CVSS v4 Guide: Metrics, Scoring Changes and How to Use Scores Well

CVSS v4.0 is the current version of the Common Vulnerability Scoring System, the open standard from FIRST that describes how severe a software vulnerability is as a number from 0.0 to 10.0 plus a vector string showing how that number was reached. Put simply, it answers "how bad could this flaw be in a reasonable worst case?", not "how likely is it to hurt us?". FIRST first published version 4.0 on 1 November 2023, replacing v3.1, and most CVE records, scanners and advisories now carry v4.0 vectors alongside or instead of v3.1. This guide explains the metric groups, what changed from v3.1, how to read a vector, and how to use the score properly with threat and asset data. It is written for vulnerability analysts, product security teams and anyone who has to defend a remediation queue.

Key takeaways

• Severity is not risk. FIRST's own user guide and FAQ say a Base score measures severity and should not be used on its own to prioritise patching.
• Four metric groups, three of them scored. Base, Threat and Environmental change the number; Supplemental metrics such as Automatable and Safety add context but never change the score.
• Always say which score you mean. v4.0 labels scores CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE so the reader knows whether threat and environment were applied.
• Scope is gone and impact is split. Impacts are scored separately for the vulnerable system and for subsequent systems, and a new Attack Requirements metric sits beside Attack Complexity.
• The consumer finishes the score. Suppliers and CNAs publish Base; applying Threat and Environmental metrics is, in FIRST's words, the responsibility of the CVSS consumer.

What it is

CVSS is maintained by the CVSS Special Interest Group at FIRST (Forum of Incident Response and Security Teams). The standard consists of a specification, a user guide, an implementation guide, worked examples, an FAQ and an official calculator, all published at first.org. The current specification and user guide are document version 1.2 (user guide dated 14 November 2025); the metrics themselves have not changed since the November 2023 release.

A CVSS assessment produces two things:

• A vector string: for example 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. It always starts with CVSS:4.0, lists metrics in a fixed order separated by slashes, and is the part that carries real information.
• A score and severity rating: a number from 0.0 to 10.0 mapped to a qualitative band. The bands are the same as in v3.1.

CVSS sits next to two related identifiers: the CVE ID that names the vulnerability and the CWE that names its weakness class. See the CVE, CWE and CPE Guide.

How it works

The four metric groups

Two defaults matter. Exploit Maturity Not Defined is scored as Attacked, so the Threat group can only hold a score steady or lower it, never raise it. Security Requirements Not Defined are treated as High. In both cases, leaving a field blank gives you the reasonable worst case.

What changed from v3.1

• Scope removed: the v3.1 Scope metric (Unchanged or Changed) is replaced by separate impact metrics for the vulnerable system and for subsequent systems. A flaw in a hypervisor or a browser sandbox now shows exactly which impacts land downstream, rather than a single flag.
• Attack Requirements added: the FAQ separates built-in obstacles the attacker must evade, such as ASLR or DEP, which stay under Attack Complexity, from conditions in the deployment, such as winning a race condition or needing an on-path position, which go under AT.
• User Interaction refined: three values instead of two. In the FAQ's examples, reflected XSS where the victim must click a crafted link is Active; stored XSS that fires during normal browsing is Passive.
• Temporal renamed Threat: Remediation Level and Report Confidence were retired and Exploit Code Maturity became Exploit Maturity.
• New scoring method: v4.0 does not use the weighted formula of v3.x. The SIG grouped roughly 15 million possible full vectors into 270 equivalence sets, which experts ranked and mapped onto 101 possible scores, and the calculator interpolates within those sets.
• Multiple Base scores allowed: a supplier may publish different CVSS-B scores for different platforms or versions of the same product.
• Supplemental group and nomenclature: both are new in v4.0.

Because the method changed, v3.1 and v4.0 scores are not directly comparable, a point the FAQ states plainly. FIRST's examples show the shift: Log4Shell (CVE-2021-44228) is 10.0 in v3.1 and 9.3 in v4.0; Heartbleed (CVE-2014-0160) moves from 7.5 to 8.7; Shellshock (CVE-2014-6271) from 9.8 to 9.3. All three are in the CISA KEV catalogue, which is a reminder that a fraction of a point either way says nothing about whether a flaw is being used.

Reading the nomenclature

• CVSS-B: Base only. This is what a CVE record or vendor advisory usually gives you.
• CVSS-BT: Base plus Threat, for example after setting E:U for a flaw with no known exploit.
• CVSS-BE: Base plus Environmental, for example after setting CR:H on a database holding customer data.
• CVSS-BTE: all three. The user guide says this combined score comes much closer to a measure of risk than Base alone.

Why it matters

CVSS is the shared severity language between suppliers, CNAs, scanners and regulators, and many remediation SLAs are still written in CVSS bands. Using it well means using the vector, not just the number, and finishing the score with your own data. The live Vulnerability Prioritisation Guide covers how to build a full queue from CVSS, EPSS, KEV and SSVC; this section covers the CVSS-specific parts.

Decision guidance

How to adopt v4.0 in a programme

