What Is a CVSS Score? A Practical Guide to Prioritising Patches

A CVSS score is a number from 0 to 10. It tells you how severe a vulnerability is under the Common Vulnerability Scoring System, the industry standard maintained by FIRST. Vendors, NVD and penetration testers all use it to rate published flaws. Most IT managers meet the term while staring at a patch report full of CVEs, each tagged critical, high, medium or low, with no clear sense of which one to fix first. That decision is what this guide is about.

Below is what the score is built from and how the severity bands map to a sensible patching schedule. It also covers how to avoid the trap of treating every “critical” the same way just because they share a number.

What actually goes into a CVSS score?

CVSS scores come from a Base metric group split into two halves. The first half is exploitability. It covers how an attacker would reach the flaw: over the internet or only from inside the network, with an existing account or none. It also asks whether a victim has to click something first. The second half is impact. It rates the damage across confidentiality, integrity and availability if the exploit works.

Put those together and you get a vector string like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. That string is shorthand for every choice that fed into the final number. Anyone can plug it into FIRST’s own calculator and see exactly how the score was reached. That matters if a vendor’s rating looks off for your environment.

Reading the severity bands

NVD sorts every score into four bands: Low from 0.1 to 3.9, Medium from 4.0 to 6.9, High from 7.0 to 8.9, and Critical from 9.0 to 10.0. Many organisations build a simple SLA on top. Patch critical findings within days, high findings within weeks, and let medium or low findings ride along with routine maintenance.

That structure works fine until your monthly patch report lists thirty critical findings and you have a two-person IT team. Then the band alone stops being useful. It can’t tell the difference between a critical flaw nobody can reach from the internet and a critical flaw sitting on your public login page.

Why the score isn’t the whole story

CVSS deliberately ignores your specific environment. It has to, because the same CVE affects thousands of different organisations. The standard scores the vulnerability in the abstract, not in your context. That’s useful for consistency, but it’s a real limitation once you try to use it for prioritisation.

Two extra signals fill that gap. FIRST’s own Exploit Prediction Scoring System runs a machine-learning model over real attack data. It produces a daily-updated probability, from 0 to 1, that a given CVE will actually be exploited in the wild within the next 30 days. CISA’s Known Exploited Vulnerabilities catalogue is blunter still. It simply lists CVEs with confirmed evidence that someone is already exploiting them, regardless of their CVSS score.

A finding that scores 9.8 but has never appeared in an attack, sitting behind internal network segmentation, is a lower priority in practice. A 7.4 already on the KEV list with a public exploit doing the rounds should come first. Businesses that patch purely by CVSS number, in descending order, routinely spend their limited hours on the wrong things.

Building a prioritisation approach that actually works

A practical order for a stretched team looks roughly like this. First, anything on CISA’s KEV catalogue, because active exploitation trumps every other signal. Second, anything with a high EPSS probability and internet-facing exposure. Third, the remaining criticals and highs by CVSS band, weighted by whether the system is public-facing or internal. Everything else joins the normal patch cycle.

This is also where the difference between a vulnerability scan and a penetration test becomes concrete. A scanner reports the CVSS score a vendor assigned and stops there. A tester goes further. They confirm whether the flaw is genuinely reachable from where an attacker would sit, and whether it chains with a second issue to become something worse. They also work out what business impact actually follows. Aardwolf Security builds its penetration test reports around that distinction, ranking findings by demonstrated exploitability rather than by CVSS number alone. If you want that distinction confirmed on your own systems, Aardwolf’s scoped penetration tests are built to do exactly that. You’re welcome to get in touch if you’d like to talk through what a test would cover.

What changed in CVSS 4.0, and does it matter here?

CVSS 4.0 added a Subsequent Systems impact metric. A vulnerability that lets an attacker pivot from one system into another now scores more accurately. Under 3.1, only the originally vulnerable component counted. The update also replaced the old Temporal metric group with a simplified Threat group. It added an Attack Requirements metric too, for conditions like race conditions that Attack Complexity alone didn’t capture well.

For a business setting patching priorities, the practical takeaway is smaller than the version change suggests. Keep using the severity bands as a starting filter. But don’t expect a like-for-like comparison between a 3.1 score and a 4.0 score on the same CVE, since NVD confirms the two aren’t directly comparable. Check which version an advisory is quoting before assuming a change in score means anything about the actual risk.

A worked example: two critical findings, one afternoon

Say a scan turns up two findings, both rated 9.1 under CVSS. The first is a remote code execution flaw in a public-facing content management system your marketing team uses. It’s on CISA’s KEV catalogue and has an EPSS score above 90%. The second carries the same severity rating in an internal reporting tool that only a handful of finance staff can reach. It has no KEV listing and an EPSS score under 1%.

Same number, same band, completely different afternoon. The first gets patched before lunch, with the login page taken offline if the fix isn’t ready in time. The second goes into the next scheduled maintenance window, because nothing in the evidence suggests anyone is actively targeting it. Two identical numbers, two entirely different responses. Only one of those decisions is easy to defend to a board or an insurer afterwards.

Frequently asked questions

Should I ignore CVSS scores altogether?

No. They’re a consistent, vendor-neutral starting point and still the fastest way to triage a long list of findings. The mistake is stopping there instead of layering in exploitation evidence and your own exposure.

Where do I find a vulnerability’s CVSS score?

The vendor’s own advisory usually publishes one. NVD independently scores every CVE it processes too, so check both when a score looks surprising.

What’s a reasonable patching SLA based on CVSS?

Many organisations aim for days on critical findings, a few weeks on high, and the next routine maintenance window for medium and low. Then they adjust up or down based on KEV listing and internet exposure.

Does a low CVSS score mean I can ignore a finding?

Not automatically. A low-scoring flaw that chains with another issue, or that sits on a system holding sensitive data, can matter more in context than its number alone suggests.

How does a penetration test relate to CVSS scoring?

A test verifies which findings are actually exploitable in your own environment, rather than relying on a generic vendor rating. That’s why pen test reports typically reference CVSS scores alongside a separate, context-aware risk rating.

How often should CVSS-based patch priorities be reviewed?

At least monthly for most businesses, since EPSS scores update daily and new CVEs join the KEV catalogue regularly. A finding that was safe to defer last month can turn urgent overnight once active exploitation starts.