CVSS score alone is not a priority order

Sort the findings table by severity, work top to bottom, ship the fixes. It is the most natural triage order in the world, and on a backlog of any size it will reliably have you patching the wrong things first.

What the base score actually measures

A CVSS base score describes a vulnerability in the abstract. The metrics that feed it — attack vector, attack complexity, privileges required, user interaction, and the impact on confidentiality, integrity and availability — are all properties of the flaw. Every one of them is fixed at publication time by someone who has never seen your network.

That is deliberate. The base score is meant to be a stable, comparable description of a weakness, not a verdict on your risk. FIRST, who maintain the specification, are explicit that base scores are intended to be refined by the temporal and environmental metric groups before being used for prioritisation. Almost nobody does this, because populating environmental metrics by hand across a few thousand findings is not work anyone has time for.

So the number that ends up driving the remediation queue is the one that knows the least about your environment.

The two findings that look identical and are not

Consider a 9.1 CVSS base score on a service that listens only on a private subnet, reachable through a bastion host, holding no customer data. Then consider a 7.4 high on your public API gateway, terminating TLS for every customer request.

By raw severity, the 9.1 wins and gets fixed first. By any honest reading of business risk, it is not close: the second one is reachable by anyone with a network connection, and the first requires an attacker to already be inside. Attack-vector metrics capture some of this, but they describe the vulnerability class in general, not whether your instance of it is exposed.

The asymmetry compounds. Internal findings are usually more numerous and often score higher, because internal services tend to run older software with weaker authentication. Sort by severity and the queue fills with them, while the smaller set of genuinely reachable problems sits below the fold.

Triage by exposure first, severity second

The practical ordering that survives contact with a real backlog:

1. Is it reachable from the internet? Everything public outranks everything private, near enough regardless of score. An attacker's first constraint is reachability, so it should be your first filter too.
2. What does the asset hold or broker? A public marketing page and a public API holding customer records are both "external" and are not the same problem.
3. Is it being exploited in the wild? A high with a working public exploit and observed campaigns outranks a critical nobody has weaponised. CISA's Known Exploited Vulnerabilities catalogue is the cheapest input here, and EPSS gives a probability where KEV gives a binary.
4. Then severity, to order what is left inside each band.

Severity has not stopped mattering — it is the tiebreaker rather than the sort key. The failure mode is treating a number computed without reference to your environment as though it already accounted for it.

Conclusion

CVSS answers "how bad is this weakness?" Your remediation queue needs the answer to a different question: "what is most likely to hurt us first?" Those diverge the moment your asset inventory contains more than one kind of asset.

This is why CyberSpec's findings table filters by asset alongside severity, and why the compliance view maps findings to the controls they break rather than ranking them by score alone. The combination of exposure and severity is the priority signal. Severity on its own is an input to it.