Repository files navigation

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

See theOpenSSF Best Practices badge website if you want to try to actually get a badge.

This is the development site for the criteria and badge applicationsoftware that runs the website.Feedback is very welcome via theGitHub siteas issues or pull (merge) requests.There is also amailing listfor general discussion.This project was originally developed under the CII, but itis now part of theOpen Source Security Foundation (OpenSSF)Best Practices Working Group (WG).The original name of the project was the CII Best Practices badge, butit is now the OpenSSF Best Practices badge project.

Interesting pages include:

• BadgingCriteria for the passing level
• Criteria for all badging levels
• Information on how tocontribute
• Information onour own security, including how to report vulnerabilities in our badge application
• Up-for-grabslists smaller tasks that may take 1-3 days, and are ideal for peoplenew to the project (or FLOSS in general)
• Background on Badging
• ChangeLog
• Requirements - our overall requirements
• Design - our basic design
• Currentimplementation - notes about theBadgeApp 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)

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

• Have astable website, which says:
  • what it does
  • how to get it
  • how to give feedback
  • how to contribute andpreferred styles
• Explicitly specify aFLOSSlicense
• Support HTTPS on the project sites
• Document how to install and run (securely),andany API
• Have adistributedpublic version control system,includingchanges between releases:
  • Give each release a unique version, usingsemantic versioning format
  • Give asummary of changes for each release,identifying any fixed vulnerabilities
• Allowbug reports to be submitted,archived andtracked:
  • Acknowledge/respond to bugs &enhancement requests, rather thanignoring them
  • Have asecure,documented process forreporting vulnerabilities
  • Respond within 14 days,andfix vulnerabilities,within 60 days if they're public
• Have a build that works, usingstandardopen-source tools
  • Enable (andfix)compiler warnings and lint-like checks
  • Run other static analysis tools andfix exploitable problems
• Have an automated test suite thatcovers most of the code/functionality, andofficiallyrequire 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 softwareandcommon 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 orknown-weak algorithms
  • Use algorithms with forward secrecy
  • Store any passwords with iterated, salted, hashes using a key-stretching algorithm
  • Use cryptographic random number sources

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 newcriteria of their own.

Here is a summary of the silver criteria, with requirements in bold(for details, see thefull 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 an allowlist)
• Use hardening mechanisms

Here is a summary of the gold criteria, with requirements in bold(for details, see thefull 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)

If you've used this system in the past, you may have referred to ourdocsubdirectory for documentation. We have renamed that to adocs subdirectory.

We have recently moved to the new main sitehttps://www.bestpractices.dev.For many years the main site was athttps://bestpractices.coreinfrastructure.org.However, the Core Infrastructure Initiative (CII) has ended, and we havebecome part of the Open Source Security Foundation (OpenSSF).Therefore, it made sense to change the domain name so it's no longer tiedto the CII. The domain name is much shorter, too.We use the "www" subdomain because there are technical challenges usinga top-level domain with our CDN; it's more efficient to use the subdomain.

Seegovernance for how this project is governed,TSC for current best practices badgeproject technical steering committee (TSC) members, andadmin for information to web site application administrators.

All material in this repository is released under theMIT license.All material in this repository that is not executable,including all text when not executed,is also released under theCreative 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 manyother components with their own licenses.Not all components we depend on are MIT-licensed, but allrequired components are FLOSS. We prevent licensing issuesusing various processes (seeCONTRIBUTING).

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

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

Thecomplete collection of datamanaged by this application is thuslicensed 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 thoseoldest 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), andthe project license is unaffected.