An enterprise application with 300 dependencies commonly carries 15 to 45 known CVEs at any given moment, and almost every security team still defaults to sorting that list by CVSS score. That instinct is the problem. Kenna Security and the Cyentia Institute analyzed roughly 18,000 CVEs tracked in 2019 and found that only 2.6% were ever actively exploited against real organizations — a figure widely reported after publication in 2021. A follow-up Kenna/Cyentia study went further: 62% of vulnerabilities carry less than a 1% probability of exploitation, while only about 5% exceed 10%. CVSS measures theoretical severity if a flaw is triggered; it says nothing about whether anyone is triggering it, or whether your code even exposes the vulnerable path. The result, at most organizations, is a backlog of hundreds of "critical" tickets and a team that can realistically close a fraction of them each sprint. This piece lays out a triage framework built on three orthogonal signals — exploitability, reachability, and business context — that together turn an unsortable pile of alerts into a ranked, defensible remediation queue, and looks at where each signal comes from, where it breaks down, and how to combine them into a single score.
Why doesn't CVSS alone work as a prioritization signal?
CVSS measures potential impact — what happens if a vulnerability is successfully exploited — not the probability that it will be. Two CVEs can carry the same CVSS 9.8 score while one has a public Metasploit module and active scanning traffic and the other has never been demonstrated outside a lab. The Kenna/Cyentia data makes this concrete: with only 2.6% of tracked 2019 CVEs seeing real exploitation, treating every "critical" CVSS finding as equally urgent guarantees a team spends most of its remediation capacity on the 97%+ that were never going to be attacked. This isn't an argument to ignore CVSS — impact still matters once something is exploitable and reachable — but using it as the sole sort key is why security backlogs balloon into the hundreds while attackers keep succeeding through a small, predictable set of flaws. Prioritization has to start by separating "severe if triggered" from "likely to be triggered," and CVSS alone only answers the first question.
What does EPSS actually measure, and how should teams use it?
The Exploit Prediction Scoring System, maintained by FIRST.org, is a machine-learning model — a gradient-boosted classifier — that outputs a daily-updated probability, from 0 to 1, that a given CVE will be exploited in the wild within the next 30 days. Its inputs include CVE age, CWE category, and observed signals like public proof-of-concept code, exploit-kit inclusion, and scanner activity referencing the CVE. FIRST.org describes EPSS as explicitly complementary to CVSS: CVSS answers "how bad is this if it happens," EPSS answers "how likely is it to happen soon." In practice, teams use EPSS to filter, not just sort — a common policy is to deprioritize findings below an EPSS threshold (e.g., 5%) regardless of CVSS, and escalate anything crossing a higher threshold (e.g., 30-50%) even at moderate severity. Because EPSS updates daily, a CVE's score can jump sharply the week a working exploit is published, which is exactly the signal a static CVSS number can never provide.
What does the CISA KEV catalog add that EPSS doesn't?
CISA's Known Exploited Vulnerabilities (KEV) catalog lists CVEs with confirmed real-world exploitation, not a probabilistic forecast — it's continuously updated, often with multiple new entries added in a single batch. Where EPSS is a prediction, KEV is a fact: if a CVE is listed, someone has already observed it being used in an attack. That distinction matters operationally. KEV membership has driven binding remediation deadlines for U.S. federal agencies since 2021 under CISA's Binding Operational Directive 22-01; that directive was superseded in June 2026 by BOD 26-04, which moves federal patch deadlines to a broader multi-signal, risk-based model (with KEV listing as one input among several, alongside exposure and exploit automation) rather than KEV membership alone, with the highest-risk vulnerabilities now due for remediation within three days. Many private-sector security teams have adopted the KEV catalog as a de facto "must patch immediately" list regardless of which federal directive currently governs it. A sound triage rule treats KEV membership as close to a hard escalation trigger on any exposed or production asset, independent of CVSS or even EPSS score, because the exploitation question has already been answered in the affirmative. EPSS and KEV are best used together: EPSS to forecast tomorrow's exploited CVEs, KEV to confirm today's.
How does reachability change what "exploitable" means for your specific code?
Exploitability signals like EPSS and KEV describe a CVE in the abstract; reachability analysis answers whether your code can actually execute the vulnerable function at all. A standard software composition analysis (SCA) scan matches a lockfile against a CVE database and reports every vulnerable package present, whether or not your application ever calls the affected code path. Reachability analysis instead builds a call graph — statically from source and bytecode, or dynamically by instrumenting a running workload — and checks whether execution can reach the vulnerable sink. This is a distinct, complementary axis to exploitability, not a substitute: a CVE can be both KEV-listed and completely unreachable in your build, or reachable but with no known exploit yet. Combining the two is where the real noise reduction happens. In practice, reachability filtering alone commonly removes 60-80% of findings from an "urgent" queue, since most flagged CVEs in a typical dependency tree sit in code paths the application never invokes.
How does business context turn a technical score into a remediation order?
Business context is the layer that decides which of the remaining, exploitable-and-reachable findings gets fixed this week versus next quarter. The same reachable, KEV-listed CVE in a production, internet-facing service handling customer PII is a fire drill; the identical finding in an air-gapped internal tool with no sensitive data is a ticket. A workable framework tags every asset along four dimensions: environment (production vs. staging vs. dev), exposure (internet-facing vs. internal), data sensitivity (regulated or customer data vs. public), and business criticality (revenue-path or compliance-scoped systems). None of these labels are new ideas individually — asset criticality has been a risk-management concept for decades — but few vulnerability programs actually wire them into the same score as EPSS, KEV, and reachability. Doing so is what converts "we have 40 KEV-listed CVEs" into "we have 3 KEV-listed, reachable CVEs on internet-facing production services holding customer data," which is a queue a team can actually clear.
How do you combine these signals into one score without losing information?
The practical answer is a weighted composite rather than any single signal acting as a gate, because gates hide risk. A finding that's unreachable today can become reachable after a refactor, and a CVE with no PoC today can get one tomorrow — so the framework needs to re-score continuously, not just at scan time. A reasonable structure ranks reachable + KEV-listed + production findings at the top of the queue, reachable + high-EPSS + production next, reachable-but-lower-severity findings in staging below that, and pushes unreachable findings of any severity to a low-priority backlog rather than deleting them outright — reachability analysis is probabilistic in cases involving reflection, dynamic dispatch, or eval-style execution, so conservative defaults matter more than aggressive suppression. Malware and secrets findings are a deliberate exception to any suppression logic: they should always surface in full regardless of dedup or reachability scoring, since a live credential leak or malicious package doesn't wait for a call graph to confirm it's dangerous. Safeguard implements this composite approach directly — its prioritization engine scores findings 0-100 from reachability class, EPSS, KEV status, and the same environment/exposure/data-sensitivity/criticality context described above, and its AutoTriage layer deduplicates overlapping findings across scanners while explicitly guaranteeing it never suppresses malware or secrets findings, so noise reduction never comes at the cost of the alerts that matter most.