OpenSSF FLOSS Best Practices Badge
Description
The OpenSSF FLOSS Best Practices is a set of recommendations from the Open Source Security Foundation (OpenSSF) Best Practices Working Group to help open source developers create and maintain more secure software.
The best practices criteria are divided into three levels, for an incremental adoption:
-
Passing focuses on best practices that well-run FLOSS projects typically already follow. Getting the passing badge is an achievement; at any one time only about 10% of projects pursuing a badge achieve the passing level.
-
Silver is a more stringent set of criteria than passing but is expected to be achievable by small and single-organization projects.
-
Gold is even more stringent than silver and includes criteria that are not achievable by small or single-organization projects.
Rationale
There is no set of practices that can guarantee that software will never have defects or vulnerabilities. Even formal methods can fail if the specifications or assumptions are wrong. Nor is there any set of practices that can guarantee that a project will sustain a healthy and well-functioning development community.
However, following best practices can help improve the results of projects. For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different organizations.
These best practices are not limited only to the software supply chain security, but many recommendations do. These are tagged with sscs. All recommendations are relevant for the security posture of the software, and tailored to the open-source community.
For example, there are some recommendations on the usage of cryptography which are quite relevant for software security, but may have a relative influence on the supply-chain security.
Benefits
Intimately associated with the best practices is the Badge program, as a way to provide consumers of the software the level of compliance with the best practices.
Basic project website content
ID |
openssf_flossbp/basic_project_website_content |
Severity |
high |
Category |
Basics |
Levels |
Passing |
Optional |
false |
Description
The project website MUST succinctly describe what the software does (what problem does it solve?).
Rationale
Contributors need to understand not only how to contribute, but also the overall contribution process, so that they will understand how their work could be incorporated and what the expectations are after the initial submission.
This means that wherever the project describes how to contribute, the project must include (directly or by reference) information on the contribution process. Note that criterion "interact" (listed earlier) requires that the contribution information be on the project website.
Verification
The project site should contain a document with a clear description. This MUST be in language that potential users can understand (e.g., it uses minimal jargon).
The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software.
The information on how to contribute MUST explain the contribution process (e.g., are pull requests used?)
The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard).