CVSS 9.8 Is Not Priority: Triage with EPSS + KEV

Q: Why is sorting my patch queue by CVSS a mistake?

Because CVSS measures severity — how bad the damage would be if a vulnerability were exploited — and says nothing about whether it is actually being exploited or ever will be. When you sort your patch queue by CVSS, you are sorting by hypothetical worst-case impact, which means you spend your finite patching capacity on vulnerabilities in descending order of how scary they sound rather than how likely they are to hurt you. The scale of the problem makes this acute: the National Vulnerability Database adds over 28,000 CVEs a year, roughly 77 a day, and a large fraction of the ones rated critical are never weaponised by anyone. So a CVSS-sorted queue is full of high-severity vulnerabilities that pose no real-world risk, while a medium-severity vulnerability that is actively being exploited sits lower down waiting. The result is the familiar failure mode where a team patches frantically, closes thousands of criticals, and still gets breached through something they deprioritised because its CVSS was only a 6. The fix is not to abandon CVSS but to stop using it as the sort key. CVSS should describe impact once you have already decided something is worth fixing; the decision about what to fix first should be driven by exploitation likelihood and confirmation, which are different questions that CVSS was never designed to answer.

Q: What is EPSS and how does it differ from CVSS?

EPSS, the Exploit Prediction Scoring System maintained by FIRST, answers a fundamentally different question from CVSS. Where CVSS tells you how severe a vulnerability impact would be, EPSS tells you how likely the vulnerability is to be exploited in the wild within the next 30 days, expressed as a probability from 0 to 1, along with a percentile that ranks it against every other CVE. A percentile of 0.98, for example, means the vulnerability is more likely to be exploited than 98 percent of all other CVEs. EPSS v4, released in March 2025, is a data-driven model trained on real-world exploitation signals, and it achieves a ROC AUC of about 0.84, meaning it correctly distinguishes exploited from non-exploited vulnerabilities roughly 84 percent of the time. The crucial distinction is that CVSS is a static assessment of potential impact assigned when the vulnerability is analysed, while EPSS is a dynamic, forward-looking estimate of probability that updates as the threat landscape changes. They are complementary rather than competing: EPSS helps you decide what is likely enough to be worth acting on, and CVSS helps you understand how much it would matter if that action came too late. The common error is to treat EPSS as a replacement for CVSS or as a statement of certainty — it is neither. It is a probability, it can lag very fresh exploitation, and it is at its most powerful when combined with CVSS for impact and the CISA KEV catalog for confirmed exploitation.

Q: What is the CISA KEV catalog and why does it matter?

The CISA Known Exploited Vulnerabilities catalog is a list, maintained by the US Cybersecurity and Infrastructure Security Agency, of vulnerabilities that have been confirmed to be exploited in the wild — meaning a human at CISA has verified real-world active exploitation, not merely predicted it. That confirmation is what makes KEV the ground truth that EPSS, as a predictive model, cannot provide. Anything on the KEV catalog should be treated as a drop-everything item regardless of its CVSS severity or its EPSS probability, because it is not a question of whether it might be exploited — it is being exploited right now. The practical power of KEV is that it turns a probabilistic guessing game into a definite signal for a subset of vulnerabilities, and wiring the KEV feed directly into your prioritisation pipeline so that a newly-listed CVE present in your environment triggers an emergency response is one of the cheapest, highest-value automations in vulnerability management. It has honest limits too. KEV is not exhaustive — a vulnerability being absent from it does not prove it is not being exploited, only that CISA has not confirmed and listed it — and it can lag for very fresh, recently-weaponised vulnerabilities. In fact EPSS scores are often observed to jump sharply only after a CVE lands on KEV rather than reliably before, which is precisely why KEV and EPSS should be used together: KEV gives you confirmed exploitation, and EPSS gives you a forward-looking probability for everything not yet confirmed.

Q: How do I combine CVSS, EPSS, and KEV into one prioritisation decision?

Use each for the question it answers and combine them into a decision matrix, with exploitation leading and severity weighting. The single most important change is to invert the usual sort order: instead of leading with CVSS severity, lead with the exploitation signals. First, check KEV — anything confirmed exploited in the wild bypasses normal triage and goes straight to an emergency patch SLA, no discussion. Second, for everything not on KEV, sort by EPSS probability, because that tells you what is most likely to be exploited soon. Third, within the high-exploitation set, rank by CVSS impact and by asset criticality and exposure, because among vulnerabilities that are likely to be exploited you should fix the ones that would hurt most and that sit on your most exposed, most important assets. Concretely, a medium-CVSS vulnerability with a high EPSS score on an internet-facing critical asset should outrank a CVSS 9.8 with a near-zero EPSS on an internal box that nobody can reach — the reverse of what a severity-sorted scanner would tell you. The mental model is that KEV and EPSS decide whether something belongs in the urgent set at all, and CVSS plus your own asset context decide the ordering within that set. This combined approach is what lets a team with finite patching capacity and 77 new CVEs a day actually direct effort at the vulnerabilities that are being or are likely to be exploited, rather than at whatever happens to have the highest severity number.

Q: Does a high CVSS score always mean I should patch immediately?

