The OpenSSF Best Practices passing criteria cover project practices as well as tooling. The model in this manual supplies some of the evidence. Following it does not establish a project’s badge status: a criterion is met when the project can point at the behavior, not at a configuration file.
What the model supplies and what a project still owes
| Area | Supplied by the model | Per-project evidence to review |
|---|---|---|
Change control |
Actions pinned by full SHA, signed commits, pull requests for every tooling change |
Public history, effective review rules, maintained releases |
Testing |
A check task on every pull request, exact-artifact release tests, a daily compatibility run |
Meaningful project tests, a documented invocation, tests for new behavior |
Analysis |
A named place for code scanning workflows |
Analysis suited to the project’s own languages; findings resolved |
Dependencies |
Dependabot pull requests for actions; locked tools and bundles |
Dependency inventory, reviewed upgrades, timely vulnerability fixes |
Delivery |
Immutable releases, content hashes verified locally, provenance reviewed at adoption |
The actual release history and its notes |
Reporting |
A |
Working report channels and the actual response history |
Documentation |
A manual rendered and deployed by a shared action |
Project purpose, interface documentation, contribution requirements, license |
Keep an evidence inventory
For each project, maintain an evidence inventory. It is an internal review aid; the public documentation should explain what readers need without discussing a badge application.
| Field | What to record |
|---|---|
Criterion or practice |
A short statement of the behavior being assessed |
Applicability |
Applicable, not applicable with a reason, or unresolved |
Public evidence |
A stable URL to documentation, releases, repository settings, or history |
Verification |
The CI check, manual review, or operational observation that tests the claim |
Status |
Met, incomplete, or needs investigation; never infer this from a template |
Owner and review date |
Who maintains the evidence and when it was last checked |
Follow-up |
A linked issue or pull request for missing work |
At minimum, review this inventory:
| Area | Evidence to locate and verify |
|---|---|
Project entry points |
Purpose, supported scope, obtaining a release, feedback, discussion, and contribution links |
Legal |
Project license in a standard location and applicable third-party notices |
Documentation |
Basic use, a working first example, public inputs and outputs, commands, configuration, formats, and APIs |
Change control |
Public version history, reviewable interim changes, unique release versions, immutable tags, and human-readable release notes |
Reporting |
Searchable issue history, enhancement path, private vulnerability channel, and actual response history |
Build and tests |
Clean source build, documented test command, CI execution, and a policy to test significant new behavior |
Analysis |
Appropriate warnings, linters, static analysis, dynamic analysis, and timely treatment of findings |
Dependencies and delivery |
Reviewed updates, dependency inventory, HTTPS delivery, locally verified content hashes, provenance review at adoption, and credential checks |
Maintenance |
Recent activity, supported versions, vulnerability handling, and periodic review of stale claims |
Cover the public project experience expands the documentation row into an authoring and review process. Verify that the configured reporting channel works. Review repository permissions and branch rules against actual successful checks, including signed commits where required.
Review and bots
Gold requires at least half of proposed modifications to be reviewed by another person before release. No workflow in this model approves or merges a change, so every tooling change is a maintainer’s pull request and counts or fails to count on its own review. Do not manufacture bot approvals.
OpenSSF Scorecard is a separate measurement. Its automated checks are not the Best Practices badge, and it scores review independently. Revisit practice evidence and response history periodically.
Sources: passing, gold, Scorecard Code-Review.