A security dashboard that reports "1,847 open vulnerabilities" tells you almost nothing about your actual risk, because fewer than 5% of published CVEs are ever exploited in the wild. That single number is the AppSec equivalent of a hospital reporting total patient count instead of who's in critical condition. FIRST.org built the Exploit Prediction Scoring System (EPSS) specifically to close this gap: it's a machine-learning model that scores every published CVE from 0.0 to 1.0 for the probability it will be exploited within the next 30 days, and it recalculates those scores daily as new exploit telemetry comes in. Research from FIRST and Cyentia has quantified just how inefficient count-based and even CVSS-based triage really is: patching every CVE with a CVSS score of 7 or higher catches 82% of vulnerabilities that go on to be exploited, but it also means spending roughly 96% of remediation effort on CVEs that were never going to be exploited at all. Prioritizing by EPSS instead — even at a modest 10% threshold — catches 63% of exploited vulnerabilities with a fraction of that wasted effort. This post lays out why raw counts and severity scores alone keep failing, and what a risk-based alternative actually looks like in practice.
Why is a raw vulnerability count such a misleading metric?
A raw count treats a critical remote-code-execution flaw in an internet-facing payment service identically to a low-severity issue in an internal batch job nobody has touched in a year — it collapses every dimension of risk into a single undifferentiated tally. Two teams can report the same number, 500 open vulnerabilities, and have wildly different actual exposure: one team's 500 might include a dozen CVEs with confirmed active exploitation and internet-facing reachable code, the other's might be entirely in dead code paths and test dependencies. Raw counts also create a perverse incentive: they reward closing easy, low-risk tickets to move the number down, rather than fixing the handful of findings that matter. Because well under one in twenty CVEs is ever exploited in practice, a metric that weights all CVEs equally is, by construction, dominated by noise. Any AppSec program that reports "vulnerabilities open" as its headline KPI is optimizing for a number that has a weak relationship to actual breach risk.
Why isn't CVSS severity alone a sufficient fix?
CVSS measures theoretical severity — how bad a flaw could be if exploited — not the probability that anyone will bother exploiting it, and the FIRST/Cyentia data above shows exactly what that gap costs in practice: an 82%-catch-rate strategy that burns 96% of effort on CVEs nobody ever weaponizes. CVSS also can't see your environment. A 9.8-rated deserialization bug in a library your application imports but never calls carries essentially zero real-world risk, while a "medium" 5.3 flaw sitting on an unauthenticated, internet-facing login endpoint can be the one an attacker actually uses. This is exactly the gap CISA's Known Exploited Vulnerabilities (KEV) catalog was built to close: CISA adds newly confirmed-exploited CVEs to KEV on a rolling basis, often multiple times a week, specifically because CVSS and NVD severity scores don't tell defenders which vulnerabilities are being used in real attacks right now. KEV membership is a distinct, verifiable signal — "this is being exploited," full stop — that a static severity score was never designed to capture.
What does exploitability data actually add to prioritization?
Exploitability data answers the question CVSS can't: is anyone actually attacking this, or likely to soon? EPSS gives a probabilistic, constantly-updated answer for every CVE, while CISA KEV gives a binary, confirmed answer for the subset already seen in active campaigns. Used together, they let a team draw a much sharper triage line than "fix everything above CVSS 7." The FIRST/Cyentia comparison is the clearest evidence for this: EPSS-based triage at even a 10% probability threshold captures the majority of eventually-exploited CVEs (63%) while sidestepping most of the wasted effort that CVSS-only triage incurs. Neither signal is meant to stand alone — EPSS is probabilistic and can miss slow-burn or targeted exploitation, and KEV only lists what's already confirmed — but combined they replace "how scary does this sound" with "how likely, and how proven, is this to be used against us."
Why do exploitability scores alone still miss the mark?
Exploitability tells you what attackers want to use; it says nothing about whether your specific application exposes the vulnerable code path at all. A CVE with a high EPSS score in a dependency your build pulls in transitively, but whose vulnerable function your code never calls, still isn't exploitable against you — no attacker can reach code that never executes. This is where reachability and call-path analysis complete the picture: they trace whether execution can actually flow from an entry point to the vulnerable line, cutting through the large share of SCA findings that sit in dead or unreachable code. Runtime context matters too — a flaw behind a disabled feature flag, or one that only fires in a development configuration your production build never ships, isn't a live risk today even if the EPSS score is high. Exploitability without reachability tells you what's dangerous in the abstract; reachability is what tells you whether that danger applies to the software you actually run.
How does business context change what counts as "urgent"?
The same reachable, actively-exploited vulnerability can be a page-the-on-call-engineer emergency or a next-sprint ticket depending entirely on what it's attached to. Business context asks three practical questions: how critical is the affected asset, what kind of data does it touch, and is it exposed to the internet or only reachable from inside a trusted network? A confirmed KEV entry, reachable in code, on an internet-facing service that processes customer payment data is categorically more urgent than the identical CVE, equally reachable, on an internal admin tool with no external exposure and no sensitive data in scope. Without this layer, even a perfect exploitability-plus-reachability pipeline still ranks findings as if every asset in the environment were equally valuable to defend — which is rarely how a real breach's blast radius, or a real incident's cost, actually plays out.
What does a combined risk-based pipeline look like in practice?
A risk-based pipeline layers exploitability, reachability, and business context on top of severity data pulled from multiple sources — NVD/CVSS for baseline severity, EPSS for exploit probability, CISA KEV for confirmed exploitation, and GitHub Security Advisories or OSV for broader ecosystem coverage — rather than relying on any single feed. This multi-source pattern is now standard across the industry, not a single vendor's invention. Safeguard's ESSCM platform implements this directly: Griffin AI scores every vulnerability against exploitability (EPSS, CISA KEV, public exploit availability), reachability (call-path analysis, runtime context, feature-flag state), and business context (asset criticality, data sensitivity, internet exposure), aggregating findings from NVD, GHSA, OSV, CISA KEV, and vendor bulletins into one prioritized view. The output isn't a shorter list dressed up to look better — it's a re-ranked one, where the vulnerability at the top is there because it's exploitable, reachable, and dangerous to something that matters, not because it happened to score highest on a scale that was never built to answer that question alone.