Prioritising vulnerabilities: why a CVSS of 9.8 is not automatically urgent

2026-08-07 · by SECURITYSQUAD

A test report with 180 findings is not yet a work plan. The obvious response – sort by score and work down from the top – sounds reasonable and still routinely puts effort in the wrong place. This article sets out which signals produce a defensible order, and in what sequence to apply them.

What CVE, CVSS and the OWASP Top 10 actually denote is covered concisely on our vulnerability management page. This is about the step after that: deciding what comes first.

A list of findings is not a ranking

A scanner reports what it finds and rates it against a universal yardstick. It does not know which of your systems is reachable from the internet, what data sits behind it, or whether working exploit code even exists for the flaw it reported. Yet those three things decide whether a finding must be handled today or next quarter.

Sorting by score also has an awkward side effect: the top of the list is crowded. If forty findings are marked critical, none of them is prioritised.

What the CVSS base score measures – and what it does not

The base score describes properties of the vulnerability itself: attack vector, privileges required, user interaction needed, impact on confidentiality, integrity and availability. That is a statement about the flaw in a vacuum, and it is meant to be exactly that.

What usually gets overlooked is that CVSS reaches further. The standard provides threat metrics – does exploit code exist, how mature is it – and environmental metrics that adapt the score to your own situation: a system without data worth protecting is weighted down, a particularly exposed one weighted up. In practice these metrics are rarely maintained, because they take effort and nobody publishes them. The result is that a number expressly not intended for prioritisation ends up being used for it.

EPSS: probability, not damage

EPSS (Exploit Prediction Scoring System) closes one of those gaps. It is a data-driven model from the EPSS Special Interest Group at FIRST and estimates, for a published CVE, the probability that it will actually be exploited within the next 30 days. The value ranges from 0 to 1 and is also expressed as a percentile.

Two things matter when reading it. First, EPSS says nothing about damage – it measures only the likelihood of exploitation, not its consequences. A high EPSS score on a flaw that merely crashes a service remains less urgent than a middling one on a flaw that lets data be extracted. Second, the value is not stable: it changes as new observations feed in. A prioritisation drawn up three months ago is out of date on this axis.

So EPSS does not replace CVSS; it adds the dimension the base score lacks.

KEV: what is demonstrably being exploited

More clear-cut still is the KEV catalogue (Known Exploited Vulnerabilities) maintained by the US agency CISA. A vulnerability is added only if three conditions are met: it has a CVE identifier, there is clear remediation guidance, and there is reliable evidence of exploitation in the wild.

That last point is what makes the catalogue so useful. Where EPSS offers an estimate, KEV states a fact. If a flaw is listed there and affects a system you operate, the discussion about urgency is over.

For US federal agencies the catalogue was tied to a binding directive with fixed deadlines; that directive has since been replaced by a newer one that aligns updates more closely with risk. For European organisations the catalogue was never binding in the first place – it is a source, not a rule. As a signal it is hard to beat all the same, because it reflects observed reality rather than a forecast.

Your environment is the most important filter

Every signal named so far is universal. The biggest difference comes from the information only you hold.

Reachability. Is the affected service addressable from the internet, does it sit behind a VPN, or does it only listen on the internal network? The same flaw means something entirely different in each case.

Protection requirement. What sits behind the system? A test system with synthetic data and the portal holding your customers' contract records do not justify the same effort.

Compensating controls. Sometimes the flaw is present but the route to it is already blocked – by a firewall rule, a WAF, a disabled feature. That changes the urgency, though not the need to write it down.

An order you can justify

In practice it works better to apply the signals one after another as filters rather than to combine them into a single number:

Is the flaw in the KEV catalogue and does it affect a reachable system? Then immediately, regardless of score.
Is the system reachable from the internet and the EPSS score high? Then into the current sprint.
High CVSS, but internal and with no sign of exploitation? Scheduled for the next maintenance window.
Everything else is bundled up and picked up in the regular patch cycle.

The advantage of this approach is not precision – four tiers are coarse. The advantage is that every classification carries a reason that still makes sense six months later. That is precisely what an auditor asks for.

An example: a CVSS of 9.8 on a decommissioned test system lands in tier four. A 6.5 on the customer portal with public exploit code available lands in tier one. The scores suggest the opposite.

What happens to the rest

Not every finding gets fixed, and that is not a failing. Where remediation is technically impossible or out of all proportion to the benefit, a compensating control takes its place – or the risk is knowingly accepted.

Both are legitimate. What is not legitimate is leaving it unwritten. A documented risk acceptance needs three things: who decided, on what basis, and when the decision will be revisited. Without that third element, a decision quietly turns into forgetting with a reference number.

As at August 2026. EPSS per FIRST; KEV inclusion criteria per CISA.