CVSS (Common Vulnerability Scoring System) is an open framework published by FIRST (Forum of Incident Response and Security Teams) for characterising and communicating the technical severity of software vulnerabilities through a standardised numerical score. The current version is CVSS v4.0 (released November 2023), which introduced a fourth metric group and clarified nomenclature to address the persistent misuse of CVSS Base scores as standalone risk measurements. CVSS scores appear in the NVD (National Vulnerability Database), CVE entries, scanner output from Qualys, Tenable, Rapid7, Grype, and Trivy, and in compliance frameworks that specify remediation SLAs based on severity bands — “critical (9.0–10.0) within 15 days, high (7.0–8.9) within 30 days.” The score ranges from 0.0 (no impact) to 10.0 (maximum severity) and maps to five qualitative ratings: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0).
CVSS v4.0 is composed of four metric groups with distinct purposes and distinct intended authors. The Base metrics (CVSS-B) measure the intrinsic, time-invariant characteristics of the vulnerability itself, independent of any specific deployment — the attack vector (Network, Adjacent, Local, Physical), attack complexity, attack requirements (a new v4.0 metric capturing prerequisites like race conditions), privileges required, user interaction, and the impact on confidentiality, integrity, and availability of the vulnerable system and any downstream systems. Base scores are provided by the vendor or the NVD and do not change once assigned for a given vulnerability version. The Threat metrics (formerly Temporal in v3.x, renamed to emphasise threat intelligence) adjust the Base score based on factors that change over time: primarily the Exploit Maturity metric, which captures whether a proof-of-concept exists, whether exploitation is known, or whether active exploitation is occurring — this is where KEV membership directly maps to a CVSS input. The Environmental metrics are provided by the consumer (the organisation deploying the software), not the vendor: they allow the score to be adjusted for the organisation’s specific context — whether the vulnerable component is internet-facing, whether compensating controls are in place, and how critical confidentiality, integrity, and availability are for that specific system in that organisation. The Supplemental metrics are a new v4.0 addition that add contextual information (safety impact for OT/ICS/IoT systems, response effort, provider urgency) without affecting the calculated score. The formal nomenclature introduced in v4.0 — CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE — makes explicit which metric groups were considered in a given score, preventing the common confusion between a raw Base score and a fully contextualised score.
The most consequential and most common CVSS misuse is treating the Base score as a complete risk assessment and prioritising remediation purely by Base score descending. The Base score assumes worst-case deployment in an unmitigated environment and no threat intelligence — it is a measure of theoretical severity, not operational risk. A CVSS 9.8 on a component that is not network-reachable in your environment, has no known exploit code, and is not in the KEV catalog represents far lower operational risk than a CVSS 6.5 that is KEV-listed and being actively used by ransomware groups. CVSS itself is explicit about this: the specification states that Base scores “should not be used alone to assess risk” and that Threat and Environmental metrics are not optional refinements but essential inputs for a meaningful score. The practical consequence for vulnerability management is a two-tier prioritisation model: KEV membership as the mandatory remediation trigger regardless of Base score, and CVSS-BTE (Base + Threat + Environmental) as the scoring basis for everything else. For SBOM-driven vulnerability management, CVSS scores from the NVD are the first-pass filter applied when correlating SBOM components against the CVE database; VEX not_affected assertions are the mechanism for suppressing false-positive CVSS hits where the vulnerable code path is not reachable in the specific product; and KEV membership is the override that escalates any surviving hit to immediate remediation priority regardless of its CVSS-B score.