By Rushabh Shah, Senior Software Developer · 2026-07-10
The OpenSSF Scorecard is an automated tool from the Open Source Security Foundation (OpenSSF) that grades an open-source project's security hygiene on a scale of 0–10. Each score is backed by up to 18 discrete checks — things like whether the project enforces branch protection, uses dependency pinning, runs CI on every PR, signs its releases, or has run a security audit. The score doesn't tell you whether the code is vulnerability-free; it tells you how mature the development process is. A project with strong Scorecard signals is harder for an attacker to hijack, and faster to respond when a vulnerability does appear.
Maintained — has the project had a commit, PR or issue response in the last 90 days? An unmaintained project won't patch its own vulnerabilities.
Code-Review — are changes reviewed before merge? The check counts how many recent commits went through a formal pull-request review. Merged-without-review code is a social engineering target (see the xz-utils attack).
Branch-Protection — are default and release branches protected from direct pushes? Unprotected branches let a compromised maintainer account ship malicious code without a paper trail.
CII-Best-Practices — has the project earned a Core Infrastructure Initiative badge? A silver badge indicates the project follows documented secure-development processes.
Security-Policy — does the project have a SECURITY.md or equivalent? Without one, researchers don't know how to privately report vulnerabilities.
Signed-Releases — are release artefacts (tarballs, binaries) signed? A signed release lets downstream consumers verify they received the authentic artefact, not a compromised mirror.
Token-Permissions — do GitHub Actions workflows request the minimum GitHub token permissions? Overly broad tokens (e.g., write-all) let a compromised workflow modify any repo content.
Binary-Artifacts — are there committed binaries in the repository? Binary blobs can contain backdoors and can't be audited via code review.
Pinned-Dependencies — do CI workflows pin dependency versions (including Actions) to a commit hash? An unpinned uses: actions/checkout@v3 can be mutated by a tag repoint.
Dangerous-Workflow — do workflows use dangerous constructs like pull_request_target with unsafely interpolated expressions? These are the class of vuln that led to the Codecov and tj-actions supply-chain attacks.
Dependency-Update-Tool — is Dependabot or Renovate configured? Automated dependency updates reduce the window between a vulnerability disclosure and a patch landing.
CI-Tests — do CI checks run on all PRs and do they all pass? Projects that don't enforce green CI ship broken code faster and with less discipline.
Fuzzing — is the project enrolled in a fuzzing program (OSS-Fuzz, Google ClusterFuzz, or via FuzzedDataProvider)? Fuzzing is the most effective technique for finding memory-safety bugs in C/C++.
SAST — does CI run a static analysis tool? Automated SAST catches injection, path traversal, XSS and hardcoded credentials at commit time.
License — does the repo have a recognisable open-source license? Unlicensed code is legally unusable.
Packaging — are release artefacts published to a package manager? Consistent, automated releases reduce the chance of a release being hijacked or swapped.
Webhooks — are repository webhooks configured with secrets? An unsecured webhook can be replayed by an attacker to trigger CI builds on arbitrary code.
Vulnerabilities — are there unpatched vulnerabilities in the project's own dependencies (from OSV)? This is the only check that directly queries the vulnerability database.
Every component DepWarden scans is enriched with its Scorecard score from deps.dev. A score below 5 generates a LOW finding; below 3, a MEDIUM finding. The finding links directly to the component's Scorecard report so you can see which specific checks failed and decide whether the project's risk profile is acceptable for your use case. Related: software composition analysis, detect typosquats in CI, CVSS, EPSS and KEV guide.