CVE, CVSS, EPSS, KEV explained for small vendors

When a new vulnerability appears, a small company doesn't need an academic lecture — it needs to know what to do and by when. Four acronyms serve that purpose. Each answers a different question, and together they produce a clear decision. Let's walk through them in plain language and show how we turn them into one verdict.

CVE — which vulnerability it is

CVE (Common Vulnerabilities and Exposures) is simply an identifier, for example CVE-2026-1234. It's a worldwide catalogue of publicly known vulnerabilities so that everyone refers to "the same hole" the same way. A CVE by itself says nothing about how serious it is or whether anyone is exploiting it — it's just a name. The details (CVSS, description, fixed versions) are attached to it from databases like NVD or OSV.dev.

CVSS — how bad it is

CVSS (Common Vulnerability Scoring System) is a severity score from 0 to 10. It expresses the impact exploitation would have: usually split into Low, Medium (≥ 4.0), High (≥ 7.0) and Critical (≥ 9.0). It answers "how bad would it be if someone used it" — but not whether anyone actually is. A high CVSS on a component whose vulnerable function you never call may in practice be a smaller problem than a medium CVSS right in your input path.

EPSS — how likely someone is to use it

EPSS (Exploit Prediction Scoring System, from the FIRST organisation) is a probability from 0 to 1 that a given vulnerability will be exploited in the near term. 0.02 means ~2%, 0.7 means ~70%. Where CVSS says how bad, EPSS says how likely. The combination of the two is more useful than either alone — high severity with high probability is a different league from high severity with near-zero probability.

KEV — who is already exploiting it

KEV (Known Exploited Vulnerabilities) is a public catalogue from the US agency CISA that lists vulnerabilities actively exploited in the real world. If a CVE is in KEV, it's not a theoretical risk — someone is genuinely using it for attacks. For the CRA this is pivotal: the reporting duty under Article 14 attaches to an actively exploited vulnerability. A KEV listing that touches a component in your product is therefore a possible trigger for the 24-hour report — with the caveat that whether it is being exploited in your product is for you to assess.

How we turn this into one verdict

Four numbers are nice, but the decision must be one. So we fold them into three verdicts — Fix now, Plan, Informational — following a fixed order of rules (first match wins):

1. The vulnerability is in KEV → Fix now (actively exploited).
2. CVSS ≥ 9.0 → Fix now (critical severity).
3. CVSS ≥ 7.0 and EPSS ≥ 0.10 → Fix now (high severity and real probability).
4. CVSS ≥ 7.0 → Plan (high severity, low probability).
5. CVSS ≥ 4.0 or EPSS ≥ 0.01 → Plan (medium risk).
6. CVSS unknown → Plan (better to assess than to miss).
7. Otherwise → Informational.

This order has logic: real-world exploitation (KEV) beats everything, critical severity stands on its own, and the combination of high severity with probability pulls a finding up even without KEV. Unknown CVSS deliberately falls to "Plan" — we don't want it dropping off the radar just because it has no score yet.

A worked example on one vulnerability

Imagine CVE-2026-XXXX appears in a library you use, with CVSS 8.1. How do you decide?

1. Is it in KEV? If yes → Fix now, end of debate, regardless of the other numbers.
2. Not in KEV, CVSS 8.1. It isn't ≥ 9.0, so rule 2 doesn't fire. We look at EPSS.
3. EPSS 0.15 (15%). CVSS ≥ 7.0 and EPSS ≥ 0.10 → Fix now (rule 3).
4. Were EPSS 0.03, rule 3 wouldn't fire, but CVSS ≥ 7.0 → Plan (rule 4).

So the same vulnerability ends up as "Fix now" or "Plan" depending on the probability of exploitation — and that's exactly the point: not every high CVSS is firefighting. And if the same CVE reached KEV a week later, the verdict automatically flips to "Fix now" and triggers the Article 14 reporting consideration.

What to take away

For a small company the practical conclusion is simple: KEV and Fix now mean today, the rest can go into a plan. And because new CVEs and new KEV listings arrive daily, this isn't a one-off check but a background process. How you actually report through ENISA's platform once a finding turns out to be "actively exploited" is covered in the Article 14 step by step article.

FAQ

1. Is a high CVSS always "Fix now"? No — CVSS ≥ 9.0 alone yes, but CVSS 7–9 depends on EPSS and KEV. That's why we combine several signals.
2. Where do EPSS and KEV come from? EPSS from the FIRST organisation, KEV from CISA's catalogue — both public, updated continuously.
3. Does "no finding" mean secure? No. Databases don't see 0-days or unknown holes; the absence of a finding is no guarantee.
4. Why does unknown CVSS fall to "Plan"? So a finding doesn't drop off the radar just because it has no score yet — better to assess it.

Why one verdict instead of four numbers

A small company doesn't have the capacity to read four metrics at every finding and decide anew. The point of a verdict is to make the decision for you, and consistently: the same rule, the same thresholds, every time. That also makes the audit trail credible — at an inspection you can show you didn't decide by mood but by a clear rule that puts KEV above everything and combines severity with probability.

How CRAguard helps

CRAguard compares your SBOM daily against OSV, KEV and EPSS, scores each finding with exactly this rule, and shows why it got its verdict in the detail view. "Fix now" reaches you by email immediately, the rest in a weekly digest — so you never catch the 24-hour Article 14 clock too late. Find out whether the CRA applies to you, or join the waitlist.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 14) and the public CVE/NVD, CVSS and EPSS (FIRST) and KEV (CISA) sources. A CRAguard verdict is input for assessment, not confirmation that you are vulnerable or compliant.