Core Infrastructure Initiative Best Practices Badge

This project identifies best practices for
Free/Libre and Open Source Software (FLOSS)
and implements a badging system for those best practices.
The "BadgeApp" badging system is a simple web application
that lets projects self-certify that they meet the criteria
and show a badge.
The real goal of this project is to encourage projects to
apply best practices, and to help users determine which FLOSS projects do so.
We believe that FLOSS projects that implement best practices are more likely
to produce better software, including more secure software.

See the
Core Infrastructure Initiative (CII) Best Practices badge website if you want to try to actually get a badge.

This is the development site for the criteria and badge application
software that runs the website.
Feedback is very welcome via the
GitHub site
as issues or pull (merge) requests.
There is also a
mailing list
for general discussion.

• Badging Criteria for the "passing" level
• Other criteria for higher-level badges
• Information on how to contribute
  (including how to report vulnerabilities)
• Up-for-grabs
  lists smaller tasks that may take 1-3 days, and are ideal for people
  new to the project (or FLOSS in general)
• Background on Badging
• ChangeLog
• Requirements - our overall requirements
• Design - our basic design
• Current implementation - notes about the
  BadgeApp implementation
• security - notes about BadgeApp security
• testing - notes about BadgeApp automated tests
• api - Application Programming Interface (API), including data downloads
• Installation - Installation and quick start
• Vetting - More about our vetting approach
• Roadmap - Roadmap (future plans)

Summary of Best Practices Criteria "passing" level

This is a summary of the passing criteria, with requirements in bold
(for details, see the full list of criteria):

• Have a stable website, which says:
  • what it does
  • how to get it
  • how to give feedback
  • how to contribute and
    preferred styles
• Explicitly specify a
  FLOSS license
• Support HTTPS on the project sites
• Document how to install and run (securely),
  and any API
• Have a distributed
  public version control system,
  including changes between releases:
  • Give each release a unique version, using
    semantic versioning format
  • Give a summary of changes for each release,
    identifying any fixed vulnerabilities
• Allow bug reports to be submitted,
  archived and
  tracked:
  • Acknowledge/respond to bugs &
    enhancement requests, rather than
    ignoring them
  • Have a secure,
    documented process for
    reporting vulnerabilities
  • Respond within 14 days,
    and fix vulnerabilities,
    within 60 days if they're public
• Have a build that works, using
  standard
  open-source tools
  • Enable (and fix)
    compiler warnings and lint-like checks
  • Run other static analysis tools and
    fix exploitable problems
• Have an automated test suite that
  covers most of the code/functionality, and
  officially
  require new tests for new code
• Automate running the tests on all changes,
  and apply dynamic checks:
  • Run memory/behaviour analysis tools
    (sanitizers/Valgrind etc.)
  • Run a fuzzer or web-scanner over the code
• Have a developer who understands secure software
  and common vulnerability errors
• If cryptography is used:
  • Use public protocols/algorithm
  • Don't re-implement standard functionality
  • Use open-source cryptography
  • Use key lengths that will stay secure
  • Don't use known-broken or
    known-weak algorithms
  • Use algorithms with forward secrecy
  • Store any passwords with iterated, salted, hashes using a key-stretching algorithm
  • Use cryptographic random number sources

Summary of Best Practices Criteria for higher levels

Getting a passing badge is a significant achievement;
on average only about 10% of pursuing projects have a passing badge.
That said, some projects would like to meet even stronger criteria,
and many users would like projects to do so.
We have established two higher levels beyond passing: silver and gold.
The higher levels strengthen some of the passing criteria and add new
criteria of their own.

Silver

Here is a summary of the silver criteria, with requirements in bold
(for details, see the full list of silver criteria):

• Use a DCO or similar
• Define/document project governance
• Another will have the necessary access rights if someone dies
• "Bus factor" of 2 or more
• Document security requirements
• Have an assurance case explaining why security requirements are met
• Have a quick start guide
• Follow accessibility best practices
• Pick & follow coding standards
• Monitor external dependencies to detect/fix known vulnerabilities
• Tests have 80%+ statement coverage
• Project releases for widespread use are cryptographically signed
• Check all inputs from potentially untrusted sources for validity (using a whitelist)
• Use hardening mechanisms

Gold

Here is a summary of the gold criteria, with requirements in bold
(for details, see the full list of gold criteria):

• At least 2 unassociated significant contributors
• Per-file copyright and license
• Use 2FA
• At least 50% of all modifications are reviewed by another
• Have a reproducible build
• Use continuous integration
• Statement coverage 90%+
• Branch coverage 80%+
• Support secure protocols & disable insecure protocols by default
• Use TLS version 1.2 or higher
• Have a hardened project website, repo, and download site
• Have a security review (internal or external)

License

All material here is released under the MIT license.
All material that is not executable, including all text when not executed,
is also released under the
Creative Commons Attribution 3.0 International (CC BY 3.0) license or later.
In SPDX terms, everything here is licensed under MIT;
if it's not executable, including the text when extracted from code, it's
"(MIT OR CC-BY-3.0+)".

Like almost all software today, this software depends on many
other components with their own licenses.
Not all components we depend on are MIT-licensed, but all
required components are FLOSS. We prevent licensing issues
using various processes (see CONTRIBUTING).