A scanner finishes its nightly run and hands you 412 findings. Sixty-two are marked critical. Three weeks later, the thing that actually caused an incident was a medium-severity flaw in an internet-facing appliance nobody had looked at twice. That gap between "scored high" and "actually dangerous" is where most vulnerability management programs succeed or stall, and it comes down to three acronyms that get used interchangeably: CVE, CVSS, and EPSS.

They answer three different questions. Mixing them up is the root of a lot of wasted patching effort.

What a CVE Identifier Really Tells You

A CVE is a name, not a judgment. When you see something like CVE-2024-3094, you are looking at a unique public identifier assigned to one specific vulnerability in one specific product. The format is fixed: the letters, the year the ID was reserved, and a sequence number. The number does not indicate order of discovery or importance, and the year is the reservation year, not necessarily the publication year.

Identifiers are issued by CVE Numbering Authorities, which include MITRE, major vendors, and some research organizations. That structure matters because it means not every CVE is created equal in quality. Some entries arrive with a detailed description and references; others sit reserved and unpublished for months. Some get disputed by a vendor and eventually rejected. Some products bundle a dozen separate CVEs for what is effectively one bad code path.

The important limitation: the absence of a CVE does not mean the absence of a vulnerability. Misconfigurations, exposed credentials, weak business logic, and cloud permission mistakes rarely get an identifier at all. A patch-driven program that only tracks CVEs will miss a large share of what actually gets attackers in.

CVSS: Severity in a Vacuum

CVSS, maintained by FIRST, produces a score from 0.0 to 10.0 plus a vector string that shows how the score was derived. For version 3.x, the ratings break down as low (0.1–3.9), medium (4.0–6.9), high (7.0–8.9), and critical (9.0–10.0). Version 4.0 keeps a similar range but refines how the metrics combine.

Base, temporal, and environmental

The base score is what scanners report. It is built from metrics such as attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope, and the impact on confidentiality, integrity, and availability. A vector like CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H scores 9.8 because it needs no credentials, no user action, and a network packet is enough.

Temporal metrics adjust for things like whether exploit code is publicly available or a patch exists. Environmental metrics let you change the base assumptions to match your deployment — for example, marking confidentiality impact as low because the data behind that service is not sensitive.

Here is the catch: most tools only report the base score. A base score describes an abstract worst case where the vulnerable code is reachable, the attacker has a path to it, and the asset matters. Your internal admin panel that only answers on localhost may carry a 9.8 and still be close to irrelevant.

EPSS: The Probability It Gets Exploited

EPSS, also from FIRST, is a different kind of number entirely. It estimates the probability that a given CVE will be exploited in the wild within the next 30 days, expressed as a value between 0 and 1, updated daily. Rather than describing impact, it describes likelihood, based on signals such as published exploit code, proof-of-concept activity, and observed exploitation.

Treat EPSS as a triage aid, not a verdict. It has real blind spots:

• New vulnerabilities score low. A CVE that is two days old has almost no public history to model, so a low probability often just means "not enough information yet."
• Targeted exploitation leaves no trace. A flaw used quietly against a narrow set of victims may never show the public signals EPSS relies on.
• Popularity drives the score. A high EPSS on a component you do not run is noise. A low EPSS on the single gateway everything routes through deserves a second look.

How the Three Fit Together

Think of it as a progression from identity to impact to likelihood:

• CVE tells you what and where — the identifier you use to look things up.
• CVSS tells you how bad it could be if someone got there, in a generic scenario.
• EPSS tells you how likely someone is to try, based on public evidence.
• Your context tells you whether any of it matters here — exposure, data, users, and compensating controls.

Compare two findings. A 9.8 in a build-time library that never ships to production: high severity, low likelihood, no reachable path. A 6.5 in an edge VPN appliance with public exploit code and a rising EPSS: medium severity, high likelihood, directly reachable from the internet. The second one belongs at the top of the list. Also check CISA's Known Exploited Vulnerabilities catalog — if an entry is on it, you no longer need to estimate anything.

A Practical Triage Workflow

1. Confirm the component exists. Verify the version and path, and whether the vulnerable function is reachable. Software composition scans produce false positives constantly through transitive dependencies.
2. Check the KEV catalog. Listed means exploited. Patch on an emergency timeline regardless of scores.
3. Pull EPSS. High probability plus internet exposure moves an item up fast. Low probability on an isolated internal system moves it down.
4. Adjust the CVSS vector. If exploitation needs local access and the host is single-tenant, recalculate. If the service sits behind authentication you actually enforce, the effective attack vector changes.
5. Read the vendor advisory. It sometimes contradicts the score, clarifies that the affected function is off by default, or notes a disputed rating.
6. Decide and record. Patch now, patch on the normal cycle, mitigate, or accept. Write down who decided and why. Six months from now that note saves an argument.

A score is an input to a decision, not the decision itself. If you cannot explain out loud why something is or is not urgent, you have not finished triaging it.

Making It a Habit

Re-evaluate when the world changes. Exploit code appears, EPSS shifts, a vendor revises its advisory, or an asset moves from internal to public. A finding you correctly deprioritized last quarter can become urgent this month without anything changing on your side.

Do not chase perfect scores. Reduce the pattern instead: shrink your attack surface, remove components you no longer use, keep a reliable inventory, and patch fast on the small set of things that face the internet. Reserve deep analysis for that set and for anything already being exploited.

And keep room in your process for the vulnerabilities that will never receive a CVE. An open storage bucket, a forgotten admin endpoint, a service account with domain-wide permissions — none of these will produce a severity rating, and any of them can end your week faster than a 9.8 that nobody can reach.

Photo: Pixabay / Pexels