No, and treating every high CVSS score as a drop-everything emergency is exactly the behaviour that overwhelms vulnerability-management programmes. A high CVSS, such as a 9.8, tells you the vulnerability would be severe if exploited, but most high-severity CVEs are never actually weaponised, so patching all of them immediately means spending your scarce remediation capacity on hypothetical risk while genuinely exploited vulnerabilities wait. The correct response to a high CVSS is to ask two further questions before deciding urgency. First, is it on the CISA KEV catalog — is it confirmed to be exploited in the wild? If yes, then regardless of anything else it is an emergency. Second, what is its EPSS probability — how likely is exploitation in the near term? A CVSS 9.8 with a near-zero EPSS score and no KEV listing is a vulnerability that is severe in theory but that current data suggests almost nobody is exploiting, so it belongs in your normal patch cycle rather than an emergency one. Conversely, a lower CVSS with a high EPSS or a KEV listing deserves urgent attention despite its modest severity number. There is an important nuance: severity still matters for the impact dimension, so once you have established that something is likely or confirmed to be exploited, a higher CVSS and a more critical asset should push it up the queue. The point is not that CVSS is useless — it is that CVSS answers how much it would hurt, not how likely it is, and urgency requires both.

Q: What are the honest limitations of EPSS and KEV?

Both are powerful but neither is complete, and understanding their limits is what stops you from trading one blind spot for another. EPSS is a predictive probability, not a statement of fact: a score is the model estimate of exploitation likelihood in the next 30 days, so a low EPSS means unlikely, not impossible, and acting as though a low score guarantees safety will eventually miss something. EPSS can also lag very fresh exploitation, because the model learns from observed signals that take time to accumulate — a brand-new, rapidly-weaponised vulnerability may not yet carry a high score. KEV has the complementary limitation: it is authoritative for what it contains, since every entry is human-confirmed active exploitation, but it is not exhaustive, so a vulnerability being absent from KEV proves only that CISA has not confirmed and listed it, not that it is safe. KEV also lags for the newest zero-days, and it has been observed that EPSS scores frequently jump only after a CVE is added to KEV rather than reliably predicting the listing in advance. The practical conclusion from these limits is that you must use EPSS and KEV together rather than relying on either alone, and you must layer your own environmental context on top — a vulnerability probability is population-level and does not know whether your particular instance is internet-facing or buried behind three network controls. The mature posture treats these tools as strong, data-driven inputs to a decision that still incorporates confirmed exploitation, predicted probability, impact severity, and your own asset exposure, rather than as a single oracle that removes the need for judgement.

Q: How should I set patch SLAs using risk-based prioritisation?

Replace blanket severity-band SLAs with tiers driven by the combined exploitation-and-impact signal, because a rule like patch all criticals within 15 days is both unmeetable at 77 new CVEs a day and misdirected, since it treats improbable criticals the same as actively-exploited ones. A workable tiered model looks like this. The top tier is anything on the CISA KEV catalog: confirmed exploited, so it gets an emergency SLA measured in hours to a few days and bypasses normal change processes where your risk appetite allows. The next tier is high EPSS probability on an exposed, critical asset: likely to be exploited and impactful, so it gets a tight SLA measured in days. Below that is high CVSS with low EPSS and no KEV listing: severe in theory but currently improbable, so it goes into the normal patch cycle measured in weeks. The lowest tier is low across all axes: batched into routine maintenance. The advantages of this approach are twofold. First, it is actually meetable, because it concentrates urgent effort on a small, genuinely urgent set rather than an impossibly large critical pile, which means the SLAs stop being fiction the team quietly ignores. Second, it is defensible to an auditor, because you can show a data-driven rationale for why each vulnerability received the timeline it did, which maps cleanly onto the risk-based expectations of frameworks like NIS2 and SOC 2. The key discipline is that the tier is determined by exploitation signals first and severity second, not by CVSS band alone.

Q: How does exploitation-based prioritisation apply to the software supply chain?

It applies directly and is arguably even more necessary there, because the volume problem is worse in dependencies than in your own infrastructure. A single application build can pull in hundreds of transitive open-source packages, each carrying its own set of known vulnerabilities, so a naive policy of failing any build that contains a high-CVSS dependency vulnerability produces so many failures that developers learn to bypass the gate entirely, which defeats the purpose. The same exploitation-first prioritisation that works for infrastructure vulnerabilities fixes this. Instead of blocking a build on severity alone, feed EPSS and KEV signals into your CI gates so that a build is blocked on vulnerabilities that are actually being exploited or are highly likely to be, while merely high-severity-but-improbable findings are surfaced for the normal remediation cycle rather than halting delivery. This keeps the gate credible — developers trust it because it fires on genuine risk — and it keeps delivery moving. The approach connects naturally to broader software-supply-chain practices like maintaining an SBOM so you actually know what is in your builds, and to the specific risks introduced by AI coding assistants that may pull in dependencies without scrutiny. The unifying principle across your own systems and your supply chain is identical: with far more known vulnerabilities than anyone can patch, the prioritisation function must be driven by whether something is exploited or likely to be, not by how severe it would be in the abstract, and that principle should govern both your infrastructure patch queue and your build-time dependency gates.

Satyam Kumar

Back to Blog

ai-architecture

CVSS 9.8 Doesn't Mean Fix It First: Prioritising Vulnerabilities with EPSS and KEV

By Satyam KumarAugust 7, 20269 min read

vulnerability management epss cisa kev cvss vulnerability prioritisation exploit prediction patch management risk-based security appsec cve exploitability security operations threat intelligence remediation sla supply chain security 2026

CVSS 9.8 Doesn't Mean Fix It First: Prioritising Vulnerabilities with EPSS and KEV

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

CVSS 9.8 Doesn't Mean Fix It First: Prioritising Vulnerabilities with EPSS and KEV

Frequently Asked Questions

Share this article

Comments

Leave a comment