What a Severity Score Actually Tells You

Vulnerability Management · July 11, 2026 · 8 min read

There is a number attached to every published vulnerability, and it is load-bearing in a way its designers never intended. It appears in policies (“remediate all criticals within seven days”), in contracts, in board reporting, and in the queue that determines what an engineer patches on Monday morning.

The number is a base score, and it answers a narrower question than the use it gets put to.

What it measures

A base score is computed from eight characteristics of the flaw itself: how the attacker reaches it, how much has to go right for them, what privileges they need beforehand, whether a user has to do something, whether the blast crosses a security boundary, and how badly confidentiality, integrity and availability suffer.

Every one of those is a property of the vulnerability. None is a property of your deployment. That is deliberate. Holding the environment constant is what makes a score comparable between a vendor advisory, a research write-up and your scanner. If the score already accounted for context, no two organisations would be able to discuss it.

The consequence is that a base score is an input, not a conclusion. It has no idea whether the affected host is reachable from the internet in your network, whether the service is even running, or whether the machine is a lab box.

The scope metric is where accuracy goes to die

Of the eight inputs, one is misapplied constantly, and it is the one that moves the score most.

Scope does not ask how severe the impact is. It asks whether the vulnerable component and the impacted component fall under the same security authority. A hypervisor bug that lets a guest reach the host changes scope. A browser sandbox escape changes scope. A SQL injection that reads the database the application already had full access to does not — the impact is serious, but it stays inside one authority.

Because a changed scope both raises the impact sub-score and applies a multiplier, getting it wrong inflates a score substantially. Plenty of published scores are wrong in exactly this way, which is a reason to sanity-check the vector string rather than accept the headline figure.

Two adjustments do most of the work

If a programme makes only two modifications to raw score ordering, these are the ones that pay.

Is it being exploited? The gap between “an attacker could theoretically” and “an attacker is currently, at scale, with a public tool” is enormous, and the base score cannot see it. A medium-scored flaw with a weaponised exploit in active use outranks a critical-scored one that requires a chain nobody has demonstrated. Exploit availability and observed exploitation are the highest value signals available, and they are external to the score by design.

What is the asset? Reachability and business role change everything. The same vulnerability on an internet-facing gateway, on an internal application server, and on a decommissioned host awaiting disposal produces three different urgencies from one number. This requires an asset inventory that knows what things are, which is why inventory quality quietly determines vulnerability management quality.

Why “patch all criticals in seven days” behaves badly

The policy is popular because it is auditable. It also produces predictable pathologies.

It creates an incentive to argue about scores rather than fix things, because reclassifying from critical to high buys three weeks. It floods the same seven days with everything that crossed the threshold, regardless of whether anything is exploitable. And it says nothing about the 6.5 on the edge of your network that has a public exploit, because 6.5 is not critical.

A threshold policy is not useless — it establishes a floor and it is easy to verify. It should not be the primary ordering, and where a regulation forces one, it is worth running the sensible queue alongside it and being explicit that the compliance queue is a compliance artefact.

Using the vector rather than the number

The vector string carries more information than the score, and it is compact enough to read at a glance. AV:N tells you it is network-reachable. PR:N tells you no prior access is needed. UI:N tells you nobody has to click anything. Those three together describe something that can be attacked directly by anyone who can route to it, and that combination is what deserves attention regardless of where the arithmetic lands.

Conversely, AV:L/PR:H describes something requiring local access and existing elevated privileges — an attacker holding both has usually already achieved what the vulnerability would grant them.

Reading the vector takes a few seconds longer than reading the number and routinely reverses the ordering the number implies.

What the score is good for

Comparability, and a starting point. It lets you say that this flaw is intrinsically more dangerous than that one, holding environment aside, and it gives a shared vocabulary between a vendor, a researcher and your own team.

That is genuinely valuable. It is simply not the same thing as knowing what to fix first, and the distance between those two is where most vulnerability management programmes spend their effort without noticing.