When a new flaw lands, two questions come first and they are not the same question. Which flaw is this, exactly, out of the thousands disclosed this year? And how bad is it? Confusing the two is the common mistake. A CVE identifier answers only the first. A CVSS score answers only the second. They are separate systems, maintained by separate organizations, and they compose precisely because each refuses to do the other’s job.
The idea
CVE is an identity system: it assigns every publicly disclosed vulnerability a unique, stable name so that two tools, two vendors, and two analysts can be certain they are talking about the same flaw. CVSS is a measurement system: it maps a vulnerability’s intrinsic technical characteristics to a number from 0 to 10 reflecting severity. The names carry no severity and the scores carry no identity. The subtle part is what CVSS is careful not to claim: the Base score assumes the reasonable worst case and is explicitly an input to risk ranking, not a measure of risk itself.
CVE: a name, and only a name
The Common Vulnerabilities and Exposures system “provides a reference method for publicly known information-security vulnerabilities and exposures.” That is the entire promise: a reference method. Its identifiers exist “as unique, common identifiers for publicly known information-security vulnerabilities in publicly released software packages.” The value is coordination. Without a shared name, a scanner, a patch advisory, and a threat-intel feed each describe the same bug in their own words and nobody can reliably join them. CVE-2021-44228 means one specific Log4j flaw to everyone, everywhere.
The system is operated by “the United States’ Homeland Security Systems Engineering and Development Institute FFRDC, operated by The MITRE Corporation,” which “maintains the system, with funding from the US National Cyber Security Division of the US Department of Homeland Security.” Names are not handed out centrally by MITRE alone. “CVEs are assigned by a CVE Numbering Authority (CNA),” a federated set of vendors, coordinators, and researchers each authorized to mint identifiers within their scope. The identifier format encodes only enough to stay unique: “CVE prefix + Year + Arbitrary Digits,” where “the variable-length arbitrary digits begin at four fixed digits and expand with arbitrary digits only when needed in a calendar year.” Nothing in CVE-YYYY-NNNN tells you whether the flaw is trivial or catastrophic. That is by design; severity is a different system’s problem.
CVSS: a severity, layered
The Common Vulnerability Scoring System “is an open framework for communicating the characteristics and severity of software vulnerabilities.” Its structure is the interesting part. “CVSS consists of three metric groups: Base, Temporal, and Environmental,” and they are layered by how much they change:
- Base “represents the intrinsic qualities of a vulnerability that are constant over time and across user environments.” These are the flaw’s own properties: how it is reached, what privileges it needs, what it can damage. “The Base metrics produce a score ranging from 0 to 10, which can then be modified by scoring the Temporal and Environmental metrics.”
- Temporal “reflects the characteristics of a vulnerability that change over time,” such as whether working exploit code is circulating yet.
- Environmental “represents the characteristics of a vulnerability that are unique to a user’s environment,” letting an organization reweight the score for what the affected asset is actually worth to them.
The Base score, the one people quote, “reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time and assumes the reasonable worst case impact across different deployed environments.” That worst-case assumption is the load-bearing detail. A raw Base of 9.8 does not mean your deployment is on fire; it means that across all plausible deployments, this flaw’s worst realistic impact is severe. The 0-to-10 number maps to a five-band label for humans: per the spec’s rating scale, None is 0.0, Low is 0.1 to 3.9, Medium is 4.0 to 6.9, High is 7.0 to 8.9, and Critical is 9.0 to 10.0.
Why severity is not risk
The trap is to read a CVSS Base as “how much danger am I in.” The specification refuses that reading twice over. First, it tells consumers the Base is only a starting point: “consumers of CVSS should supplement the Base Score with Temporal and Environmental Scores specific to their use of the vulnerable product to produce a severity more accurate for their organizational environment.” Second, and more strongly, it locates real risk outside CVSS entirely: “consumers may use CVSS information as input to an organizational vulnerability management process that also considers factors that are not part of CVSS in order to rank the threats to their technology infrastructure and make informed remediation decisions.”
So the honest pipeline is CVE names the flaw, CVSS Base scores its intrinsic worst-case severity, Temporal and Environmental refine that severity for the moment and the environment, and only then does an organization’s own process, weighing exposure, asset value, and threat activity the score never saw, turn severity into a risk-ranked patch queue. Treating a Base score as the final risk verdict skips every layer the framework’s own authors say you must add.
A high score on an unreachable asset can outrank a lower score on your crown jewels
Because Base assumes worst case and ignores your environment, patch prioritization by raw Base alone is a known failure mode. A Critical (9.0+) on a segmented, internet-unreachable box may warrant less urgency than a Medium on your externally exposed authentication service. That reordering is exactly the work the Environmental group and the out-of-band risk process exist to do.
Related Notes
- OWASP Top 10, which categorizes vulnerability classes, where CVE names individual instances and CVSS scores them
- The Cyber Kill Chain and MITRE ATT&CK, other shared-vocabulary frameworks maintained by MITRE
- Buffer Overflows, the kind of concrete flaw that receives a CVE and a CVSS score
- STRIDE Threat Modeling, design-time threat enumeration versus disclosed-vulnerability tracking
Sources
- “Specification Document,” CVSS v3.1, FIRST. https://www.first.org/cvss/v3.1/specification-document . Supports that CVSS “is an open framework for communicating the characteristics and severity of software vulnerabilities,” the three metric groups and their definitions, that Base “produce[s] a score ranging from 0 to 10” and “assumes the reasonable worst case impact,” the qualitative rating scale (None/Low/Medium/High/Critical bands), and that consumers “should supplement the Base Score” and use CVSS “as input to an organizational vulnerability management process that also considers factors that are not part of CVSS.”
- “Common Vulnerabilities and Exposures,” Wikipedia. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures . Supports that CVE “provides a reference method for publicly known information-security vulnerabilities and exposures,” serves as “unique, common identifiers … in publicly released software packages,” is maintained by the MITRE-operated FFRDC “with funding from the US National Cyber Security Division of the US Department of Homeland Security,” that “CVEs are assigned by a CVE Numbering Authority (CNA),” and the “CVE prefix + Year + Arbitrary Digits” identifier format.