What is the OpenSSF Best Practices Badge and how does a project earn one?
answer
- self-assessment, not an audit
- public questionnaire per project
- three cumulative named levels
- answers marked Met/Unmet/N/A
- justifications visible to anyone
basics
~20 sThe OpenSSF Best Practices Badge is a public self-assessment for open-source projects. Maintainers answer a fixed list of criteria covering licensing, change control, testing and vulnerability handling; meeting every required one earns that level's badge.
solid answer
~50 sIt is a badge programme run under the OpenSSF (originally the Linux Foundation's CII Best Practices Badge) in which a project's own maintainers fill in a public questionnaire about how the project is run. Each criterion is answered Met, Unmet or N/A with a written justification, and criteria are graded MUST, SHOULD or SUGGESTED. There are three levels — passing, silver and gold — and a project displays a level once it satisfies that level's required criteria. The passing criteria cover things like an OSI-approved license, a public version-controlled repository with unique version numbering and release notes, a documented way to report bugs and vulnerabilities, a working build and automated test suite, basic secure-development and cryptography practice, and no publicly known unpatched vulnerabilities of medium or higher severity older than 60 days. Nobody audits the answers — but every answer and justification is public.
go deeper
Be ready to say in one sentence that this is a self-assessment run by the project itself, that answers are public, and that there are three levels named passing, silver and gold.
Explain the mechanics: criteria answered Met, Unmet or N/A with justifications, grades of MUST, SHOULD and SUGGESTED, levels that are cumulative, and roughly which themes the passing criteria cover.
Show that you read the entry rather than the image — which criteria were marked N/A, when the entry was last touched, whether the justification links still resolve — and say what the badge does not cover.
Own the question of where a voluntary, self-asserted signal belongs in a dependency policy: as an input to a documented decision, never as the decision itself, and never as evidence in a risk register on its own.
## What it is The OpenSSF Best Practices Badge is a **self-certification programme for open-source projects**. It began life as the Linux Foundation's Core Infrastructure Initiative (CII) Best Practices Badge and now sits under the Open Source Security Foundation. A project registers an entry, works through a questionnaire of criteria describing how the project is developed and maintained, and — if it satisfies the required criteria — gets to display a badge image on its README or site. The important structural facts, in order of how often people get them wrong: 1. **It is self-asserted.** The maintainers answer the questions. There is no auditor, no site visit, no sampling of evidence, no third party who signs off before the badge appears. 2. **The answers are public.** Every criterion carries a status and a free-text justification, usually with links into the repository, and anyone can read the whole entry. That publicity is the programme's only real enforcement mechanism: a false claim is a false claim made in the open, next to the repo that contradicts it. 3. **It describes a project, not a release.** The entry is attached to the project, not to version 4.2.1 of it and not to the tarball you downloaded. A badged project can still ship a bad release tomorrow. ## How a project earns one Criteria are grouped roughly by theme: project basics (a homepage, a description, how to contribute), the license (an OSI-approved FLOSS license, license file present), documentation (basic user docs and a reference), change control (a public version-controlled repository, interim versions available, unique version numbering, release notes), reporting (a documented bug-reporting process, an archived discussion, a documented process for **privately** reporting vulnerabilities and evidence that reports actually get responses), quality (a working build system, an automated test suite, a stated policy that new functionality arrives with tests, compiler/linter warning flags enabled), security (at least one primary developer who knows how to design secure software and the common kinds of error, sound use of cryptography with no hardcoded credentials, delivery protected against man-in-the-middle, and no publicly known unpatched vulnerabilities of medium or higher severity for more than 60 days) and analysis (static analysis applied and any discovered exploitable problems fixed). Each criterion is marked **Met**, **Unmet** or **N/A**, and each is graded: | Grade | What it means | |---|---| | MUST | Required at that level; unmet blocks the badge | | SHOULD | Required unless there is a stated justification for not doing it | | SUGGESTED | Must be *answered*, but any answer is acceptable | The entry shows a completion percentage; at 100% of a level's requirements, the badge for that level is displayed. There are three levels — **passing**, **silver**, **gold** — and they are cumulative: silver includes everything in passing, gold includes everything in silver. ## What it is worth Used correctly, the badge is a **cheap, honest signal of maintainer engagement and baseline hygiene**. A project that has worked through the questionnaire has, at minimum, thought about how someone reports a vulnerability to it, what its release process looks like, and whether its tests run. That is genuinely more than many dependencies can say. Used incorrectly, it becomes a rubber stamp. Three limits to internalise: - **It is a process claim, not an artifact claim.** It tells you something about how the project works. It tells you nothing about whether the file you just downloaded is the file the maintainers built. - **It is a snapshot.** An entry records when it was last updated and nothing forces a refresh; a badge earned once can sit unchanged while the project's practices drift. - **Absence is not evidence of badness.** Plenty of carefully run libraries have simply never filled in the form, because nobody asked them to. So read the entry, not the image. The justifications — which criteria the project marked N/A and why, how it describes its release process, whether the links still resolve — carry far more information than the coloured badge in the README.
- Does the badge apply to a released artifact or to the project?To the project. The entry describes how the project is developed — its repository, reporting channels, test policy and release practice — not any particular version or published file. A badged project can publish a release that was never built from the reviewed source, and the badge would look exactly the same.
- What stops a project from claiming criteria it does not meet?Nothing technical. There is no auditor. What constrains it is publicity: the answers and their justifications are visible next to a repository that either supports them or does not, so an inflated claim is checkable by any reader and can be disputed in the open. Consumers are expected to read the answers, not just the badge.
- Are all criteria at a level strictly required?No. Criteria are graded MUST, SHOULD or SUGGESTED. A MUST blocks the badge if unmet. A SHOULD can be left unmet if the project states a justification. A SUGGESTED must be answered but any answer is accepted. That grading is why reading justifications matters more than reading the level.
It is closer to a restaurant's self-completed food-hygiene questionnaire pinned in the window than to an inspector's certificate: useful, honest more often than not, and never verified before it goes up.
saying these in an interview costs you the question
- Calls the badge a third-party certification or audit
- Thinks a badge proves the project has no vulnerabilities today
- Believes the badge covers a specific downloaded release
- Assumes someone reviews the answers before the badge appears
- Treats an unbadged project as automatically less secure