CVSS 4.0 vs 3.1: What Changed and What It Means for Triage

The most important thing in CVSS 4.0 is not a metric. It is a naming convention.

By defining CVSS-B as the name for a base-only score, FIRST conceded in the specification itself what practitioners had been arguing for a decade: a base score is not a risk rating, and reporting one as though it were is a misuse of the standard. Everything else in the release follows from that admission.

CVSS v4.0 was published by FIRST in November 2023. The specification is on first.org and is worth reading directly, because the summaries mostly cover the new metrics and skip the part that changes how you should behave.

Why FIRST Rebuilt CVSS

Version 3.1 had three well-known structural problems.

Score compression. Too many vulnerabilities landed in a narrow band near the top. When roughly half your corpus is 7.0 or above, the score has stopped discriminating.

Scope was applied inconsistently. The S metric was meant to capture impact crossing a security boundary. In practice two competent analysts scoring the same flaw would routinely disagree, and a Scope change swung the number hard.

Temporal metrics were dead weight. Remediation Level and Report Confidence were rarely populated and even more rarely acted on, so the group that was supposed to carry real-world context carried nothing.

The Four Metric Groups: Base, Threat, Environmental, Supplemental

CVSS 4.0 organises scoring into four groups:

• Base: intrinsic characteristics of the vulnerability, constant over time and environment.
• Threat: how exploitation is developing in the real world. Replaces Temporal.
• Environmental: your deployment, your compensating controls, your asset criticality.
• Supplemental: additional context that is explicitly non-scoring. It never changes the number.

That last group is unusual for a scoring standard and genuinely useful, because it lets the spec carry signals that are meaningful to a policy engine without pretending they belong in a single scalar.

CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE: The Nomenclature Is the Point

The naming scheme is normative, not stylistic:

Here is the rule you can apply today: if a tool reports "CVSS 9.1" without a suffix, you are looking at CVSS-B. Almost every published score is CVSS-B, because almost nobody populates Threat and nobody but you can populate Environmental.

What Changed in the Base Metrics

Attack Vector, Privileges Required and the confidentiality, integrity and availability impacts survive largely intact. Three things changed materially.

Attack Requirements: The New Metric Nobody Talks About

CVSS 4.0 adds Attack Requirements (AT), split out from Attack Complexity. The distinction is precise and worth internalising:

• Attack Complexity (AC) now covers measures the *attacker* must overcome, such as defeating ASLR or winning a race they can influence.
• Attack Requirements (AT) covers deployment or execution conditions outside the attacker's control: a specific non-default configuration, a race condition the attacker cannot influence, a particular network position.

This is the metric that finally lets a vector say "yes, this is devastating, but only if you enabled the optional module". Under 3.1 that nuance was crammed into AC and usually lost.

Scope Is Gone: Vulnerable System vs Subsequent System Impact

The Scope (S) flag has been removed. In its place, impact is scored twice:

• Vulnerable System: VC, VI, VA
• Subsequent System: SC, SI, SA

So a hypervisor escape is no longer a boolean flag plus one impact triad. It is explicit: low impact on the guest, high impact on everything downstream, expressed as six values instead of four plus a flag. This is more work to score and dramatically less ambiguous, which is the right trade.

User Interaction Is No Longer a Yes or No

User Interaction (UI) gains a middle value. It is now None, Passive, or Active.

Passive means the victim's ordinary use of the product triggers exploitation, such as viewing a page. Active means they must take a deliberate, deceptive-looking step, such as importing a crafted file. Under 3.1 both collapsed into "Required", which flattened a genuine order-of-magnitude difference in exploitability.

The Threat Group: Exploit Maturity Replaces the Temporal Metrics

The Temporal group is renamed Threat and cut down to a single metric: Exploit Maturity (E), with values Not Defined, Attacked, Proof-of-Concept and Unreported.

Remediation Level and Report Confidence are gone. Good. They were noise.

Exploit Maturity is the point where CVSS reaches toward the ground truth that KEV and EPSS supply, and it is worth being honest about the relationship: Exploit Maturity is a manually assigned label in a vector string, while EPSS is a daily-refreshed model output and KEV is a curated statement of confirmed exploitation. If you have all three, the vector's E value is the one most likely to be stale.

Supplemental Metrics: Safety, Automatable, Recovery, Provider Urgency

None of these change the score. All of them are meant to be consumed by your policy:

• Safety (S): can exploitation cause physical harm? Essential in OT, medical and automotive.
• Automatable (AU): can the attack be reliably automated across many targets? This maps directly onto the SSVC decision point of the same name, which is not an accident.
• Recovery (R): automatic, user-initiated, or irrecoverable.
• Value Density (V): diffuse or concentrated, meaning how much a single successful exploitation is worth.
• Vulnerability Response Effort (RE): low, moderate or high, from the defender's side.
• Provider Urgency (U): Red, Amber, Green or Clear, the vendor's own view.

Automatable: Yes is arguably the most operationally useful single field in the whole 4.0 specification, and it changes no number at all. Wire it into your policy as an escalation trigger. It is also the natural bridge into a decision-tree approach such as SSVC, which uses the same concept as a first-class input.

Migrating a 3.1 Vector: A Side-by-Side Table

Living With Both Versions at Once

Scoring in 4.0 does not use a closed-form formula. It uses a MacroVector lookup with interpolation, which is why you cannot mentally convert a 3.1 vector to a 4.0 number, and why any third-party "CVSS converter" should be treated as fiction.

Two rules follow, and both are about data modelling rather than maths:

1. Store the full vector string, not just the number. A bare 8.8 is unrecoverable. CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N can be rescored, filtered and audited forever.
2. Never sort a mixed-version list by the raw number. Keep 3.1 and 4.0 in separate columns. A blended sort is meaningless, and it will silently reorder your queue.

Expect the mixed reality to persist for years. A single record may carry a 3.1 vector from one provider and a 4.0 vector from another, or neither, since as we covered in where CVE data actually comes from, enrichment is not guaranteed to happen at all. Any threshold you copy from a 3.1 policy into a 4.0 policy will select a different population of vulnerabilities than you expect, so re-derive your bands against your own corpus before you trust them. If you are rebuilding your patch tiers around this, our patch management framework is the piece that turns bands into deadlines.

What CVSS 4.0 Still Does Not Tell You

CVSS 4.0 is a better severity standard. It is still a severity standard.

Even a fully populated CVSS-BTE tells you how bad exploitation would be given your environment. It does not tell you how likely exploitation is, and it never claims to. That is EPSS's job, and confirmed exploitation is KEV's job. We set out the division of labour in detail in CVSS vs EPSS: which score matters more, and the short version is unchanged by 4.0: severity, likelihood and confirmed exploitation are three different questions, and you need answers to all three.

That combination is exactly what our risk scoring computes, and you can see the resulting ordering across the whole corpus in the CVE screener.

Adopt 4.0. Keep the vector. Stop calling any of it risk.