CVE and CVSS: How Vulnerability Scoring Actually Works

Two separate systems are at work here, and conflating them is the first mistake. CVE is an identifier. CVSS is a score. One names the vulnerability; the other estimates its severity. They come from different organizations, answer different questions, and have different failure modes.

CVE: a license plate for vulnerabilities

CVE stands for Common Vulnerabilities and Exposures. It's a catalog, run by the nonprofit MITRE with funding from the U.S. Cybersecurity and Infrastructure Security Agency, that assigns each publicly disclosed vulnerability a unique identifier in the form CVE-YEAR-NUMBER. The point is purely coordination: so that a researcher, a vendor's advisory, a scanner, and a news article are all unambiguously talking about the same bug.

A CVE ID says nothing about severity. It doesn't even guarantee the flaw is exploitable — it asserts that a distinct vulnerability has been identified and described. IDs are issued by a network of CVE Numbering Authorities (CNAs): MITRE itself, plus major vendors like Microsoft, Google, and Red Hat who are authorized to assign IDs for their own products. This is why a vendor advisory can ship with a CVE number on day one.

CVSS: turning a flaw into a number

The Common Vulnerability Scoring System, maintained by the FIRST organization, is the formula that produces the 0.0–10.0 severity rating. It works by scoring a set of metrics about how a vulnerability can be exploited and what happens if it is, then running them through a published equation. The Base score — the one almost always quoted — is built from metrics in two groups.

Exploitability metrics	Impact metrics
Attack Vector — network, adjacent, local, or physical	Confidentiality — can data be read?
Attack Complexity — how much has to go right for the attacker	Integrity — can data be altered?
Privileges Required — none, low, or high	Availability — can the system be knocked offline?
User Interaction — does a victim have to click something?	Scope — can the impact spread beyond the vulnerable component?

A flaw that is reachable over the network, needs no privileges, needs no user interaction, is easy to exploit, and fully compromises confidentiality, integrity, and availability scores at or near 10.0. That's why Log4Shell (CVE-2021-44228) — remotely triggerable by a logged string, with full remote code execution — landed at 10.0. The metrics get packed into a "vector string" like CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which is the real, auditable content; the single number is just its summary.

The qualitative bands most people actually use map like this:

• 0.0 — None
• 0.1–3.9 — Low
• 4.0–6.9 — Medium
• 7.0–8.9 — High
• 9.0–10.0 — Critical

Why the base score lies by omission

Here's the crucial part the headlines skip: the Base score is intentionally context-free. It describes the vulnerability in the abstract, as if every affected system were equally exposed and equally important. It says nothing about whether your instance is reachable, whether an exploit exists in the wild, or whether the affected component even handles sensitive data.

A CVSS base score measures a vulnerability's intrinsic properties, not your risk. Risk is base score filtered through your environment, your exposure, and whether anyone is actually exploiting it.

CVSS itself acknowledges this with Temporal and Environmental metric groups designed to adjust the base score for exploit maturity and your specific deployment — but almost nobody quotes those, because they require analysis. A "critical 9.8" remote code execution in a service you don't run, or that sits behind a firewall with no network path to an attacker, may be a non-issue for you. Meanwhile a "medium 5.3" information leak in a component sitting on your authentication path could be the thing that actually gets you breached.

The triage signals that beat the number

Mature security teams stopped patching strictly by CVSS years ago, because doing so means chasing thousands of high-scored flaws that no one is exploiting while a handful of actively-weaponized medium-scored ones do real damage. Two data sources have become essential complements:

• CISA's Known Exploited Vulnerabilities (KEV) catalog — a list of CVEs with confirmed, observed exploitation in the wild. Presence on the KEV list is a far stronger "patch this now" signal than any base score.
• EPSS (Exploit Prediction Scoring System) — also from FIRST, this estimates the probability that a given CVE will be exploited in the next 30 days. It answers "how likely?" where CVSS answers "how bad if?"

Used together the picture sharpens: CVSS tells you the potential blast radius, EPSS tells you the odds someone lights the fuse, and KEV tells you whether the fuse is already lit. A flaw that is high on all three is a genuine fire drill. A 9.8 that's low-EPSS and absent from KEV can often wait for the regular patch cycle.

What this means for choosing software

For someone evaluating tools rather than running a security team, the practical takeaways are simpler but no less useful. A long CVE history isn't automatically damning — it often means the software is widely used and actively scrutinized, which is healthier than silence. What matters more is the vendor's response: do they assign CVEs to their own flaws (a sign of maturity), publish clear advisories, and ship fixes promptly? That posture connects directly to supply-chain risk, and a transparent disclosure culture is a feature, not an embarrassment.

The deeper point is that a single number is a starting gun, not a finish line. "9.8 critical" should prompt the question "critical to whom, exploitable how, and is anyone actually using it?" — not an automatic panic. Vulnerability scoring is a tool for prioritizing finite attention. Treat the score as the headline and the vector string, KEV, and EPSS as the article.