1. Inventory where CVSS is consumed: scanner exports, SLA policy, ticket rules, dashboards, exception forms and contracts. Note which version each reads today.
2. Store the vector, version and source: keep the full vector string, the CVSS version and who scored it (CNA, NVD, CISA ADP, vendor, internal). Never store only the number.
3. Run v3.1 and v4.0 side by side: for one or two patch cycles, compute both queues and compare. Expect movement in both directions; record which items changed band.
4. Add Threat automatically: set E:A for anything in KEV or with confirmed exploitation, E:P where public exploit code exists, and E:U otherwise. Re-evaluate daily, because exploit status changes faster than Base.
5. Add Environmental from asset data: map data classification to CR, integrity criticality to IR and recovery objectives to AR. Start with your crown-jewel systems rather than the whole estate.
6. Rewrite SLAs against labelled scores: for example "CVSS-BTE 9.0 or above, or KEV listed, within 7 days". Say which label the SLA uses. See the Remediation SLAs and Vulnerability Exceptions Guide.
7. Keep a rollback path: retain v3.1 vectors where suppliers still publish them and version your scoring rules, so the queue can be reverted if the new view misbehaves.

Measuring whether it works

• Vector coverage: percentage of open findings with a stored v4.0 vector and source (target above 95%).
• Enrichment rate: percentage of findings scored as CVSS-BT or CVSS-BTE rather than CVSS-B.
• Queue reduction: number of findings in the top SLA band before and after Threat and Environmental metrics are applied.
• Exploited miss rate: KEV-listed findings that sat outside the top band at the time they were added to KEV (target zero).
• Override evidence: share of Modified Base changes with a linked control record.

Where it maps

Common misconceptions

• "A 9.8 means patch first": a Base score is the worst case across all deployments. The FAQ says Base scores should not be used alone for patch prioritisation. Unexploited flaws on internal, low-value systems often drop sharply once Threat and Environmental metrics are applied.
• "The Threat group makes scores go up when exploits appear": it cannot. Not Defined already equals Attacked, so a newly exploited CVE keeps its Base score while the unexploited ones fall around it.
• "Supplemental metrics change the score": they never do. Automatable, Recovery and Provider Urgency are inputs to your own policy, useful as tie-breakers between similar scores.
• "NVD scores every CVE": no longer routinely. NIST announced on 15 April 2026 that NVD will no longer routinely issue its own separate severity score where the CNA has provided one, and it prioritises enrichment of KEV-listed CVEs. On 28 April 2026 it also corrected about 4,500 v4.0 scores, most of which had been too high. Record the source of every score and expect CNA or CISA ADP scores to be the norm. See the CVE Programme and NVD Backlog Guide.
• "v4.0 and v3.1 numbers can sit in one report": they are produced by different methods. Mixing them in one chart or SLA without a version label misleads the reader.
• "Multiplying CVSS by EPSS gives risk": EPSS is a probability of exploitation in the next 30 days and, per FIRST, relates only to the threat component and should never be treated as a risk score. Use the two side by side, for example as quadrants, not as a product.

A related failure is treating an unscored CVE as a low one. Where the vector is missing, the safe default is to hold the finding in triage, not to drop it to the bottom of the queue. The Top 10 Vulnerability Management Mistakes lists other queue errors.

Related concepts

• EPSS: FIRST's model estimating the probability that a CVE is exploited in the wild within 30 days, published daily. It answers likelihood; CVSS answers severity.
• CISA KEV: the list of vulnerabilities with confirmed exploitation. A KEV entry is the strongest single input for setting E:A.
• SSVC: a decision tree from Carnegie Mellon SEI and CISA using Exploitation, Technical Impact, Automatable, Mission Prevalence and Public Well-being to reach Track, Track*, Attend or Act. NVD began displaying CISA ADP SSVC data alongside CVSS in 2026. See the SSVC Guide.
• Risk-based vulnerability management: combining these signals with asset criticality and ownership. See the Risk-Based Vulnerability Management Guide.
• Chained and library vulnerabilities: the user guide scores each flaw separately and treats chains as guidance, combining the least restrictive exploitability with the most severe impact. Library flaws are scored as a reasonable worst case and should be reassessed in each product, where a product that does not expose the vulnerable function scores 0.
• Identity systems: secrets managers, identity providers and CI/CD runners hold machine credentials that reach many other systems, which is exactly what the subsequent-system impact metrics (SC, SI, SA) and a High CR are meant to express. See the Vulnerability Management Guide.

Practitioner checklist

• Store the full CVSS vector, version and scoring source for every finding, never just the number.
• Label every score you report or put in policy as CVSS-B, BT, BE or BTE.
• Automate Exploit Maturity from KEV, exploit databases and your threat intelligence, and refresh it daily.
• Derive CR, IR and AR from data classification and recovery objectives for your most critical systems first.
• Record the control and evidence behind every Modified Base change.
• Run v3.1 and v4.0 queues in parallel for at least one cycle before switching SLAs.
• Use EPSS and KEV alongside CVSS, never multiplied into it.
• Use MSI:S, MSA:S and Supplemental Safety for OT and medical assets.
• Track the exploited miss rate and investigate every KEV entry that sat outside your top band.

Standards and references

• FIRST: CVSS v4.0 Specification Document
• FIRST: CVSS v4.0 User Guide
• FIRST: CVSS v4.0 Frequently Asked Questions
• FIRST: CVSS v4.0 Examples
• FIRST: EPSS User Guide
• CISA: Stakeholder-Specific Vulnerability Categorization
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: National Vulnerability Database news and updates

Related NHI Mgmt Group resources: Vulnerability Prioritisation Guide · SSVC Guide · CVE, CWE and CPE Guide · Risk-Based Vulnerability Management Guide