EPSS score explained for Kubernetes operators

If you run Kubernetes, you have a vulnerability list, and it is sorted by CVSS. Sorting by CVSS is how a team ends up patching a never-exploited 9.8 in an image-processing library while the 7.5 in the ingress controller that has a public exploit waits in the second screen. EPSS exists to fix that ordering. It is free, daily, covers every CVE, and most scanners already show it — but the number is widely misread. This post says what it measures, how to read it, which threshold to act on, and shows what it does to a real cluster's list.

What the number measures

EPSS — the Exploit Prediction Scoring System, run by FIRST.org — publishes, for every CVE, the probability that it will be exploited in the wild in the next 30 days. It is a model output, trained on observed exploitation activity (from honeypots, IDS telemetry and vendor feeds) against a large set of features: the CVE's age, the affected vendor, whether exploit code is public, whether it is in the CISA KEV catalogue, references, CWE, CVSS vector components, and so on. The model is refit periodically — the current major version, EPSS v4, shipped in March 2025 — and the scores are recomputed every day.

Three things follow from that definition that are easy to miss:

• It is a probability, not a rating. 0.05 means five in a hundred. The median CVE is below 0.01. A "high" EPSS is anything over about 0.1.
• It is about the CVE, not about you. EPSS says nothing about whether the vulnerable package is in your images, whether the vulnerable code path is reachable, or whether the pod is exposed. It is one input to prioritisation, not a verdict.
• It changes. A CVE with EPSS 0.004 on the day it is published can be at 0.6 a week later once an exploit is public. Whatever you do with the score has to be re-evaluated daily or it is wrong.

Score versus percentile

Every EPSS record carries two numbers, and they are for different jobs:

{
  "cve": "CVE-2021-44228",
  "epss": "0.97",
  "percentile": "0.99",
  "date": "2026-08-27"
}

The score is the probability. The percentile is the share of all scored CVEs with a lower score — here, 97.5% of CVEs are less likely to be exploited. The percentile is the number to read when a score looks small: 0.03 sounds negligible and is around the 90th percentile, because the distribution is so skewed. It is also the number never to compute with. Percentile is uniform by construction, so a formula that multiplies by it asserts that the median CVE has a 50% chance of exploitation, which is off by two orders of magnitude.

Which threshold to act on

FIRST deliberately publishes no threshold, and the honest answer is that the right one depends on how much you can fix. Two reference points are in wide use:

The exact percentiles drift as the model is refit, so read them as bands rather than constants. A workable policy for a platform team is: everything in CISA KEV first, regardless of score; then EPSS ≥ 0.1, sorted by CVSS; then everything else, fixed in bulk by moving to newer base images. That is roughly a third of the findings on most clusters, and it is the third that matters.

A worked example

Take five findings that turn up in almost every Debian-based image — the kind of list any cluster with an ingress controller and a few Python or Node images produces. Sorted by CVSS they look like this. The KEV column is a fact; the EPSS values are rounded from a recent day and will have moved by the time you read this, which is rather the point:

The three 9.8s are real vulnerabilities in real packages, and they are in almost every Debian-based image on the planet. They are also, per EPSS, less likely to be exploited than 90% of CVEs — the minizip one is in a component most binaries never link. Number four is the libwebp bug that was used in the wild against browsers and is in the KEV catalogue; number five is the OpenSSH regression that had a public exploit within days. Sorted by the Radar Score contribution — CVSS weighted by exploitation, with KEV as certainty — the same five come out as:

Across a whole cluster the effect is larger than five rows suggest. Because the EPSS distribution is so skewed, the KEV-or-EPSS-≥-0.1 set is typically one to two percent of a cluster's findings, concentrated in a handful of images — and those images are usually fixed by a chart bump or a base-image update rather than by touching a package. The remaining findings are not ignored; they are closed in bulk by the same base-image rebuilds. Nobody has to read them one at a time.

Where EPSS is weak

• No CVE, no score. GHSA and PYSEC advisories without a CVE alias, and every MAL- malware record, are unscored. A scanner has to pick a rule for them; "treat as zero" buries real findings and "treat as one" floods the top. StackRadar treats them as typical and shows EPSS —.
• It lags on brand-new CVEs. The model has few signals on day one. A CVE with a working exploit on GitHub can sit at 0.01 for a day or two before the score catches up. KEV and vendor advisories are the day-one signal.
• It knows nothing about reachability. A high-EPSS CVE in a library your binary never calls is still a high-EPSS CVE on the list. VEX statements are the tool for that, and they are a separate, slower conversation.

Using it tomorrow

If your scanner shows EPSS, sort by it once and look at what moves. If it does not, the API takes a comma-separated list of CVE IDs and the daily CSV is a single file. In StackRadar every finding carries its EPSS score and percentile, both re-synced daily, and the ranking above is the default sort — the point is that nobody should have to do the join by hand.

Frequently asked questions