← gociux.comall insights

Vulnerability management

Which CVEs actually matter? KEV and EPSS, explained for busy teams

Gociux · June 2026 · 6 min read

The National Vulnerability Database publishes roughly 3,000 new CVEs a month. Research behind exploit-prediction models has shown for years that only a small fraction of all CVEs — on the order of a few percent — are ever observed being exploited in the wild. Those two facts together define the real job of vulnerability management: it is not "patch everything," because nobody can. It is find the few percent, fast, with evidence you can defend in front of an auditor or a CISO.

Two free, public signals do most of that work, and many teams still use neither.

CISA KEV: confirmed exploitation, not speculation

The Known Exploited Vulnerabilities catalog is a curated list containing only vulnerabilities with reliable evidence of active exploitation. It is deliberately conservative: inclusion means someone is actually using this against real targets, not that exploitation is theoretically possible.

That makes KEV the strongest single "patch this now" signal that exists. If a CVE in your environment is on KEV, the debate is over — the only open question is your remediation timeline. KEV entries also flag known use in ransomware campaigns, which is exactly the qualifier a payment company's risk register cares about.

The limitation is the flip side of the strength: KEV is reactive. A vulnerability appears only after exploitation is observed and verified. For everything not (yet) on the list, you need a forward-looking signal.

EPSS: the probability of exploitation

The Exploit Prediction Scoring System, maintained by FIRST, takes the opposite approach: a model that estimates, for every published CVE, the probability of exploitation activity in the next 30 days. Instead of a binary list you get a score from 0 to 1, refreshed daily.

EPSS is what lets you triage the thousands of CVEs that are not on KEV. A CVE with an EPSS score of 0.9 deserves attention this week even if no agency has confirmed exploitation yet; a CVE at 0.005 — which is most of them — can usually wait for the normal patch cycle, regardless of how scary its severity score looks.

Why CVSS alone keeps failing you

CVSS measures theoretical severity — what an exploit could do — not the likelihood anyone will build and use one. Huge numbers of CVEs are rated High or Critical by CVSS, and treating severity as priority produces backlogs of thousands of "criticals" that teams learn to ignore. Severity tells you the blast radius; KEV and EPSS tell you whether anyone is lighting the fuse. You need both, but the fuse matters more for ordering the queue.

A working rule of thumb: KEV-listed and present in your environment → emergency change. EPSS above ~0.1 on an internet-facing asset → this sprint. Everything else → ride the normal patch cadence, and let the dashboard prove why that's defensible.

Putting it together in practice

  1. Inventory first. Neither signal helps if you don't know what you run. Scanner output, CMDB, or even a maintained spreadsheet — priority scoring multiplies asset knowledge, it cannot replace it.
  2. Join your findings against KEV daily. The catalog is a small JSON file; matching it against scanner output is an afternoon of scripting and turns "we have 4,000 findings" into "we have 12 confirmed-exploited findings."
  3. Sort the remainder by EPSS, weighted by exposure. An EPSS 0.4 on an internet-facing VPN appliance outranks an EPSS 0.7 on an isolated lab box. Context multiplies probability.
  4. Write the thresholds into policy. "KEV within 7 days, EPSS ≥ 0.1 internet-facing within 14" is a defensible, auditable standard — and a far better conversation with a QSA than a CVSS-based SLA nobody meets.

This is the logic behind the live feed on our homepage: the handful of CVEs shown there are KEV entries enriched with EPSS probabilities — the same two signals, doing in public what your internal pipeline should be doing against your own asset list.

Drowning in a vulnerability backlog?

We build prioritization pipelines on exactly these signals — wired into your scanner, your SIEM, and your ticketing — so your team patches what attackers actually use.

Book a free assessment call