OpenSSF Scorecard is an automated tool that gives an open source project a 0 to 10 score on each of a set of security checks, such as code review and pinned dependencies. Use it to triage the packages a target depends on most, then read the individual checks, not the aggregate.
What the tool does
According to the project's own page, Scorecard assesses security heuristics called checks, scores each from 0 to 10, and blends them into an aggregate weighted by risk level: critical 10, high 7.5, medium 5 and low 2.5. The default checks include Binary-Artifacts, Branch-Protection, Code-Review, Dangerous-Workflow, Dependency-Update-Tool, Maintained, Pinned-Dependencies, SAST, Security-Policy, Signed-Releases, Token-Permissions and Vulnerabilities, among others. Results are available through a web viewer, a REST API, README badges and a GitHub Action.
The project is clear about limits: checks are heuristics with false positives and false negatives, and an aggregate score tells you nothing about which individual behaviours a repository does or does not follow.
Where it fits in diligence
A target's product may depend on hundreds of open source packages. You cannot review them all. Scorecard helps you choose where to look first:
- Take the target's SBOM and list the packages that sit on a critical path, such as authentication, parsing, cryptography and the build chain.
- Look up each one in the Scorecard viewer.
- Sort by the specific checks you care about, not by total score.
- Ask the target what it knows about the low scorers.
Which checks to read first
| Check | Why it matters to a buyer |
|---|---|
| Maintained | An unmaintained package will not get fixes |
| Code-Review | Shows whether changes need a second pair of eyes |
| Signed-Releases | Lets you verify what you install came from the project |
| Dangerous-Workflow | Flags build setups that attackers can abuse |
| Security-Policy | Shows a reporting path exists |
| Vulnerabilities | Known unfixed issues in the project itself |
A small project with one maintainer can score low on Code-Review and still be well run. Context matters.
How to avoid misusing the score
Do not use a number as a gate for a whole acquisition. Use it as a prompt for a conversation: "This package scores low on Maintained and sits in your login flow. What is your plan?" A good answer names a replacement, a fork, or a contribution back to the project.
Also remember that the score describes the project, not the version you use. A pinned old release of a well scored project can still carry known flaws.
Try it yourself
Open the demo to see how a dependency inventory is built and how risky packages surface. Think about which of them you would look up first.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning and SBOM generation produce the package list you would feed into this triage, and you can start with a free scan.
Quick check
Is a Scorecard score a safety rating?
No. It measures project practices. The project itself warns that checks are heuristics that can be wrong.
Can I run it on a private repository?
Scorecard is built for public repositories. For private code, use it as a checklist of habits to ask about.
Sources
Last reviewed: 19 October 2026.
