VaultScore: how we prioritize vulnerabilities (and why CVSS isn't enough)
Every security team has the same conversation. The dashboard shows 847 critical vulnerabilities. Engineering has time to fix maybe 12 this sprint. Which 12?
CVSS — the Common Vulnerability Scoring System — was supposed to answer that. It doesn't. CVSS is a measure of theoretical impact under worst-case assumptions. It tells you a vulnerability is bad. It does not tell you it is bad for you.
What VaultScore adds
VaultScore combines four signals into a 0–10 score that reflects real-world risk:
- CVSS base score — the underlying severity (still useful as a floor)
- EPSS — the FIRST.org probability that the vulnerability is exploited in the next 30 days
- CISA KEV catalog — is it being actively exploited right now?
- Reachability — based on your source, is the vulnerable package actually imported/used in code you ship?
Why reachability matters
A CVSS 9.8 in a transitive dependency you never import is not a 9.8 risk to you. It might be a 2. We trace your import/require graph to tell the difference.
Conversely, a CVSS 6.5 in a library that handles untrusted user input on your authentication path can be the most urgent fix in your queue.
VaultScore weights reachability heavily, because it's the signal that actually changes what your team should do this week. Today this is import-level — whether the vulnerable package is reachable at all from code you ship. Function-level call-graph reachability — tracing whether the specific vulnerable function is called — is on our roadmap.
What we don't do
We don't pretend VaultScore replaces human judgment. The score gets you a sorted queue. The decisions about what to patch, what to compensate, and what to accept are still yours. But starting from a sorted queue beats starting from 847 unsorted "criticals."