Reading a CVSS score without the panic

A report lands with three findings scored 9.8, and the instinct is to drop everything. Sometimes that is right. Often, though, a lower score on a more important system deserves the first fix. The Common Vulnerability Scoring System is a good starting point for prioritising, as long as you know what it does and does not measure.

What the number measures

CVSS gives a vulnerability a base score from 0 to 10, based on how it can be exploited and what it affects. The base score assumes a reasonable worst case and knows nothing about your environment: whether the system is exposed, what data it holds, or what already protects it. That makes it useful for comparing vulnerabilities, and dangerous when it is treated as a to-do list.

CVSS v4.0 was published in 2023 and treats threat and environmental factors more cleanly, but v3.1 is still the version most tools and reports use.

Read the vector, not just the number

Every score comes with a vector string, such as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Read left to right, it describes the attack:

• AV, attack vector: N (network) means it can be reached remotely; L (local) or P (physical) needs a foothold first
• AC, attack complexity: L means no special conditions are needed
• PR, privileges required: N means no login at all
• UI, user interaction: N means no victim has to click anything
• S, scope: C (changed) means the impact reaches beyond the vulnerable component
• C, I and A: the impact on confidentiality, integrity and availability

That example scores 7.5 (High): anyone on the internet can read data, with no login and no user interaction. The vector says more about urgency than the number does.

Add exploitability

A severe vulnerability that nobody is exploiting can wait behind a moderate one that is being used in attacks today. Three questions help:

• Is it in the CISA Known Exploited Vulnerabilities catalogue? If so, attackers are using it now.
• What does EPSS say? The Exploit Prediction Scoring System estimates the probability of exploitation in the next 30 days.
• Is there a public exploit or a ready-made module in common attack tools? Public tooling lowers the bar for every attacker.

Add business context

Then ask what the vulnerable system means to you:

• What data does it hold, and how sensitive is it?
• Who can reach it: the internet, the internal network, or only an isolated segment?
• What protects it already: a web application firewall rule, network segmentation, multi-factor authentication?

A 9.8 on an isolated test server with no data may matter less than a 6.5 on the payment API.

Common misreadings

• Treating a scanner's score as final. Scanners score the vulnerability in general; a tester who has seen it in your environment may rightly rate it higher or lower.
• Ignoring the vector. Two findings scored 7.5 can be very different: one reachable by anyone on the internet, the other only by a logged-in administrator on the internal network.
• Adding scores together. Three medium findings do not add up to a critical one, although a chain of weaknesses can. Showing that chain is a tester's job, not a score's.
• Forgetting the environment. CVSS has environmental metrics for exactly this reason, but they are rarely filled in.

A worked example

Two findings arrive in the same report:

• A remote code execution flaw scored 9.8 on an internal build server, reachable only from the build network and behind multi-factor authentication
• An access control flaw scored 6.5 on the customer API, letting any customer read another customer's invoices

The 9.8 is more severe in general. The 6.5 exposes customer data to anyone with an account, on the internet, today. Most organisations should fix the 6.5 first, schedule the 9.8 promptly, and record why.

Turning it into a fix order

1. Fix vulnerabilities that are exploited in the wild on exposed systems first, whatever their score.
2. Then critical and high findings on systems that hold sensitive data or face the internet.
3. Then the rest, against due dates that match their severity.

Write down the reasoning when you move a finding up or down. A severity change without a reason looks like risk acceptance by accident, and it is the first thing an auditor will ask about.

Severity in Cerberos Nexus

Pentest findings in Cerberos Nexus are scored with CVSS 3.1, and a tester can override the calculated severity only with a written justification. SLA due dates follow from the severity, so the client's dashboard shows what is on track, at risk and overdue.