OpenSSF Scorecard explained: how the 0-10 score is built

Per Scorecard's README, under "Aggregate score": each individual check returns a score of 0 to 10, and the aggregate score is "a weight-based average of the individual checks weighted by risk." The checks documentation assigns every check one of four risk levels, each with a fixed weight used in that average:

Because the weighting is risk-based rather than a simple average, a project that scores 0 on a Critical-rated check (for example, a dangerous GitHub Actions workflow pattern) sees a much larger hit to its overall score than a 0 on a Low-rated one (for example, a missing published license). A project does not need every check at 10 to reach a high overall score, but it cannot reach one while ignoring the heavily weighted checks.

Synthetic example. The repository and its check scores are invented to show the arithmetic; they describe no real project.

Take a library scored on 16 checks: one Critical, seven High, six Medium and two Low. The weights add up to 10 + (7 × 7.5) + (6 × 5) + (2 × 2.5) = 97.5.

Now the maintainers attach signatures to every release (Signed-Releases goes from 0 to 8, the score the checks doc gives when signatures are found) and set workflow tokens to read-only (Token-Permissions goes from 0 to 10). That adds 7.5 × 8 + 7.5 × 10 = 135 points, and the aggregate becomes 625 ÷ 97.5 = 6.4. Lifting the Low-rated CII-Best-Practices check from 0 to 10 would add only 25 points, about 0.26. Two High-risk fixes move the number more than five times as much as a Low-risk one, which is why the triage advice below starts from the High and Critical checks.

Scorecard's own checks documentation lists 20 checks in the default suite. The table below groups the ones most relevant to a software or firmware supply chain by risk level, as rated in that documentation:

Each check name links to a question Scorecard's documentation phrases as a yes/no heuristic, for example: does the project pin its dependencies to a specific hash rather than a mutable version tag (Pinned-Dependencies), does it require human code review before a pull request merges (Code-Review), and does it have open, unfixed known vulnerabilities (Vulnerabilities)? Scorecard answers each from what is publicly visible in the repository and its CI configuration — it does not require the maintainer to self-report anything. One exception: the README marks Webhooks as experimental and says it needs a maintainer token with webhook read rights, so a consumer scoring someone else's repository will not get a result for it.

Scorecard reads GitHub and GitLab repositories. The README's support table marks Dangerous-Workflow, SAST and Token-Permissions as unsupported on GitLab and several other checks as "Validating" there. The checks documentation also says Pinned-Dependencies, Signed-Releases, Packaging and CI-Tests are limited to GitHub-hosted repositories. Embedded components often live elsewhere: on a project's own Git server, behind a mailing-list patch workflow, or only as release tarballs. For those, any score you find belongs to a GitHub or GitLab mirror, and it measures the mirror's settings rather than the upstream project's real process. Record "no Scorecard data" for them and assess them another way.

A device or firmware build typically pulls in dozens to hundreds of open-source components: kernel subsystems, network stacks, crypto libraries, build tooling. Scorecard gives you a fast way to triage that list before deciding where to spend limited review time: a dependency scoring near 0 on Maintained, Vulnerabilities, or Code-Review is a stronger candidate for manual review, pinning to a known-good version, or replacement than one scoring well across the Critical and High checks. It is a triage signal, not a substitute for the kind of binary-level component inventory described in our firmware SBOM guide, and it says nothing about code that never reaches a public source repository, which is common for vendor SDKs and board-support packages. Scorecard's own SBOM check even measures whether the upstream project publishes a bill of materials of its own, which, where present, feeds directly into the kind of component-level risk tracking an SBOM and VEX process already does for your own release.

Scorecard also complements, rather than duplicates, SLSA: Scorecard's Signed-Releases, Branch-Protection and Pinned-Dependencies checks look at process signals visible from outside a repository, while SLSA's Build and Source tracks grade the build pipeline and source-history controls more formally with signed provenance; see SLSA: supply-chain levels for software artifacts.

The OSPS Baseline is a checklist maintainers implement; Scorecard measures what it can see from outside. The Baseline v2026.08.28 crosswalk maps Scorecard checks to Baseline controls:

Scorecard's own Baseline coverage analysis, written against Baseline v2026.02.19, finds probes that cover or partly cover 25 of 59 controls (42%) and fully cover 8 (14%). An experimental conformance mode (--catalog=osps-baseline) is documented in the repository, and it evaluates only the two branch-protection requirements, OSPS-AC-03.01 and AC-03.02. A good Scorecard result is therefore partial evidence toward a Baseline level, not a substitute for the project's own attestation.

• What the aggregate hides. The README itself warns: "Aggregate scores in particular tells you nothing about what individual behaviors a repository is or is not doing."
• Whether signatures are valid. Signed-Releases looks for signature files among release assets; the checks doc states "The check does not verify the signatures." Verify them in your own build.
• Whether a 10 on Vulnerabilities means none. The check queries OSV, and the remediation text lets maintainers ignore an ID they consider non-affecting via an osv-scanner.toml file. Match the component version you actually ship yourself.
• Whether a low Maintained score is a problem. The checks doc says the top score needs at least one commit per week over the previous 90 days, and admits that some software, "especially smaller utility functions, does not normally need to be maintained."
• Whether the number is stable. Scores shift when Scorecard refines its heuristics; compare results produced by the same Scorecard version.