What CVEs, CVSS and the rest of the acronyms actually mean
CVE, CWE, CVSS, EPSS, KEV… We explain in plain terms what each acronym means, how a vulnerability is scored, and how to decide which ones to fix first.
Almost every week, the same message lands at Veritus Code from a client: “we got an alert about a critical CVE, should we be worried?”. The honest answer is almost always “it depends”, and understanding what it depends on is exactly what separates spending the week patching what’s urgent from wasting it patching what’s irrelevant.
This post untangles the acronym soup —CVE, CWE, CVSS, EPSS, KEV— without the unnecessary jargon, and explains how we decide what gets fixed first.
What a CVE is
CVE stands for Common Vulnerabilities and Exposures. It is not a vulnerability itself: it is a unique, public identifier for one specific, already-known vulnerability in one specific product. Think of it as the license plate of a security flaw.
It looks like this:
CVE-2024-3094
│ │
│ └── sequential number
└─────── year the identifier was reservedThe system is coordinated by MITRE with U.S. government funding, but the identifiers are assigned by dozens of authorized organizations called CNAs (CVE Numbering Authorities): vendors like Microsoft, Google or Red Hat, and large open-source projects. When a researcher reports a flaw, the relevant CNA reserves a CVE, and once the details are published it is on the record forever.
Why have a shared number? So that we all talk about the same flaw. Your scanner, the vendor advisory, the news article and our report can all say “CVE-2024-3094” and mean exactly the same thing, with no ambiguity.
A CVE is not a CWE (or an exploit)
This is where most people get lost. Three concepts that are constantly mixed up:
| Acronym | What it is | Example |
|---|---|---|
| CWE | The type of weakness, the generic category | CWE-89: SQL Injection |
| CVE | A concrete instance of that weakness in a real product | CVE-2023-XXXXX: SQLi in plugin X v2.1 |
| Exploit | The code or technique that abuses that CVE | A script that automates the injection |
Put simply: CWE is the disease, CVE is the specific patient, and the exploit is the weapon. A single CWE (SQL injection) spawns thousands of distinct CVEs over the years across different products.
CVSS: putting a number on severity
Knowing a CVE exists doesn’t tell you how much it hurts. That’s what CVSS (Common Vulnerability Scoring System) is for, assigning a score from 0.0 to 10.0:
| CVSS range | Severity |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
That score isn’t arbitrary: it’s computed from metrics like whether the attack is remote or local, whether it needs authentication, whether it requires user interaction, and its impact on confidentiality, integrity and availability. You’ll see it summarized as a “vector” like this:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (Critical)That AV:N (Attack Vector: Network) and PR:N (Privileges Required: None) are what push the number up: anyone, from the internet, with no credentials.
Important nuance: the score you see in the news is the base CVSS, which measures the flaw “in the lab”. The standard also defines environmental metrics to adjust it to your setup. A 9.8 CVE on a server that isn’t exposed to the internet and handles no sensitive data may, for you, be a medium risk.
The problem: there are too many CVEs
In 2024, more than 40,000 new CVEs were published. No company can patch them all at once, so the real question isn’t “is it critical?” but “is it critical, exploitable AND relevant to us… this week?”. Two tools help answer that, and almost nobody uses them:
EPSS — probability it gets exploited
EPSS (Exploit Prediction Scoring System) estimates, from 0 to 100%, the probability that a CVE will be exploited in the next 30 days. It’s a different signal from CVSS: a vulnerability can be 9.8 in severity yet have a 2% EPSS because exploiting it in practice is fiendishly hard. And vice versa.
CISA KEV — what’s already being exploited
The KEV (Known Exploited Vulnerabilities) catalog from the U.S. agency CISA lists the CVEs that are being actively exploited in the real world, right now. If a vulnerability is on the KEV, the debate is over: patch it now. It’s the most actionable list out there.
How we prioritize
When we review a client’s posture, we don’t sort by CVSS alone. We combine three questions:
- Is it exposed? A critical CVE on an internet-facing system weighs far more than the same CVE on an internal tool behind the VPN.
- Is it being exploited? If it’s on the KEV or has a high EPSS, it jumps to the front of the queue, even if its CVSS isn’t a 10.
- What does that system protect? A 6.5 on the server holding your customer data can be more urgent than a 9.1 on a static marketing site.
The result is a short, realistic list of what to touch first this week, not a dump of 300 alerts that paralyzes the team.
“We found a CVE” is not a pentest finding
One detail that separates a scan from a real pentest: saying “the server runs a version with CVE-XXXX” is not, on its own, a serious finding. An automated scanner spits that out in seconds, and half the time the flaw isn’t exploitable in your specific configuration.
Our job is the next step: confirming whether that CVE is actually exploitable in your environment, proving the impact with a reproducible proof of concept and, often, chaining it with other flaws to show the real damage. You can see how we do it phase by phase in our article on the pentesting methodology we follow.
The essentials, in one sentence
A CVE is just a name; CVSS tells you how much it could hurt; EPSS and KEV tell you how much it’s going to hurt for real; and your company’s context decides the order. Managing vulnerabilities isn’t patching everything, it’s patching the right thing before the attacker does.
Want to know which of the CVEs you’re worried about are actually exploitable in your systems? Request a quote and we’ll look at it with you in under 24 hours.