The OpenSSF Best Practices badge shows that a project filled in a questionnaire about recommended practices, such as how it handles testing, releases and vulnerability reports. It is voluntary and self-certified, with some automated checking, so treat it as evidence the maintainers care, not as proof the code is secure.
Where it comes from
The program is run by the Open Source Security Foundation, part of the Linux Foundation, and was formerly called the Core Infrastructure Initiative Best Practices badge. Projects explain in a web application how they meet each practice. The site says projects can self-certify at no cost, and that automated analysis fills in some answers and flags obviously incorrect ones.
The program page we fetched describes the passing badge. We could not confirm the details of higher levels from it, so check the criteria on the badge site before relying on one.
What it can tell you
- The maintainers know a baseline of practices exists and took time to document theirs.
- The project has answered questions about reporting vulnerabilities, using version control and publishing releases.
- The answers are public, so you can read them and test a claim.
OpenSSF Scorecard includes a CII-Best-Practices check that looks for the badge. It carries a low risk weight in the aggregate, which is a fair reflection of how much it can prove alone.
What it cannot tell you
| Claim you might want | Does the badge show it? |
|---|---|
| Code is free of vulnerabilities | No |
| The maintainer account is secure | No |
| Releases are signed and reproducible | Only if the answers say so, and you should verify |
| The project will be maintained next year | No |
| The answers are accurate | Partly, since checks are automated in places |
Because the process is voluntary, absence is weak evidence too. Many solid projects never applied.
How to use it in a review
- Open the badge page and read the specific answers on vulnerability reporting and release practice, not just the status.
- Check one or two claims against the repository. If it says there is a security policy, find the file.
- Note the badge as one row in your adoption record.
- Move on to evidence that is harder to fake: advisory history, release pipeline, who can publish.
Our rubric overview shows where the badge fits among the other signals.
A note on trust and gaming
Any self-reported signal can be filled in optimistically. The program tries to counter that with automated analysis that flags obviously incorrect answers, but it cannot check every claim. That is why the useful move is to sample: pick two answers that matter to you, such as how vulnerability reports are received and how releases are produced, and verify them in the repository or on the registry. If both check out, your confidence in the rest rises. If one does not, treat the whole badge with caution and move on to harder evidence.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Is the badge an audit?
No. The program describes voluntary self-certification with some automated analysis, so it is not an independent audit.
Should I require the badge for every dependency?
Probably not. It would exclude good projects. Use it as a positive signal.
Sources
Last reviewed: 19 October 2026.
