CVSS, the scoring system FIRST.org has maintained since 2005, tells you what a vulnerability could do if exploited — attack vector, complexity, privileges required, blast radius — collapsed into a single number from 0 to 10. It does not tell you whether anyone has bothered to exploit it, or ever will. That gap has real consequences: CISA's Known Exploited Vulnerabilities (KEV) catalog, which launched in November 2021 with roughly 291 entries, has grown past 1,300 CVEs as of mid-2026, with new confirmed-exploitation additions published multiple times a week. Every one of those entries is proof, not prediction — CISA only adds a CVE once it has evidence of active exploitation in the wild. Meanwhile the average enterprise vulnerability backlog runs into the thousands, and teams that triage purely by CVSS severity end up patching plenty of 9.8s that no attacker has ever touched while missing lower-scored flaws already under active attack. The industry has started splitting this into two distinct questions: is a vulnerability theoretically exploitable, and has it been demonstrated as breakable against something real? This post lays out the difference precisely, the data sources that measure each side, and a scoring rubric that combines them with reachability and business context so a security team can rank a backlog by actual risk instead of theoretical severity.
What's the actual difference between exploitability and breakability?
Exploitability is a property of the vulnerability in the abstract — does a code path exist that an attacker could theoretically reach and abuse, given the right conditions. Breakability is empirical: has someone actually built and fired a working exploit against this specific vulnerability, in this configuration, and gotten a result. A CVSS 9.8 remote code execution flaw is exploitable by definition — the scoring rubric says so — but it may sit for years with zero public proof-of-concept and zero observed attacks. Contrast that with a CVE the CISA KEV catalog lists: by definition, that means real attackers have already run a working exploit against real targets. The term "breakability" shows up increasingly in vendor and practitioner discourse specifically to name this second, evidentiary category, separate from the theoretical scoring that CVSS was built for. Confusing the two leads teams to treat every high-CVSS finding as equally urgent, when in practice the exploited ones deserve emergency response and the merely-exploitable ones can often wait for the next patch cycle.
Why isn't a high CVSS score itself evidence of real-world danger?
CVSS was explicitly designed to score severity, not likelihood — FIRST.org's own specification separates "base" metrics (attack vector, complexity, privileges, impact) from temporal and environmental metrics that account for real-world exploit maturity, and most organizations only ever look at the base score. That means a 9.8 and a 9.8 can represent wildly different real risk: one might require an unauthenticated network attacker with no user interaction, while a functionally identical score can attach to a flaw nobody has found a practical way to trigger outside a lab. CVSS also says nothing about whether the vulnerable function is ever called by your specific deployment, whether the affected component is internet-facing, or whether any attacker has bothered building tooling for it. Treating CVSS as a complete prioritization signal is why so many security teams accumulate multi-thousand-item backlogs sorted by a number that measures only "how bad if" — not "how likely" or "how proven."
What does EPSS actually predict, and where does it fall short?
EPSS, the Exploit Prediction Scoring System also maintained by FIRST.org, estimates the probability — expressed as a percentage — that a given CVE will be exploited in the wild within the next 30 days, using a machine learning model trained on observed exploitation signals like exploit-code publication, scanner activity, and dark-web chatter. It's a genuine improvement over CVSS for prioritization because it's forward-looking and probabilistic rather than static. But it is a forecast, not proof, and its timing can undercut the "early warning" premise. Nucleus Security studied a sample of CVEs added to CISA's KEV catalog between October 2025 and March 2026 and found that the median EPSS score movement was roughly 121 times larger in the days after KEV listing than before it — with most of that movement concentrated in the 72 hours right after CISA confirmed exploitation. In other words, for the vulnerabilities they examined, EPSS mostly reacted to confirmed exploitation rather than predicting it ahead of time. EPSS is directionally useful and worth weighting heavily, but it cannot substitute for confirmed exploitation data, and treating a low EPSS score as a green light to deprioritize a patch is not a safe assumption.
What counts as confirmed proof that a vulnerability is breakable?
The clearest, most conservative signal is CISA KEV membership itself — CISA adds a CVE only after collecting evidence of documented, in-the-wild exploitation, not just theoretical risk. Beyond KEV, publicly available exploit tooling is a strong secondary signal: a CVE with a working Metasploit module or an ExploitDB entry has crossed from "someone could write an exploit" to "an exploit already exists and is trivially reusable," which meaningfully lowers the skill bar for any attacker who finds the same door. A third tier is credible proof-of-concept code published by researchers without confirmed in-the-wild use — informative, but a step below KEV-grade evidence since a PoC against a lab environment doesn't guarantee it works against your specific patch level, WAF, or network segmentation. None of these signals are mutually exclusive; the strongest triage decisions weight KEV membership highest, treat exploit-kit availability as a serious escalator, and use a lone research PoC as a reason to investigate rather than an automatic fire drill.
How should reachability and business context factor into the rubric?
Exploitability and breakability answer "could this be attacked, and has it been demonstrated" — but neither answers "can an attacker reach this in my environment." Reachability analysis builds a call graph from your actual entry points down through your dependencies and checks whether execution can ever hit the vulnerable line; if it can't, even a KEV-listed CVE in an unreachable code path may be a lower priority than a moderate-severity flaw sitting on a live request path. Business context closes the loop: the same vulnerable library behaves completely differently depending on whether it's running on an internet-facing payment service handling card data or an internal batch job with no network exposure. A workable rubric scores each finding across five inputs — CVSS (severity ceiling), EPSS (likelihood forecast), KEV/exploit-kit status (confirmed breakability), reachability (is the path live), and business context (asset criticality, data sensitivity, exposure) — and lets a KEV hit on a reachable, internet-facing, high-sensitivity asset always outrank a high-CVSS finding that's unreachable and internal, regardless of raw severity number.
How Safeguard helps
Safeguard's Griffin AI prioritization scores every vulnerability across three of these same dimensions rather than collapsing everything into one severity number: Exploitability (EPSS score, CISA KEV membership, and public exploit availability), Reachability (call-path analysis, runtime context, and configuration impact), and Business Context (asset criticality, data sensitivity, and exposure level). Vulnerability data is aggregated continuously from NVD, GitHub Security Advisories, OSV, CISA KEV, and vendor bulletins, so a CVE's KEV status and EPSS score are already attached the moment it's ingested rather than requiring a separate lookup. Because reachability is computed from the actual call graph rather than assumed, a theoretically exploitable finding in dead code doesn't crowd out a moderate-severity flaw an attacker can actually reach — and teams can query in plain language, like asking Griffin AI to show critical vulnerabilities in production that are actively exploited, to turn a five-input rubric into a single ranked action list instead of a spreadsheet exercise.