OpenSSF Scorecard explained: catching risk in packages that don't have a CVE yet

Most dependency scanners only tell you about vulnerabilities that already have an advisory filed against them. That's useful, but it's inherently reactive — it only catches risk after someone has found and disclosed it. OpenSSF Scorecard takes a different angle: instead of asking "has this package been proven vulnerable," it asks "does this package show the hygiene signals of a project that's actively maintained and hard to compromise." That second question catches risk earlier, before an incident, not after one.

What Scorecard actually measures

Scorecard runs a set of automated checks against a project's public repository and CI configuration and produces a score from 0–10 across roughly 18 checks. The ones that matter most for supply-chain risk:

• Maintained — has the project had commits or releases in the last 90 days, or is it effectively abandoned?
• Branch protection — can a single compromised maintainer account push directly to the default branch, or does it require review?
• Code review — are changes actually reviewed by someone other than the author before merging?
• Dangerous workflow — does the CI configuration have script-injection patterns or run untrusted code with write access to secrets?
• Pinned dependencies — are the project's own build dependencies pinned to a hash, or can a compromised upstream silently change what gets built?
• Vulnerabilities — does the project have known, unfixed vulnerabilities of its own?
• Token permissions — does CI use the principle of least privilege for its tokens, or does everything run with full write access?

Each check is a proxy for a real incident pattern. Branch protection and code review are the checks that would have made the XZ Utils backdoor (introduced via a subtly malicious commit from a trusted-looking maintainer account) meaningfully harder to slip in. Dangerous workflow and token permissions are the checks that catch the GitHub Actions script-injection class of attack that's been used to steal CI secrets from dozens of popular projects.

Why this matters even without a CVE

A package with a low Scorecard score isn't necessarily compromised right now — it's a package where, if something goes wrong, there's less standing between an attacker and your build. An unmaintained package with no branch protection and a single maintainer is a soft target: if that maintainer's account is phished, or they sell the package to someone with bad intent (a real, repeated pattern in the npm ecosystem), there's no review process to catch a malicious release before it reaches you. None of that shows up as a CVE until after it happens.

Reading a score in context

A 10/10 score is rare and not the bar to hold every dependency to — plenty of excellent, safe packages score lower simply because they're small, stable, and don't need elaborate CI. What matters is using the score as a relative signal: a sudden drop in a package you depend on, a very low score on a package with broad reach in your tree, or a low score combined with a package that hasn't been touched in years, are the combinations worth actually looking at. Scorecard is a triage signal, not a verdict.

How DepWarden uses it

DepWarden surfaces Scorecard health alongside every dependency in a scan, so a package's maintenance risk sits next to its vulnerability findings instead of requiring a separate lookup. Combined with deprecation markers and end-of-life release-line detection, it's part of the "risk that has no CVE yet" picture DepWarden shows before it bites — the same category of signal that catches typosquatting and dependency confusion.

Related: detect typosquats and dependency confusion in CI, software composition analysis, transitive dependencies explained.