Vulnerability Management

CVSS (Common Vulnerability Scoring System)

A 0–10 severity score, maintained by FIRST, describing how bad a vulnerability is in the abstract. It reflects a flaw's properties, not any particular organization's actual risk.

What is CVSS?

CVSS, the Common Vulnerability Scoring System, is a 0 to 10 severity score describing how bad a vulnerability is in the abstract. Maintained by FIRST, it is the most widely used vulnerability metric in security, and it is a description of a flaw's properties rather than a measure of any particular organization's risk.

Key takeaways

  • CVSS scores the flaw, not the environment. It cannot see a network, a call graph or the controls already in place.
  • It marks a great deal as critical. Which makes it a poor sorting key when the queue is large: if everything is urgent, nothing is.
  • It has three metric groups. Base, threat and environmental. Almost everyone uses only the first.
  • It is a starting point. Combining it with exploitation signals and environment-specific reachability is what makes it useful.
  • A high score in unreachable code is not an emergency. And no version of CVSS will say so, because the information it would need is not in the model.

Why it matters

The practical failure is straightforward. A backlog ranked by severity concentrates effort on findings an attacker could not use, while genuinely exploitable exposures, often unremarkable individually and dangerous when chained, wait their turn. Because base metrics assume worst-case conditions in an unspecified environment, a large proportion of published vulnerabilities score above 7.0, and a ranking in which most items are high or critical is not a ranking.

Log4Shell shows the shape of the problem. Every Java installation that shipped the library scored at the top of the scale. If the application was not using that logging engine, the vulnerable code was never callable: loaded, and zero exposure, at maximum severity. The score was accurate about the flaw and useless about the risk.

The three metric groups

  • Base. Intrinsic properties: attack vector, attack complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity and availability. This is the number almost everyone quotes.
  • Threat, formerly temporal. How the situation has evolved: exploit maturity and, in earlier versions, remediation level and report confidence. Rarely maintained after publication.
  • Environmental. Adjustment for a specific context: asset criticality and modified base metrics reflecting compensating controls. Almost never used, because populating it accurately across an estate is a substantial data problem.
  • Supplemental, in version 4.0. Non-scoring context such as safety impact, automatable and recovery, intended to inform decisions rather than move the number.

The irony of the environmental group

The metric group designed to answer the question that actually matters, how much does this matter here, is the one nobody fills in. It requires per-asset criticality ratings, an accurate control inventory and someone to maintain both. Organizations that have that data usually have better ways to use it than adjusting a severity score, and organizations that do not cannot populate the group at all.

The base score, explicitly designed to be environment-agnostic, therefore ends up used as if it were environment-specific. Most criticism aimed at CVSS is really criticism of that substitution.

What to combine it with

  • EPSS. The Exploit Prediction Scoring System estimates the probability a vulnerability will be exploited in the wild. A sharper signal than severity alone, and still global rather than specific to one environment.
  • KEV. The CISA Known Exploited Vulnerabilities catalog records confirmed real-world exploitation. If a vulnerability is listed, the exploitation question is settled.
  • Reachability. Whether the vulnerability can be reached at all over the network, in the call graph and by attacker-controlled data. The only one of these signals that is specific to the environment.
  • Existing controls. A compensating control may already block the attack, which lowers urgency regardless of score, provided the control has been verified rather than assumed.

CVSS 3.1 compared with CVSS 4.0

Version 4.0, published by FIRST in 2023, refines the base metrics, splits user interaction into passive and active, separates impact on the vulnerable system from impact on subsequent systems in place of the older scope metric, renames the temporal group to threat, and adds the supplemental group. The nomenclature also changed, so a score is now qualified as CVSS-B, CVSS-BT or CVSS-BTE depending on which groups were used.

The additions are genuine improvements in expressiveness. They do not change the fundamental property: version 4.0 remains a description of a vulnerability rather than of exposure, and adoption of the threat and environmental groups remains low.

Common misconceptions

  • That CVSS should be abandoned. It is a reasonable universal description of a flaw's properties and a poor work queue. The correct response is to use it as an input, not to discard it.
  • That the score is a risk rating. Risk requires likelihood and business impact in context. CVSS supplies neither.
  • That scores are comparable across sources. Vendors and databases sometimes publish different base vectors for the same CVE, so the provenance of a score matters.
  • That a 10.0 always outranks a 7.5. A reachable, actively exploited 7.5 on a public asset is a more urgent decision than an unreachable 10.0.

Standards and sources

CVSS is maintained by the Forum of Incident Response and Security Teams, with version 3.1 published in 2019 and version 4.0 in 2023. Scores are commonly distributed through the NIST National Vulnerability Database alongside CVE records. Exploitation probability comes from the FIRST Exploit Prediction Scoring System, and confirmed exploitation from the CISA Known Exploited Vulnerabilities catalog.

FAQ

Should CVSS still be used? Yes, as an input. It is a reasonable universal description of a flaw's properties and a poor work queue, so it should be combined with exploitation and reachability signals.

Why does so much score above 7? The base metrics assume worst-case exploitability in an unspecified environment, and most real environments are not worst case.

Is CVSS 4.0 better than 3.1? It adds nuance and supplemental metrics, and it remains a description of the vulnerability rather than of exposure in a specific environment.

What is the difference between CVSS and EPSS? CVSS describes how severe a flaw would be if exploited. EPSS estimates how likely it is to be exploited in the wild within a defined window.

Sources

  • FIRST, Common Vulnerability Scoring System v4.0 Specification Document, 2023.
  • FIRST, Common Vulnerability Scoring System v3.1 Specification Document, 2019.
  • FIRST, Exploit Prediction Scoring System (EPSS) Model, 2024.
  • CISA, Known Exploited Vulnerabilities Catalog, 2026.
  • NIST, National Vulnerability Database, 2026.
  • CVE Program, CVE-2021-44228 (Log4Shell) Record, 2021.