OpenSSF Scorecard is a tool from the Open Source Security Foundation that runs automated checks against a repository and scores each one from 0 to 10. It measures project habits such as code review, branch protection and workflow safety. It does not scan the code for flaws, so a score is a signal, not a verdict.
How the scoring works
Scorecard lists roughly 18 to 19 checks, depending on which page you read, and its project site groups them into three themes: holistic security practices, source risk assessment, and build risk assessment. Each check returns a score from 0 to 10, where 10 is best.
Every check also carries a risk level: Critical, High, Medium or Low. Those levels act as weights in the aggregate score, at 10, 7.5, 5 and 2.5. The headline number is a risk weighted average, so a failed Critical or High check pulls the total down much further than a failed Low one.
What the checks look at
The checks cover four broad areas.
- Source: branch protection, code review, whether binaries are checked into the repository, and whether a license is declared.
- Build: pinned dependencies, workflow token permissions, risky patterns in GitHub Actions workflows, and whether packages are published from CI.
- Maintenance: whether the project is actively maintained, whether a dependency update tool is configured, and whether a security policy exists.
- Verification: static analysis, fuzzing, signed releases, and a check against the OSV database for known unfixed vulnerabilities.
What a score does not tell you
The Scorecard documentation says plainly that the checks are heuristics, with false positives and false negatives. Scores also shift over time because heuristics are added or refined.
Two limits matter most for anyone using scores to pick dependencies.
First, Scorecard focuses on overall security posture and practices. It is not a vulnerability scanner for the code itself. A project can score well and still ship a bug, and a small project run by one careful person can score poorly on checks that assume a team.
Second, some things you might expect are absent. Two-factor authentication for maintainers is not a check, because that data is not public.
How to use it sensibly
Treat Scorecard as one input to a dependency decision. Look at the individual checks rather than the aggregate, because the aggregate hides which behaviors are present. A project missing Signed-Releases matters differently from one failing Dangerous-Workflow.
Pair it with signals Scorecard does not cover: who maintains the package, how fast fixes ship, and whether the version you use has known vulnerabilities in your actual call paths. Safeguard's SBOM and dependency scanning and reachability analysis cover that last part, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a score of 10 mean a project is secure?
No. It means the project passes the automated practice checks. It says nothing about undiscovered bugs in the code.
Is Scorecard only for GitHub projects?
GitHub is the main target. The documentation also describes GitLab support, but with some checks unsupported there, including Dangerous-Workflow, SAST and Token-Permissions.
Sources
Last reviewed: 19 October 2026.
