Your scanner reports thirty-one vulnerabilities. Nine are rated critical. You have an afternoon. Severity alone will not tell you where to start — and picking wrong is how security tooling ends up ignored.
The failure mode here is well documented and entirely predictable. A team is handed a long list, cannot act on all of it, works down from the top by severity, runs out of time, and gradually stops opening the report. The list was accurate and useless at the same time.
What CVSS actually measures
CVSS is a severity score from 0 to 10, attached to a CVE identifier. It describes how bad exploitation would be if it happened: how easy the attack is, whether it needs credentials, and what the attacker gains.
What the score in front of you deliberately does not describe is whether anyone is doing it. CVSS defines optional Threat metrics for exploit maturity, but almost nobody publishes them, so what advisories and scanners carry is the Base score: a property of the flaw in isolation, assigned when the advisory is published, and unchanged when the world moves. A vulnerability scored 9.8 that requires a configuration almost nobody runs and has no public exploit sits at 9.8 forever. So does one that every automated scanner on the internet started firing at last Tuesday.
This is not a flaw in CVSS. It is a misunderstanding of what it is for. Severity is one input to prioritisation, not the answer.
KEV: exploitation that has actually been observed
CISA's Known Exploited Vulnerabilities catalogue is a list of vulnerabilities confirmed to have been used in real attacks. Not theoretically exploitable — observed, in the wild, with evidence.
It is a deliberately conservative list. Something appears on it because there is reliable evidence of exploitation, which means the catalogue is much shorter than the total number of published vulnerabilities, and every entry is a statement of fact rather than a prediction.
That makes it the single most useful prioritisation signal available, and it is free. If a component you run has a KEV entry, that is not a backlog item. Attackers are already using it against somebody, and internet-wide scanning means being small is not much protection.
The limitation is coverage: KEV only knows what has been seen and reported. A brand-new flaw being quietly exploited against a handful of targets will not be there yet.
There is also a condition that is easy to miss. CISA only adds a vulnerability if there is a clear remediation to point at, so an actively exploited flaw with no fix available can sit outside the catalogue precisely while it is at its worst.
EPSS: the probability of what happens next
EPSS — the Exploit Prediction Scoring System, published by FIRST — fills that gap from the other direction. It is a model, updated daily, that outputs the probability a given vulnerability will be exploited in the next thirty days. Each score is a number between 0 and 1.
It is trained on the observable characteristics that historically precede exploitation — how the flaw is described, what kind of software it is in, whether exploit code has appeared, how much attention it is getting. It is a forecast, and like any forecast it is sometimes wrong.
The number that makes EPSS worth using is not its accuracy on any single vulnerability but the shape of the distribution: the overwhelming majority of published vulnerabilities score very low, and a small minority score high. That is what makes it useful for cutting a list down.
Putting them together
The three tiers that follow from this are straightforward, and they should drive the order your findings appear in, not just a badge on the side:
- Exploited in the wild — it is in KEV, or the EPSS probability is above 0.5. Fix it now. This is the tier that justifies interrupting planned work.
- Likely target — an EPSS score above 0.1, which is roughly the top two per cent of all published vulnerabilities. Not yet confirmed in attacks, but the model puts it well ahead of the field. This week.
- Elevated risk — a measurable but lower EPSS score. Worth scheduling deliberately rather than leaving in the general pile.
Everything else is the backlog: real, worth fixing, and not worth an interruption. Handle it on the normal upgrade cycle — noting that for a vulnerability in a transitive dependency, the upgrade is usually to something else entirely.
Notice what this does to the arithmetic. Thirty-one findings become two or three that need attention this week. That is the difference between a report someone acts on and a report someone closes.
Two ways to get this wrong
Alerting on everything. If your tooling emails you about the backlog as well as the exploited items, the ranking has achieved nothing — you have restored the original problem through a different channel. The whole point of separating "your to-do list" from "this is being attacked now" is lost if both arrive in the same inbox with the same urgency.
Treating a missing feed as good news. If the KEV or EPSS lookup fails, the correct output is "not checked", not "not exploited". A tool that silently degrades to an all-clear when a data source is unavailable is worse than one that has no ranking at all, because you will trust it.
What is the CISA KEV catalogue?
The Known Exploited Vulnerabilities catalogue is CISA's list of vulnerabilities confirmed to have been used in real attacks — observed in the wild with evidence, not merely judged exploitable in theory. It is deliberately conservative and therefore much shorter than the total number of published vulnerabilities, which is what makes it useful: if something you run appears in KEV, attackers are already using it against somebody, and internet-wide scanning means being small is not much protection.
What is an EPSS score?
EPSS is a daily-updated model that estimates the probability a given vulnerability will be exploited within the next thirty days, expressed as a number between 0 and 1. It is trained on characteristics that historically precede exploitation, such as whether exploit code has appeared and how much attention the flaw is getting. Its value is less in any single prediction than in the shape of the distribution: most published vulnerabilities score very low, so a high score genuinely narrows the field.
Why is CVSS not enough to prioritise patching?
CVSS measures how bad exploitation would be if it happened, not whether anyone is doing it. It is assigned when the advisory is published and does not change when the world does, so a 9.8 that requires a configuration almost nobody runs scores the same as a 9.8 that every scanner on the internet started firing at last week. Severity is one input to prioritisation rather than the answer, which is why exploitation data is needed alongside it.
How many vulnerabilities are actually being exploited?
Only a small fraction of published vulnerabilities are known to be exploited. The KEV catalogue contains vulnerabilities with confirmed evidence of real-world exploitation, and it is orders of magnitude shorter than the total number of CVEs published each year. EPSS shows the same pattern from the other direction: the overwhelming majority of vulnerabilities score very low, and a small minority score high. This is precisely why ranking by exploitation turns an unusable list into a short one.
Where this shows up in TrustCtrl
Both CodeControl and VulnControl cross-reference every finding against CISA KEV and, in CodeControl's case, EPSS. The vulnerability table sorts by exploitation first and severity second, and CodeControl's report opens with a "patch these first" section — usually two or three items. Email is reserved for a dependency that has just entered the exploited catalogue; the backlog stays in the dashboard where it belongs. A failed lookup is reported as not checked, never as not exploited.