The OpenSSF Criticality Score is a number from 0 to 1 that estimates how influential an open source project is. It is not a security rating. A high score means many people depend on a project, so a flaw there would matter more. The public data pipeline behind it has stopped running.
What it measures
The project's README describes a score built on an algorithm by Rob Pike, and labels the tool Beta. Its goal is to find the projects the community depends on most, so security effort can go where it counts.
The signals it combines include:
- Positive: project age, number of contributors (heavily weighted), distinct contributing organizations, weekly commit frequency, releases in the past year, issues closed and updated in the last 90 days, comments per issue, and dependents.
- Negative: time since the last update, which lowers the score for unmaintained projects.
Dependents are counted through project mentions in commit messages, and they carry heavy weight too.
Criticality is not quality
This is the point people miss. A project can be critical and poorly defended, or obscure and carefully built. The score answers "how much would it hurt if this broke" and not "is this safe to use".
| Question | Criticality Score | Scorecard | Your own review |
|---|---|---|---|
| How widely depended on is it? | Yes | No | Partly |
| Does it follow security practices? | No | Yes | Yes |
| Is it right for your use? | No | No | Yes |
So do not pick between two libraries because one has a higher criticality number. Use it to decide how much scrutiny a dependency deserves: the more critical a package is to your product, the more checks you should run before and after you adopt it.
Current status
The README is explicit about operations. It says the public infrastructure has not been running since May 2026, the last successful run was in July 2025, and the Google Cloud Storage and BigQuery datasets stopped being available in August 2026. The latest data lives in the repository's data directory. The repository is still maintained by the OpenSSF Vulnerability Disclosures Working Group and is not marked deprecated.
In practice that means any number you find may be a year old. If a vendor or blog quotes a criticality figure, ask when it was computed.
What to do instead
- Build your own criticality view: which dependencies sit in your production path, handle untrusted input, or touch secrets.
- Rank them by that exposure. Reachability analysis helps here, because it shows whether your code actually calls the vulnerable function.
- Spend the deepest checks, such as audit history, release practice and bus factor, on the top of that list.
- Use fresher inputs for health, such as recent release dates and open advisories.
Try it yourself
Open the demo and see how reachability separates findings your code can hit from the rest. That is one way to rank your own critical packages.
Click through it at your own pace, or open it full screen.
Quick check
Does a high Criticality Score mean a package is safe?
No. It estimates influence, not safety. A highly depended on package can still have weak practices.
Is the score still updated publicly?
According to the README, the public infrastructure has not run since May 2026, with the last successful run in July 2025. Treat any figure as possibly dated.
Safeguard's reachability analysis shows which vulnerable code in your dependencies your application can actually reach, which is a practical way to rank your own critical packages. You can start with the free scan.
Sources
Last reviewed: 19 October 2026.
