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.
This page discusses the set of best practices for Free/Libre and Open Source Software (FLOSS) projects developed for the Open Source Security Foundation (OpenSSF) Best Practices badge. Projects that follow these best practices will be able to voluntarily self-certify and show that they've achieved the relevant badge. Projects can do this, at no cost, by using a web application (BadgeApp) to explain how they meet these practices and their detailed criteria.
这些最佳实践的创建是为了：
The idiom "best practices" means "a procedure or set of procedures that is preferred or considered standard within an organization, industry, etc." (source: Dictionary.com). These criteria are what we believe are widely "preferred or considered standard" in the wider FLOSS community.
For more information on how these criteria were developed, see the OpenSSF Best Practices badge GitHub site.
You may also see the full criteria.
The best practices criteria are divided into three levels:
Every criterion has a short name, shown as superscripted text inside square brackets after the criteria text.
The Linux Foundation also sponsors the OpenChain Project, which identifies criteria for a "high quality Free and Open Source Software (FOSS) compliance program." OpenChain focuses on how organizations can best use FLOSS and contribute back to FLOSS projects, while the OpenSSF Best Practices badge focuses on the FLOSS projects themselves. The OpenSSF Best Practices badge and OpenChain work together to help improve FLOSS and how FLOSS is used.
In some cases we automatically test and fill in information if the project follows standard conventions and is hosted on a site (e.g., GitHub) with decent API support.
We intend to improve this automation in the future. Improvements to the automation are welcome!
However, we have intentionally prioritized on "what is important", even if can't be affordably automated. We love automated measurements, but not everything important is automatable or can be automated affordably.
We expect that these practices and their detailed criteria will be updated over time. We plan to add new criteria but mark them as "future" criteria, so that projects can add that information and maintain their badge.
Feedback is very welcome via the GitHub site as issues or pull requests. There is also a mailing list for general discussion.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. The additional term SUGGESTED is added. In summary, these key words have the following meanings:
Often a criterion is stated as something that SHOULD be done, or is SUGGESTED, because it may be difficult to implement or the costs to do so may be high.
To obtain a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be either met OR unmet with justification, and all SUGGESTED criteria have to be considered (it must be rated as met or unmet, but justification is not required unless noted otherwise). An answer of N/A ("not applicable"), where allowed, is considered the same as being met. In some cases, especially in the higher levels, justification and/or a URL may be required.
Some criteria have special markings that influence this:
A project must achieve the previous level to achieve the next level. In some cases SHOULD criteria become MUST in higher level badges, and some SUGGESTED criteria at lower levels become SHOULD or MUST in higher level badges. The higher levels also require more justification, because we want others to understand how the criteria are being met.
The (many) cryptographic criteria do not always apply, because some software has no need to directly use cryptographic capabilities. In those cases, answer N/A.
There is one implied passing criterion - every project MUST have a public website with a stable URL. This is required to create a badge entry in the first place.
If you are not familiar with software development or running a FLOSS project, materials such as Producing Open Source Software by Karl Fogel may be helpful to you.
以下是一些关键术语：
条件：
The passing level does not include criteria that would be impractical for a single-person project, e.g., something that requires a significant amount of money. Many FLOSS projects are small, and we do not want to disenfranchise them.
Our application gives every project entry a unique id, but that doesn't help people searching for the project. For our purposes, the real name of a project is the URL for its repository, and where that is not available, the project "front page" URL. We rate limit changes to the repo URL to prevent some nonsense. Projects normally have a human-readable name, but these names are not unique enough.
The paper Open badges for education: what are the implications at the intersection of open systems and badging? identifies three general reasons for badging systems (all are valid for this):
We have chosen to use self-certification, because this makes it possible for a large number of projects (even small ones) to participate. There are millions of FLOSS projects, and paying third parties to independently evaluate each one does not scale. There's a risk that projects may make false claims, but we think the risk is small, users can check the claims for themselves, and false claims can be overridden. We also use automation to override false claims where we can be confident in the results.