Not by itself. A low OpenSSF Scorecard score means the repository lacks certain security practices, such as branch protection or signed releases. It does not mean the code contains a vulnerability. Read the individual checks, weigh the ones tied to your risk, and combine them with vulnerability data before deciding.
Myth versus fact
Myth: a score under 5 means do not use it. Fact: Scorecard's own FAQ says it focuses on overall security posture and best practices, not on detecting existing vulnerabilities. A one maintainer project can lose points on checks that assume a team and still be carefully written.
Myth: a score over 8 means it is safe. Fact: the documentation says the checks are heuristics with false positives and false negatives. A high score shows good habits, not a clean codebase.
Which low checks matter more
Scorecard weights checks by risk, and the documentation lists the levels. Some low scores deserve more attention than others.
- Dangerous-Workflow (Critical): flags GitHub Actions patterns that run untrusted pull request code or inject untrusted input into scripts. A failure here means an attacker's pull request could reach secrets or write access.
- Token-Permissions (High): workflow tokens that are not read-only by default widen the damage of any compromised step.
- Branch-Protection and Code-Review (High): weak scores mean changes can land without a second person. That matters for trust in future releases.
- Vulnerabilities (High): this check uses OSV to find open, unfixed vulnerabilities, so it is closer to actual risk than most.
Which low checks matter less
Contributors and CI-Tests are Low risk. The Contributors check looks for contributors from several companies, which a healthy small project may never meet. Fuzzing and CII-Best-Practices are also optional extras for many libraries.
The Maintained check needs context. The documentation says no fix is required for a low score, and that a low result is a prompt to investigate. A stable, finished library can look quiet without being neglected, but a quiet project with open vulnerability reports is a real concern.
A short decision rule
- Open the detail view instead of the aggregate.
- Note failures on Critical and High checks.
- Check whether the version you use has known vulnerabilities, and whether your code reaches them.
- Look at the maintainer situation: how many people can publish, and whether releases are made from CI.
- Decide whether the dependency is replaceable. A weak score on a package you can swap out in an afternoon is cheaper to act on than on one woven into your core.
Safeguard's reachability analysis and dependency scanning help with step 3, since a known vulnerability that your code never calls is a different priority from one on a hot path.
Quick check
Should I block packages under a fixed score in CI?
A hard numeric cutoff tends to create noise. Gating on specific Critical and High checks, with an exception path, matches the risk better.
Sources
Last reviewed: 19 October 2026.
