Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.
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 companies. To earn a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR be unmet with justification, and
all SUGGESTED criteria must be met OR unmet (we want them considered at least). If you want to enter justification text as a generic comment, instead of being a rationale that the situation is acceptable, start the text block with '//' followed by a space. Feedback is welcome via the GitHub site as issues or pull requests
There is also a mailing list for general discussion
We gladly provide the information in several locales, however, if there is any conflict or inconsistency between the translations, the English version is the authoritative version.
If this is your project, please show your badge status on your project page! The badge status looks like this:
You can show your badge status by embedding this in your markdown file:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/26/badge)](https://bestpractices.coreinfrastructure.org/projects/26)
or by embedding this in your HTML:
<a href="https://bestpractices.coreinfrastructure.org/projects/26"><img src="https://bestpractices.coreinfrastructure.org/projects/26/badge"></a>
level criteria. You can also view the