OpenSSF Best Practices Badge (formerly CII 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. We support both our original "metal" badge criteria and the OpenSSF Baseline criteria.

See the OpenSSF 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. This project was originally developed under the CII, but it is now part of the Open Source Security Foundation (OpenSSF) Best Practices Working Group (WG). Its formal name is the OpenSSF Best Practices badge project, formerly named the CII Best Practices badge.

Interesting pages

Interesting pages include:

• Badging Criteria for the passing level
• Criteria for all badging levels
• Information on how to contribute
• Information on our own security, including how to report vulnerabilities in our badge application
• 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, specifically its assurance case
• 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)
• Automation proposals - a mechanism for external tools to easily propose changes (this is our recommended integration mechanism)

Baseline and Metal series

The best practices badge site supports both the OpenSSF Baseline criteria (baseline-1,2,3) and its own "Metal series" of criteria (passing, silver, gold).

The baseline series is a more minimal checklist focusing only on MUST security requirements and is derived in part from global cybersecurity regulations and frameworks. The metal series is a larger set of criteria that includes suggestions and quality issues that impact security, and is derived in part from experiences of secure FLOSS projects. Both focus on security.

We encourage projects to eventually do both. You choose where to start. Once you do one series, it's much easier to do the other.

Summary of Best Practices Criteria "passing" level

This is a summary of the passing criteria, with requirements in bold:

• 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 :

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

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)

Directory "doc" is now "docs"

If you've used this system in the past, you may have referred to our doc subdirectory for documentation. We have renamed that to a docs subdirectory.

Main site

Years ago we moved our main site to https://www.bestpractices.dev.

For many years the main site previously was at https://bestpractices.coreinfrastructure.org. However, the Core Infrastructure Initiative (CII) ended and we became part of the Open Source Security Foundation (OpenSSF). We use the "www" subdomain because there are technical challenges using a top-level domain with our CDN; it's more efficient to use the subdomain.

Governance and administration

See governance for how this project is governed, TSC for current best practices badge project technical steering committee (TSC) members, and admin for information to web site application administrators.

Software Bill of Materials (SBOM)

We generate an Software Bill of Materials (SBOM) in SPDX format. Here is more information how to get our SPDX SBOMs.

License

All material in this repository is released under the MIT license. All material in this repository 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).

The data managed by this software is under different highly-permissive open data licenses, depending on when the data was last updated:

• Data updated on or after 2024-08-23T12:00:00Z is released under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. This agreement does not impose any restriction or obligations with respect to the use, modification, or sharing of Results.
• Otherwise, data updated on or after 2017-02-20T12:00:00Z is released under the Creative Commons Attribution 3.0 International (CC BY 3.0) license or later (CC-BY-3.0+).
• Otherwise, data is released under the Creative Commons Attribution 3.0 International (CC BY 3.0) license (CC-BY-3.0).

The complete collection of data managed by this application is thus licensed with the SPDX license expression "(CC-BY-3.0 AND CDLA-Permissive-2.0)". Only a few old entries are under the CC-BY-3.0, so if you omitted those oldest data values, the dataset is released under the expression "(CC-BY-3.0+ AND CDLA-Permissive-2.0)".

Submitters of data retain copyright (if any), and the project license is unaffected.