FIRST.org published CVSS version 4.0 in November 2023, the first major revision to the Common Vulnerability Scoring System since CVSS 3.0 arrived in 2015. For eight years, security teams triaged tickets off a single number that conflated four different things: how easy a flaw is to exploit, what it damages, whether anyone is actively exploiting it, and how much a specific organization should care. CVSS 3.1's most infamous flaw was the "Scope" metric — a binary yes/no field so widely misunderstood that FIRST's own documentation needed a dedicated worked example to explain it, and vendors routinely disagreed on how to score the same CVE against it. CVSS 4.0 removes Scope entirely, adds a new Base metric called Attack Requirements, expands User Interaction from two values to three, and — perhaps most consequential for tooling — introduces explicit naming (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) so a published score finally states which metric groups actually went into it. This post walks through what changed, what got renamed, what got dropped, and what it means for teams still triaging purely off a bare Base score.
What happened to the Scope metric?
Scope is gone. In CVSS 3.1, Scope was a single Changed/Unchanged flag meant to capture whether a vulnerability in one component could affect resources beyond it — a container escape being the textbook case. In practice, FIRST found the binary flag collapsed too much nuance into one bit and left scorers guessing at boundaries between "the vulnerable component" and "impacted resources." CVSS 4.0 replaces it with two full sets of Confidentiality/Integrity/Availability impact metrics: Vulnerable System impacts (VC/VI/VA) and Subsequent System impacts (SC/SI/SA). Instead of one flag saying impact "changed," a scorer now separately rates damage to the flawed component and damage to anything downstream it can reach. A SQL injection that only corrupts its own database scores differently — and more legibly — than one that pivots into a connected payment system, without anyone having to interpret what "scope change" means for their specific architecture.
What is Attack Requirements, and why did it need its own metric?
Attack Requirements (AT) is an entirely new Base metric in CVSS 4.0, sitting alongside the familiar Attack Vector and Attack Complexity. It captures preconditions that exist in the target environment but aren't about attacker skill or network position — things like a race condition that only triggers under specific timing, or a vulnerability that requires a non-default configuration to be reachable at all. In CVSS 3.1, this kind of nuance got folded awkwardly into Attack Complexity, which mixed "how hard is this to pull off" with "does this even apply to your setup" into one High/Low value. Splitting them out means two CVEs that both score "Attack Complexity: Low" in 3.1 language can now be differentiated in 4.0: one exploitable against any default install, the other only against a rare configuration — a distinction that matters directly when a team is deciding which of two "critical" tickets to work first.
How did User Interaction get more granular?
CVSS 3.1's User Interaction metric was binary: None or Required. CVSS 4.0 splits "Required" into two values — Passive (P), where a victim performs a routine action unrelated to the attack (like opening a file they already intended to open), and Active (A), where the victim must take a specific, attacker-directed step (like clicking a crafted link or approving a permission prompt) for exploitation to succeed. This matters because phishing-dependent vulnerabilities and drive-by-style flaws were previously scored identically under "User Interaction: Required," even though the former needs deliberate social engineering and the latter can succeed on incidental behavior. Separating them lets a score reflect that a Passive-UI flaw is closer in practical risk to no interaction at all, while Active-UI flaws retain a meaningfully lower likelihood of real-world exploitation — a distinction 3.1 simply couldn't express.
What happened to Temporal metrics, and why the CVSS-B/BT/BE/BTE naming?
The Temporal metric group is renamed Threat in CVSS 4.0, with its values simplified: Exploit Code Maturity becomes Exploit Maturity (E), while Remediation Level (RL) and Report Confidence (RC) are dropped outright as FIRST judged them too rarely populated to be worth the complexity. The bigger structural change is nomenclature. A "CVSS score" in 3.1 was ambiguous — nobody could tell from the number alone whether Temporal or Environmental metrics had been layered on, so two organizations comparing "CVSS 7.5" on the same CVE were sometimes comparing incompatible calculations. CVSS 4.0 fixes this by requiring scores to be labeled: CVSS-B (Base metrics only), CVSS-BT (Base + Threat), CVSS-BE (Base + Environmental), and CVSS-BTE (all three). A vendor bulletin or NVD entry can now state plainly which inputs produced the number, which is a meaningful fix for any team that automates ticket routing off CVSS thresholds.
What are Supplemental Metrics, and why don't they change the score?
CVSS 4.0 introduces an entirely new, optional metric group — Supplemental Metrics — covering Safety (S), Automatable (A), Recovery (R), Value Density (V), Vulnerability Response Effort (RE), and Provider Urgency (U). Per FIRST's specification, none of these six values feed into the final CVSS-BTE calculation; they're deliberately extrinsic, published alongside a score rather than folded into it. The intent is to give downstream consumers — especially OT/ICS vendors and incident responders — a standardized vocabulary for context that CVSS previously had no field for at all, like whether exploitation could cause physical harm (Safety) or whether an exploit can be scripted at scale (Automatable), without corrupting the comparability of the core score across every other CVE in the world. A vendor can now say "CVSS-B 8.1, Safety: Present, Automatable: Yes" instead of manually inflating or footnoting a Base score to convey urgency it wasn't designed to carry.
What does this mean for how teams should prioritize vulnerabilities?
CVSS 4.0's changes reinforce a conclusion the security field had already been reaching independently: no single score, however refined, should be the sole input to a fix-it-now decision. FIRST built 4.0 explicitly to move teams away from over-reliance on the bare Base score — but even a well-labeled CVSS-BTE score only measures theoretical severity and threat intelligence, not whether your specific application ever executes the vulnerable code path, or whether it's already under active exploitation this week. That's why frameworks like EPSS (exploit prediction) and reachability analysis exist as complements, not substitutes. Safeguard's platform reflects this directly: vulnerability records surface CVSS score alongside EPSS probability, CISA KEV exploited-in-the-wild status, and call-path reachability side by side, and Griffin AI weighs all four together — plus asset criticality and exposure — when it recommends what to fix first. A CVSS-BTE 9.1 finding in code nothing ever calls should rank below a CVSS-B 7.2 finding with a KEV entry and a live, reachable call path. Getting the severity math right, as CVSS 4.0 does, only helps if it's one input among several rather than the whole decision.