OpenSSF Scorecard explained: how the 0-10 score is built
OpenSSF Scorecard is an automated tool, maintained by the Open Source Security Foundation (OpenSSF), that runs a fixed set of heuristic checks against a public GitHub or GitLab repository and returns a score from 0 to 10 for each one. Scorecard's own README states its purpose plainly: "to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe." The result is not a security audit; it is a fast, repeatable, machine-readable signal you can run against hundreds or thousands of dependencies at once.
How the 0-10 aggregate 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:
| Risk level | Weight |
|---|---|
| Critical | 10 |
| High | 7.5 |
| Medium | 5 |
| Low | 2.5 |
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.
The 20 checks, by risk level
Scorecard's docs/checks.md 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:
| Risk | Checks |
|---|---|
| Critical | Dangerous-Workflow (GitHub Actions workflows avoid known-dangerous code patterns), Webhooks (repository webhooks are configured with authenticated tokens) |
| High | Binary-Artifacts, Branch-Protection, Code-Review, Dependency-Update-Tool, Maintained, Signed-Releases, Token-Permissions, Vulnerabilities |
| Medium | Fuzzing, Packaging, Pinned-Dependencies, SAST, SBOM, Security-Policy |
| Low | CI-Tests, CII-Best-Practices, Contributors, License |
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.
How to get a score: three ways to run it
Scorecard's README describes three practical ways to use it, in increasing order of effort:
- Look it up on the public dataset. Scorecard "scans more than 1.3 million repositories every week" and publishes the results as a public REST API (data licensed CDLA Permissive 2.0) and through the web viewer at scorecard.dev. For most dependencies you consume, a score already exists; no local run is needed.
- Add the GitHub Action to your own repository. The README states "the easiest way to use Scorecard on GitHub projects you own is with the Scorecard GitHub Action," which runs the checks on a schedule and can publish a badge.
- Run it yourself against any repository, including ones you do not own, via the published Docker container (
ghcr.io/ossf/scorecard:latest) or a standalone CLI binary, useful for scoring a dependency that has not yet been scanned by the weekly public run.
Why this matters for firmware and device supply chains
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.
A workable way to use Scorecard results
- Pull the public score first for every open-source dependency in your bill of materials before running anything locally — most will already be scanned.
- Triage by the Critical and High checks, not the overall number alone: a mediocre aggregate score driven by Low-risk checks (missing a contributor from a second organisation, no CII badge) matters far less than a weak Vulnerabilities or Maintained score.
- Treat a 0 or missing score as "unknown," not "unsafe." Scorecard only runs against public Git repositories; vendored code, private forks and binary-only SDKs will not have one, and that absence needs its own review step.
- Don't stop at the number. Read the specific check results for anything you are about to adopt widely; the score is a prioritisation tool for where to look next, not a pass/fail gate.
SoftWSP's firmware and component analysis identifies the open-source and vendor code actually compiled into your build, whether or not it has a public Scorecard entry: see device firmware security.
This guide summarises the public OpenSSF Scorecard documentation; it does not constitute a security audit or compliance advice.
Frequently asked questions
What is OpenSSF Scorecard?
An automated tool maintained by the Open Source Security Foundation (OpenSSF) that, in its own words, was created "to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe." It runs a set of heuristic checks against a public GitHub or GitLab repository and scores each one from 0 to 10.
How is the overall Scorecard score calculated?
Scorecard's own documentation states the aggregate score "is a weight-based average of the individual checks weighted by risk": checks rated Critical risk carry a weight of 10, High risk 7.5, Medium risk 5, and Low risk 2.5. A project does not need a perfect 10 on every check to get a high overall score, but a 0 on a heavily weighted Critical or High check pulls the average down hard.
How many checks does Scorecard run, and what do they check?
The project's checks documentation lists 20 checks in the default set, covering areas such as branch protection, required code review, pinned dependencies, signed releases, least-privilege workflow tokens, fuzzing, static analysis (SAST) use, and known unfixed vulnerabilities. Each check is independently rated Critical, High, Medium, or Low risk.
Is a high Scorecard score a guarantee that a dependency is safe?
No. Scorecard measures process heuristics visible from the outside of a public repository, such as whether branch protection or signed releases are configured; it does not read or audit the code itself for logic flaws or hidden vulnerabilities. A high score indicates engineering hygiene that correlates with lower supply-chain risk, not a security audit result or a certification.