What Are CVEs and CVSS? Making Sense of Vulnerability IDs and Scores

You have seen the codes even if you never thought about them. CVE-2021-44228. CVE-2014-0160. They turn up in news stories, security bulletins, and the little red badges on this very blog. Alongside them there is usually a number out of ten, and a colour, "9.8, Critical" in menacing red. Most people nod along without ever being told what these things actually are. They are not jargon meant to exclude you. They are two simple, useful systems: one for naming vulnerabilities, and one for scoring how severe they are. Once you understand them, security news suddenly reads a lot more clearly.

This is a plain guide to CVEs and CVSS: what they are, who decides them, and the one crucial thing the score does not tell you.

CVE: a name, not a verdict

CVE stands for Common Vulnerabilities and Exposures. It is, at heart, a naming system. When a new vulnerability in some widely used software is publicly disclosed, it gets a unique identifier so that everyone in the world can refer to the exact same flaw without confusion.

The format is simple: CVE, the year, and a number.

CVE-2021-44228
 |     |     |
 |     |     the unique number for this flaw
 |     the year it was assigned
 the naming scheme

That one, for the curious, is Log4Shell. The naming is coordinated by a long running non profit called MITRE, working with many partner organisations around the world who are authorised to assign ids.

The vital thing to grasp is what a CVE id is not. It is not a measure of how dangerous the flaw is. It carries no severity, no score, no judgement. It is purely a label, a way to make sure that when you say "have you patched CVE-2021-44228" and someone else says "yes", you are both talking about the identical issue. Think of it like a case number: it identifies the case, it does not tell you how serious the case is.

CVSS: a score for severity

If the CVE is the name, CVSS is the score. It stands for the Common Vulnerability Scoring System, and it produces a number from 0.0 to 10.0 describing how severe a vulnerability is. Those numbers map onto named bands, which is where the colours come from:

0.0         None
0.1 - 3.9   Low
4.0 - 6.9   Medium
7.0 - 8.9   High
9.0 - 10.0  Critical

So "CVSS 9.8" lands firmly in Critical, and "CVSS 5.5" is Medium. That gives you a quick, standardised sense of how bad a given flaw is in general terms.

The score is not plucked from the air. The main part, the base score, is built from a set of specific questions about the vulnerability. In plain terms:

• Attack Vector: how close does the attacker need to be? Can they exploit it over the internet (worst), or do they need to be on the local network, logged in locally, or physically present (progressively less accessible)?
• Attack Complexity: how hard is it to pull off reliably?
• Privileges Required: do they need an account already, or none at all?
• User Interaction: does a victim have to click or do something, or is it automatic?
• Scope: can the flaw affect things beyond the vulnerable component itself?
• Impact to Confidentiality, Integrity, and Availability: how badly does a successful attack hurt secrecy, correctness, and uptime? These three, by the way, are the CIA triad.

There are two further metric groups, Temporal (which reflects things that change over time, like whether a working exploit exists yet) and Environmental (which lets you adjust the score for your own specific setup). Version 3.1 of CVSS is the one you will see most often, and a version 4.0 also exists.

The number is severity, not your risk

Here is the single most valuable idea in this whole piece, and it trips up even experienced people. CVSS measures severity in the abstract. It does not measure your actual risk. Those are different things, and confusing them leads to bad decisions.

Severity asks "how bad is this flaw in general?" Your risk asks "how bad is this flaw for me, right now?" The answer to the second depends on things the base score cannot know:

• Do you even run the affected software? A perfect 10.0 in a product you do not use is not your problem.
• Is the vulnerable thing exposed? A high score on an internal system with no path to it is very different from the same score on something facing the open internet.
• Is it being actively attacked? A flaw that criminals are exploiting today, right now, deserves your attention over a theoretically scarier one that nobody is using.

That last point has its own crucial resource. The United States agency CISA maintains the Known Exploited Vulnerabilities catalogue, usually called the KEV list: a list of CVEs that are confirmed to be actively exploited in the real world. If a vulnerability is on the KEV list, it jumps the queue, because "attackers are using this today" beats a high score on something nobody is touching.

This is the beating heart of sensible patching: you cannot fix everything at once, so you prioritise by real risk, and CVSS plus KEV are two of the tools that help you do it well.

The takeaway

A CVE is a unique name for a publicly known vulnerability, in the form CVE year number, coordinated by MITRE, and it says nothing about severity on its own. CVSS is a 0.0 to 10.0 severity score built from questions about how the flaw is exploited and how much damage it does, banded from Low to Critical. Both are genuinely useful, but the score measures severity in the abstract, not your risk, which also depends on whether you run the thing, whether it is exposed, and whether it is being actively attacked. Read the CVE as the name, read CVSS as a starting severity, check the KEV list for what is really being exploited, and prioritise your patching on the honest combination of all three.