OpenSSF Scorecard is an automated tool from the Open Source Security Foundation that grades a repository against a set of security best-practice checks and produces a 0-10 score for each one, giving you a fast, objective read on how safely a project is maintained. Instead of manually digging through a dependency's commit history, branch protection, and release process, you point Scorecard at the repo and it answers the question most engineers actually care about: is this project healthy enough to depend on?
This guide covers what the checks measure, how scoring works, and how to wire Scorecard into your own repositories.
What Scorecard actually measures
Scorecard runs a series of independent checks against a public repository, mostly on GitHub, and each check returns a score from 0 to 10 plus a risk weighting. The checks map to concrete supply chain risks rather than vague "is this good code" opinions. Some of the most influential ones include:
- Branch-Protection - are pushes to the default branch gated by review and status checks?
- Code-Review - does the project require review before merging?
- Maintained - is there recent commit and issue activity, or has the project gone quiet?
- Dangerous-Workflow - do CI workflows contain patterns like untrusted code execution in privileged contexts?
- Token-Permissions - do GitHub Actions workflows follow least privilege?
- Pinned-Dependencies - are dependencies pinned by hash rather than a mutable tag?
- Vulnerabilities - does the project have known unfixed vulnerabilities via the OSV database?
- Signed-Releases, Binary-Artifacts, Fuzzing, SAST, and CII-Best-Practices among others.
Each check is documented in the project's checks.md reference, including exactly what evidence it looks for and why it matters. That transparency is the point: a Scorecard result is auditable, not a black-box rating.
How the aggregate score is calculated
Every check produces its own 0-10 score. Scorecard then combines them into a single weighted aggregate, where higher-risk checks (like Dangerous-Workflow and Branch-Protection) carry more weight than lower-impact ones. A project sitting around 7 or above is generally following solid practices; a score in the low single digits is a signal to look harder before you add the dependency to your critical path.
Two cautions. First, the aggregate can hide a critical weakness: a project can score well overall while failing one check that matters enormously for your use case, so read the per-check breakdown, not just the headline number. Second, Scorecard measures process and hygiene, not the absence of bugs. A high score means the maintainers run a disciplined project; it does not guarantee the code is vulnerability-free.
Running Scorecard on a project
The fastest way to try it is the CLI. With the binary installed and a GitHub token exported, you can check any public repo:
export GITHUB_AUTH_TOKEN=<your_pat>
scorecard --repo=github.com/ossf/scorecard
You will get a table of each check, its score, and a reason. To narrow to specific checks:
scorecard --repo=github.com/expressjs/express --checks=Branch-Protection,Maintained,Vulnerabilities
Output can be rendered as JSON for ingestion into other tooling:
scorecard --repo=github.com/pallets/flask --format=json > flask-scorecard.json
The JSON form is what you want if you are feeding results into a dashboard or a policy engine that gates which dependencies your teams are allowed to adopt.
Continuous scoring in CI with GitHub Actions
For projects you own, the more valuable pattern is running Scorecard on every change to your own repository so regressions in your security posture surface immediately. OpenSSF publishes a scorecard-action and a starter workflow. Once configured, it runs on pushes to the default branch, publishes results to the code-scanning dashboard, and can optionally submit to the public Scorecard registry.
A minimal workflow looks like this:
name: Scorecard
on:
branch_protection_rule:
schedule:
- cron: '30 1 * * 6'
push:
branches: [ "main" ]
permissions: read-all
jobs:
analysis:
runs-on: ubuntu-latest
permissions:
security-events: write
id-token: write
steps:
- uses: actions/checkout@v4
with:
persist-credentials: false
- uses: ossf/scorecard-action@v2
with:
results_file: results.sarif
results_format: sarif
publish_results: true
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarif
Because it emits SARIF, the findings land in the GitHub Security tab alongside your other code-scanning alerts, which keeps everything in one place.
Where Scorecard fits in a supply chain program
Scorecard is a triage and monitoring signal, not a full security program. It answers "how disciplined is this project?" quickly and consistently. Pair it with a vulnerability scanner that answers "what known CVEs are in the versions I actually use?" — the two are complementary. Scorecard tells you a dependency is well maintained; an SCA scanner tells you whether the specific version in your lockfile has an open advisory. An SCA tool such as Safeguard can also flag transitive dependencies that a repo-level score never inspects.
Use Scorecard at adoption time to vet a new dependency, run it on a schedule against your own repos to catch posture drift, and treat a sudden drop in the Maintained or Vulnerabilities check as a prompt to reassess. For a broader grounding in supply chain fundamentals, the Safeguard Academy has background on the risks these checks are designed to surface.
FAQ
Is OpenSSF Scorecard free?
Yes. Scorecard is an open source project under the Open Source Security Foundation, and both the CLI and the GitHub Action are free to use. You only need a GitHub token to raise API rate limits when scanning public repositories.
What is a good OpenSSF Scorecard score?
As a rough guide, an aggregate of 7 or higher indicates a project following strong security practices, while low single digits warrant closer scrutiny. Always read the per-check breakdown, because a good average can mask a failing high-risk check like Branch-Protection or Dangerous-Workflow.
Does a high Scorecard score mean the code has no vulnerabilities?
No. Scorecard measures maintenance and process hygiene, not the absence of bugs. A disciplined project can still ship a vulnerable version, so pair Scorecard with a vulnerability scanner that inspects the exact versions you depend on.
Can Scorecard check private repositories?
The tooling is designed primarily for public repositories and the public dependency ecosystem. You can run the action inside your own repository regardless of visibility, but the public registry and many checks assume publicly inspectable metadata.