Key takeaways
- Each criterion is tagged MUST, SHOULD, SUGGESTED or MAY, following RFC 2119 language with one addition.
- Basics (floss_license, MUST): "The software produced by the project MUST be released as FLOSS," meeting Open Source Initiative, Free Software Foundation, Debian, or Fedora approval standards.
- Because the badge is explicitly designed as a maturity ladder rather than three independent certificates.
- Directly, as one of its named automated checks.
The OpenSSF Best Practices Badge is a free, self-certification programme in which a Free/Libre and Open Source Software (FLOSS) project answers a structured questionnaire against 67 specific, published criteria — organised into 6 categories — to earn a "passing" badge, with Silver and Gold tiers layered sequentially on top for projects that go further. Originally the Core Infrastructure Initiative (CII) Best Practices Badge, it is now run by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, and its own stated purpose is to let "consumers of the badge quickly assess which FLOSS projects are following best practices." Unlike an automated scanner, the badge reflects what a maintainer has reported about their own project's process — which is also why OpenSSF Scorecard checks for it directly rather than treating it as redundant with Scorecard's own automated checks.
What problem does the badge solve?
A downstream team evaluating an open-source dependency usually cannot tell, from the code alone, whether the maintainers follow a defined release process, handle vulnerability reports responsibly, or require code review before merging — practices that matter for supply-chain risk but rarely show up in a quick repository browse. The Best Practices Badge turns those practices into an explicit, answerable questionnaire a maintainer completes once and keeps current, giving any downstream consumer a structured signal without needing to read the project's entire history or contact its maintainers directly.
How are the 67 passing-level criteria organised?
Counting directly from the project's own criteria document, the 67 passing-level criteria fall into 6 categories:
| Category | Criteria count | Covers |
|---|---|---|
| Basics | 13 | Project website content, FLOSS licensing |
| Change Control | 9 | Version-controlled repository, unique version numbering, release notes |
| Reporting | 8 | Bug reporting process, vulnerability report handling |
| Quality | 13 | Build process, automated test suite, coding standards, warning flags |
| Security | 16 | Secure-development knowledge, cryptographic practices, secure delivery |
| Analysis | 8 | Static and dynamic code analysis |
Each criterion is tagged MUST, SHOULD, SUGGESTED or MAY, following RFC 2119 language with one addition. Quoted directly from the project's own document: "MUST is an absolute requirement," "SHOULD indicates a criterion that is normally required, but there may exist valid reasons in particular circumstances to ignore it," and "SUGGESTED is used instead of SHOULD when the criterion must be considered, but valid reasons to not do so are even more common." To earn a passing badge, every MUST criterion must actually be met, every SHOULD criterion must be met or its exception documented, and every SUGGESTED criterion must at least be explicitly considered — a project cannot simply skip an item.
What does a real criterion look like, word for word?
Three examples, quoted directly from the project's own criteria document, show the range from simple to technically specific:
- Basics (
floss_license, MUST): "The software produced by the project MUST be released as FLOSS," meeting Open Source Initiative, Free Software Foundation, Debian, or Fedora approval standards. - Security (
know_secure_design, MUST): "The project MUST have at least one primary developer who knows how to design secure software" — and the criterion's own detail text requires familiarity with Saltzer and Schroeder's eight named design principles: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, and psychological acceptability. - Security (
crypto_keylength, MUST, N/A allowed): default security mechanisms "MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012)" — a specific, dated technical floor, not a vague instruction to use "strong" cryptography.
Why does Silver require Passing, and Gold require Silver?
Because the badge is explicitly designed as a maturity ladder rather than three independent certificates. The project's own text states plainly: "you must achieve the 'passing' criteria before you can achieve silver or gold." Each higher tier both strengthens some existing passing-level criteria (for example, requiring an OSI-approved licence outright rather than just suggesting one) and adds criteria of its own — the project notes, for instance, that Silver-level criteria include following accessibility best practices, an item not present at the passing level at all. A project cannot skip ahead; the ladder enforces that foundational practices are in place before more demanding ones are assessed.
How does OpenSSF Scorecard use this badge?
Directly, as one of its named automated checks. Scorecard's own CII-Best-Practices check documentation states it "verifies whether a project has earned an OpenSSF (formerly CII) Best Practices Badge at passing, silver, or gold level," and assigns points by tier: 10 points for gold, 7 for silver, 5 for passing, and 2 for a badge that is in progress but not yet earned. See OpenSSF Scorecard: what the automated checks actually measure for how this single check sits alongside Scorecard's other automated signals — a project with no badge at all simply scores 0 on this check rather than being flagged as actively unsafe, since the badge is opt-in and many well-run projects have simply never applied.
What should a device or firmware team actually check before trusting a dependency?
Look up the specific badge tier, not just whether a badge existsA passing badge confirms baseline practices; it does not confirm the stronger Silver/Gold criteria such as accessibility review or more advanced security requirements. Read the project's actual criteria answers, not just the badge iconThe BadgeApp publishes each project's specific met/unmet/N-A answer per criterion — useful for checking exactly which Security-category criteria (cryptography practices, secure-development knowledge) a given dependency claims to meet. Cross-check against OpenSSF Scorecard and, for build integrity specifically, SLSAThe badge is self-reported and does not re-verify automatically; Scorecard re-scans on every run, and SLSA separately grades the provenance of a specific build — see SLSA: the Supply-chain Levels for Software Artifacts framework, explained. Treat the absence of a badge as "unknown," not "unsafe."Many well-maintained FLOSS projects embedded in firmware (smaller libraries, vendor-contributed drivers) have simply never gone through the self-certification process; absence of a badge is a prompt for more manual review, not an automatic disqualification.
A firmware image frequently bundles dozens of open-source components whose individual badge status, Scorecard score and licence terms are easy to lose track of once compiled into a binary. SoftWSP's device firmware security service unpacks the shipped image, builds a software bill of materials, and matches every identified open-source component against published CVE, CISA KEV and FIRST EPSS data — the same component inventory a badge, Scorecard check or SLSA provenance claim would otherwise require you to assemble by hand. See device firmware security.
This guide is based on a direct read of the OpenSSF Best Practices Badge project's own criteria document (docs/criteria.md in the ossf/best-practices-badge GitHub repository, including a direct count of its listed MUST/SHOULD/SUGGESTED criteria by category) and the OpenSSF Scorecard project's own check documentation, rather than a secondary summary. The project's criteria document itself notes that the live, canonical, and most current criteria text has moved to the interactive bestpractices.dev site; this guide's category counts reflect the archived document as fetched and should be re-verified against the live site for any compliance-sensitive use. This guide is general information, not a substitute for reading a specific project's own badge answers.
Sources
- OpenSSF Best Practices Badge: programme overview (bestpractices.dev)
- GitHub: ossf/best-practices-badge — criteria.md (passing-level criteria, categories, MUST/SHOULD/SUGGESTED definitions)
- GitHub: ossf/best-practices-badge repository
- GitHub: ossf/scorecard — docs/checks.md (CII-Best-Practices check, point values by tier)
Frequently asked questions
What is the OpenSSF Best Practices Badge?
A free, voluntary self-certification programme for Free/Libre and Open Source Software (FLOSS) projects, run by the Open Source Security Foundation (OpenSSF), part of the Linux Foundation. It was originally the Core Infrastructure Initiative (CII) Best Practices Badge, and its GitHub repository has since moved from `coreinfrastructure/best-practices-badge` to `ossf/best-practices-badge`. Per the programme's own stated purpose, it exists so that "consumers of the badge can quickly assess which FLOSS projects are following best practices and as a result are more likely to produce higher-quality secure software." A project earns a badge by answering a structured questionnaire (the BadgeApp) about its own practices, not through a third-party audit.
How many criteria are there, and how are they organised?
At the passing level — the entry tier — the project's own criteria document lists 67 individual criteria across 6 categories. Counting directly from that document: Basics (13 criteria, covering project website content and licensing), Change Control (9, version-controlled repository and release practices), Reporting (8, bug and vulnerability disclosure process), Quality (13, build systems, testing, coding standards), Security (16, secure-development knowledge and cryptographic practices), and Analysis (8, static/dynamic code analysis). Silver and Gold are higher tiers layered on top, documented separately, and per the project's own text, "you must achieve the 'passing' criteria before you can achieve silver or gold" — the three tiers are strictly sequential, not independent.
What do MUST, SHOULD and SUGGESTED mean in the criteria, exactly?
The project defines these using RFC 2119 language plus one addition, quoted directly from its criteria document: "MUST is an absolute requirement, and MUST NOT is an absolute prohibition." "SHOULD indicates a criterion that is normally required, but there may exist valid reasons in particular circumstances to ignore it" (with the exception documented). "SUGGESTED is used instead of SHOULD when the criterion must be considered, but valid reasons to not do so are even more common." To earn the passing badge, a project must meet every MUST/MUST NOT criterion, meet every SHOULD criterion or document why not, and have explicitly considered (met or unmet) every SUGGESTED criterion — nothing can simply be left unanswered.
What does a real passing-level criterion actually require?
Specific and checkable text, not vague principle. Two examples quoted directly from the project's own criteria document: the Basics category's `floss_license` criterion states "the software produced by the project MUST be released as FLOSS," meeting OSI, FSF, Debian or Fedora approval standards. The Security category's `know_secure_design` criterion states "the project MUST have at least one primary developer who knows how to design secure software," with the detail explicitly requiring familiarity with Saltzer and Schroeder's eight design principles (economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, and psychological acceptability) by name. Another Security criterion, `crypto_keylength`, requires default key lengths that "at least meet the NIST minimum requirements through the year 2030 (as stated in 2012)" — a specific, dated technical bar, not a general instruction to "use strong cryptography."
Does OpenSSF Scorecard check for this badge?
Yes, directly and by name. OpenSSF Scorecard's own `CII-Best-Practices` check documentation states it "verifies whether a project has earned an OpenSSF (formerly CII) Best Practices Badge at passing, silver, or gold level, indicating adoption of security-focused development practices," and assigns point values by tier: 10 points for gold, 7 for silver, 5 for passing, and 2 for a badge that is in progress but not yet earned. See [OpenSSF Scorecard: what the automated checks actually measure](/guides/openssf-scorecard/) for how this fits into Scorecard's overall score — a project missing the badge entirely scores 0 on this specific check, not a penalty beyond that.
Is the badge the same thing as an OpenSSF Scorecard score or an SLSA level?
No — each measures something different, and they are complementary rather than overlapping. The Best Practices Badge is a self-reported questionnaire a maintainer fills in once (and should keep current) about process and practice; OpenSSF Scorecard is an automated tool that re-scans a repository's actual current state on every run, with the badge as just one of its many checks; SLSA grades the integrity of a specific build's provenance, not the project's general practices. See [SLSA: the Supply-chain Levels for Software Artifacts framework, explained](/guides/slsa-supply-chain-levels/) for the build-provenance model. A device or firmware team evaluating an open-source dependency reasonably checks all three rather than treating any single one as sufficient.
In this cluster
