CVSS 4.0 Explained: How to Prioritise Vulnerabilities Properly
Why the base score is severity, not risk — and what to do about it.
For most security teams, vulnerability prioritisation is the activity that consumes the most time and produces the least visible value. The CVSS base score has become the default ranking mechanism — the “9.8 critical” that lands in the ticketing system and goes onto the patch list. The problem is that the base score was never designed to do that job. CVSS 4.0, released by FIRST in November 2023, makes that explicit, and the prioritisation approaches that organisations are adopting in 2026 finally look fit for purpose.
This article explains why base scores create noise, what changes in CVSS 4.0, and how to combine CVSS with other inputs — exploit data, exposure and asset value — to produce defensible priorities. It is written for security leaders who own vulnerability programmes and are tired of fighting backlogs that never shrink.
Why base scores create noise
The CVSS base score reflects the intrinsic characteristics of a vulnerability — exploitability metrics (attack vector, complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability). It deliberately excludes anything about how the vulnerability is being exploited in the wild and anything about the specific environment it is found in.
That design choice is sensible for the vendor publishing the score. It is poorly suited for the operator deciding what to fix first. The result, in practice:
- A “critical” remote code execution vulnerability in a service you do not run, or that is not reachable, dominates the report.
- A “medium” authorisation bypass in your most sensitive internet-facing application sits below it.
- Tens of thousands of vulnerabilities arrive each year, the majority of which are never exploited and many of which do not apply to your environment.
- Remediation teams burn out on volume, lose trust in the prioritisation, and start patching what they feel like patching.
The data backs this up. EPSS (the Exploit Prediction Scoring System maintained by FIRST) consistently shows that fewer than 5% of disclosed CVEs are exploited within their first year, while CVSS base distribution puts a far larger proportion in “critical” or “high”. Using base scores alone, the average organisation is prioritising several times more vulnerabilities as “critical” than will ever matter.
What CVSS 4.0 changes
CVSS 4.0 keeps the base score and explicitly reframes it as one input among several. The framework now consists of four metric groups: Base, Threat, Environmental and Supplemental.
Base metrics are the intrinsic characteristics of the vulnerability — what was already in CVSS 3.1, with refinements. A notable addition is the Attack Requirements (AT) metric, which distinguishes between vulnerabilities exploitable in any configuration and those requiring specific environmental conditions.
Threat metrics capture the real-world threat landscape. Is there proof-of-concept code? Is there evidence of active exploitation? These metrics adjust the score based on what is actually happening in the wild, rather than what could theoretically happen.
Environmental metrics allow the consumer to reflect their own context. How important is the affected system to the business? What compensating controls are in place? Is the affected component actually reachable in your deployment?
Supplemental metrics add context without changing the numeric score. They include Safety (does exploitation create physical risk?), Automatable (can exploitation be scaled?), Recovery (how hard is recovery if exploited?), Provider Urgency (vendor’s assessment) and Vulnerability Response Effort (operational cost of mitigation).
The most important conceptual change in CVSS 4.0 is the explicit acknowledgement, written into the standard, that the base score alone is not a measure of risk. FIRST states this directly. The base score is severity; risk requires the threat and environmental context.
CVSS 4.0 also introduces clearer nomenclature — CVSS-B for base only, CVSS-BT for base+threat, CVSS-BTE for base+threat+environmental — making it explicit which inputs informed any given score.
How to use CVSS for real prioritisation
A defensible prioritisation approach in 2026 combines three independent inputs:
- Severity — what CVSS 4.0 base tells you about the intrinsic seriousness of the vulnerability.
- Exploitability — what is actually happening in the wild, drawn from the CISA Known Exploited Vulnerabilities catalogue, EPSS scores and vendor threat intelligence.
- Exposure and asset value — whether the affected component is reachable in your environment, and how much it would matter if it were compromised.
A practical workflow looks like this:
- First pass. Anything on the CISA KEV catalogue affecting an asset you actually run jumps to the top of the queue, regardless of CVSS base score. KEV exists because exploitation is confirmed; this is the highest-confidence signal available.
- Second pass. Use EPSS to identify vulnerabilities with high predicted exploitation probability that have not yet appeared in KEV. These represent leading indicators.
- Third pass. Apply environmental context. A CVSS 9.8 issue in a non-reachable internal service is a different problem from the same issue on an internet-facing application. Use CVSS 4.0 environmental metrics, or your own asset criticality model, to adjust.
- Backlog. Everything else enters a normal remediation queue, sorted by base score, asset criticality and operational cost.
- Verify, do not assume. After remediation, confirm the fix has actually been applied — ideally by re-testing rather than by closing the ticket.
This approach turns vulnerability management from “patch everything labelled critical” into a defensible programme that prioritises by real-world risk. It is also auditable: when the board asks why a specific issue was not patched immediately, the answer is concrete rather than apologetic.
The supplemental metrics in CVSS 4.0 — particularly Automatable and Recovery — are worth adopting even though they do not change the numeric score. An exploit that can be automated and from which recovery is hard belongs at the top of the queue.
Frequently asked questions
When was CVSS 4.0 released?
CVSS 4.0 was published by FIRST in November 2023 and is the current version of the framework.
What is the difference between CVSS-B, CVSS-BT and CVSS-BTE?
CVSS-B is the base score only. CVSS-BT incorporates threat metrics. CVSS-BTE incorporates both threat and environmental metrics. The nomenclature makes clear which inputs the score reflects.
Is CVSS 4.0 a measure of risk?
No. The standard itself states that the base score is severity, not risk. Risk requires threat context (what is being exploited) and environmental context (what matters in your environment).
What is the relationship between CVSS, EPSS and KEV?
CVSS measures severity, EPSS predicts exploitation probability, and KEV records confirmed exploitation. The three are complementary inputs to prioritisation, not alternatives.