Triage CVEs by exploitation, not just severity

Every scanner report arrives sorted the same way: CVSS descending, a wall of red, most of it "critical". The team patches from the top, runs out of window somewhere in the middle, and rolls the rest to next month. Meanwhile the breach reports keep featuring vulnerabilities rated 7-point-something. The sort key is the problem.

What CVSS actually measures — and what it does not

CVSS is an impact and exploitability characterisation: given this vulnerability, how bad is it if someone exploits it, and how hard is the exploitation in principle? It is a property of the vulnerability in the abstract — network-reachable, low complexity, no privileges, high impact on all three axes — computed without any knowledge of whether a working exploit exists, whether anyone has written one, or whether anyone is using it. That abstraction is deliberate and useful for describing a flaw. It is a poor patch order, because the question a patch queue answers is not "which flaw is worst?" but "which flaw is most likely to be used against me before the next window?" Those are different orderings, and the gap between them is wide: at any moment, the set of CVEs with a CVSS of 9 or higher numbers in the tens of thousands, while the set being actively exploited numbers in the low thousands. Defenders have limited windows; attackers have already made their selection. Triage is the discipline of finding the attackers' selection inside your scanner output, and two public datasets now publish exactly that — one as fact, one as probability.

The floor of fact: the KEV catalog

CISA's Known Exploited Vulnerabilities catalog is a list with an evidence bar: a CVE enters it when CISA has credible reporting of exploitation in the wild, and each entry carries the date it was added, the vendor and product, whether it is known to be used in ransomware campaigns, and a remediation due date — binding on US federal agencies, and a sensible deadline for everyone else. KEV membership is the closest thing vulnerability management has to ground truth. If a CVE on your list is in KEV, somebody is using it, against somebody, now; the only remaining question is whether your asset is exposed. That makes KEV the floor of any sane ordering: every KEV entry outranks every non-KEV entry, full stop, before severity is even consulted. The catalog is small — under two thousand entries against a quarter-million published CVEs — which is the point: it converts "everything is critical" into a first page you can actually finish. Paste your scanner list into the CVE triage desk and the P1 band is precisely this set, due dates and ransomware flags included.

The ranking signal: EPSS probability

Below the floor of fact sits a much larger grey zone: CVEs not known to be exploited, some of which are about to be. FIRST's EPSS model scores every CVE daily with the probability that it will be exploited in the next 30 days, learned from exploitation telemetry and CVE features. Two properties make the scores usable. First, they are brutally skewed: the median CVE scores near zero, and well under one percent of CVEs hold a score of 0.10 or higher — so a threshold like 0.10 selects a small, genuinely hot set rather than re-labelling half the queue. Second, every score ships with its percentile, which keeps you honest: an EPSS of 0.08 sounds low until you see it is the 97th percentile. In the ordering used here, EPSS at or above 0.10 is P2 — below KEV, above everything severity-only — and within bands, EPSS breaks ties before CVSS does. Treat the model with the respect due to a forecast: it is re-scored daily, it moves when exploits are published, and last month's P4 becoming this week's P2 is normal, expected, and the reason the list gets re-run rather than framed.

Where CVSS still belongs, and a worked order

None of this discards CVSS; it demotes it to its proper jobs. It is the tiebreak inside the no-signal zone (P3 is CVSS 7.0 and above: severe, unexploited as far as anyone knows, worth the window after the exploited and the probable), it is the language vendor advisories and auditors speak, and it is the impact estimate that tells you what a successful exploit costs — which matters for the one adjustment this ordering deliberately leaves to you: exposure. Exploitation data describes the CVE in the world; it knows nothing about your estate. A P3 on an internet-facing service can deserve the slot ahead of a P1 on an isolated lab box, which is why the practical routine is to split the scanner output by exposure first — the desk takes 200 ids at a time, sized for one asset group — and let the bands order each batch. A worked example, from a real shape of list: Log4Shell (CVE-2021-44228, CVSS 10.0, KEV-listed, EPSS near the ceiling) is P1 by every signal at once; a Citrix NetScaler flaw at CVSS 7.5 that sits in KEV with a ransomware flag is also P1, and under a severity-only sort it would have waited behind a dozen theoretical 9.8s in products nobody is attacking; a fresh 9.8 with an EPSS of 0.4 is P2 and climbing; the same 9.8 with an EPSS of 0.002 is P3 — patch it in the normal window, and spend the emergency window on the first three. Severity asked "how bad?"; the queue needed "how soon?" — and now it can answer both.

Frequently asked questions

Does a low EPSS score mean I can skip a CVE?

No. EPSS is a probability over the next 30 days, re-scored daily — a CVE at 0.001 today can be at 0.9 next month when an exploit drops, which is exactly what happened to several vulnerabilities that later entered the KEV catalog. Low scores deprioritise; they do not delete. The queue still gets worked, just in an order that spends the first hours where the attacks actually are.

What if a CVE is in neither KEV nor EPSS?

Then you have severity and the vendor advisory, which is the old way — read the advisory, weigh exposure, and patch on your normal cadence. Absence from both datasets is common for brand-new CVEs and for niche products, and it carries no safety information either way. The triage desk marks such rows "not in today's cached data" rather than guessing.

How often should a triage list be re-run?

Whenever the inputs change: a new scanner report, obviously, but also on KEV additions — CISA adds entries most weeks, and an old P3 becoming a P1 overnight is the single most valuable alert in vulnerability management. Weekly is a sane cadence for most estates; the desk caches the daily data, so re-running the same paste costs you thirty seconds.