CVSS 4.0 Explained: How to Prioritise Vulnerabilities Properly
The CVSS base score measures severity, not risk — here's how to use it effectively.
For many security teams, vulnerability management is an exercise in triaging endless lists of “critical” findings. Most scanning tools sort vulnerabilities by Common Vulnerability Scoring System (CVSS) base score, so anything with a 9.x becomes a top priority. Yet the CVSS base score was never designed to be a risk ranking; it reflects only the intrinsic characteristics of a vulnerability. CVSS 4.0, released by the Forum of Incident Response and Security Teams (FIRST) on 1 November 2023, makes this clear and provides new metrics to incorporate threat and environmental context.
This article explains why using base scores alone creates noise, summarises the changes introduced in CVSS 4.0 and describes how to combine severity, real‑world exploitation and exposure to produce defensible vulnerability priorities.
Why base scores create noise
The CVSS base score combines exploitability metrics (attack vector, complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability). It excludes anything about how a vulnerability is being exploited in the wild or how important the affected system is to your organisation. That makes sense for vendors publishing a generic score but is unsuitable for operators deciding what to fix first.
In practice, using base scores alone means:
- A “critical” remote code execution vulnerability in a library you do not deploy outranks an authorisation bypass in your most sensitive internet‑facing application.
- Tens of thousands of vulnerabilities are flagged as “high” or “critical” each year, most of which will never be weaponised.
- Remediation teams lose trust in prioritisation and start patching based on gut feel rather than data.
Real‑world exploitation is rare relative to disclosure volume. A study by the Cyentia Institute and FIRST shows that exploits affecting more than one in ten organisations are rare — less than five per cent of vulnerabilities see exploitation on that scale. This means most “critical” vulnerabilities in a scan will never be used in the wild. Relying solely on base scores therefore creates significant noise and wastes remediation effort.
What CVSS 4.0 changes
CVSS 4.0 retains the base score but explicitly reframes it as just one input. The framework now consists of four metric groups: Base, Threat, Environmental and Supplemental.
- Base metrics capture intrinsic characteristics of the vulnerability, such as attack vector, complexity and impact. CVSS 4 adds an Attack Requirements (AT) metric to distinguish between vulnerabilities exploitable in any configuration and those requiring specific environmental conditions.
- Threat metrics replace the “Temporal” metrics from CVSS 3.1. They measure the current state of exploit techniques or code availability. Exploit Maturity reflects whether proof‑of‑concept code or active attacks exist.
- Environmental metrics allow the consumer to incorporate local context: asset criticality, compensating controls and whether the affected component is reachable. Modified base metrics can override vendor‑provided values to reflect your environment.
- Supplemental metrics provide additional extrinsic context without affecting the numeric score. CVSS 4 defines metrics such as Safety, Automatable, Recovery, Provider Urgency and Value Density.
CVSS 4 introduces clearer nomenclature: CVSS‑B for base only, CVSS‑BT for base plus threat, CVSS‑BE for base plus environmental and CVSS‑BTE for base, threat and environmental metrics. The standard emphasises that the base score alone measures severity, not risk. Threat and environmental context must be added to turn severity into risk.
How to use CVSS for real prioritisation
In 2026, a defensible vulnerability prioritisation strategy combines three independent inputs:
- Severity — the CVSS 4 base score tells you how serious the vulnerability is in isolation.
- Exploitability — what is actually happening in the wild, informed by the CISA Known Exploited Vulnerabilities (KEV) catalogue, EPSS probabilities and vendor threat intelligence. The KEV catalogue lists vulnerabilities with confirmed exploitation; EPSS predicts the likelihood of exploitation in the near term.
- Exposure and asset value — whether the affected component is reachable in your environment and how critical the asset is to your business.
A practical workflow looks like this:
- First pass: Immediately prioritise vulnerabilities from the CISA KEV catalogue that affect assets you operate. KEV entries have confirmed exploitation and thus represent the highest risk.
- Second pass: Use EPSS to identify vulnerabilities with a high predicted probability of exploitation that have not yet made it into KEV. These are emerging threats.
- Third pass: Apply environmental context. A CVSS 9.8 vulnerability on an internal, non‑reachable service is very different from the same issue on an internet‑facing application. Use the environmental metrics in CVSS 4 or your own asset‑criticality model to adjust priorities.
- Backlog: Everything else enters a normal remediation queue, sorted by base severity, asset criticality and operational cost. Document the rationale for deferring issues with high base scores but low exploitability or exposure.
- Verify fixes: After remediation, verify that the vulnerability is actually fixed — ideally via re‑scanning or penetration testing rather than closing the ticket based on paperwork.
This approach shifts vulnerability management from “patch everything labelled critical” to a risk‑informed programme. It is auditable: if challenged on why a particular CVE was not patched immediately, you can point to the absence of real‑world exploitation and low exposure. Supplemental metrics in CVSS 4 — such as Automatable (can exploitation be automated?) and Recovery (how hard is recovery?) — provide further nuance when deciding which issues to fast‑track.
Frequently asked questions
When was CVSS 4.0 released?
CVSS 4.0 was officially launched by FIRST on 1 November 2023 and is the current version of the framework.
What is the difference between CVSS‑B, CVSS‑BT, CVSS‑BE and CVSS‑BTE?
CVSS‑B is the base score only. CVSS‑BT includes threat metrics. CVSS‑BE includes environmental metrics. CVSS‑BTE includes base, threat and environmental metrics. The nomenclature makes clear which inputs were used.
Is CVSS 4.0 a measure of risk?
No. The base score measures severity. Risk requires the addition of threat context (are there exploits in the wild?) and environmental context (is the affected system important to you?). CVSS 4.0 explicitly separates these dimensions.
How do CVSS, EPSS and KEV relate to each other?
CVSS provides a standardised way to rate the intrinsic severity of a vulnerability. EPSS predicts the probability of exploitation in the near term. KEV lists vulnerabilities with confirmed exploitation. Using all three allows you to prioritise based on severity, likelihood and evidence of attack.