EPSS score explained for Kubernetes operators

An EPSS score is the probability, from 0 to 1, that a CVE will be exploited in the wild in the next 30 days. CVSS says how bad a vulnerability would be; EPSS says how likely anyone is to use it. The difference matters because your vulnerability list is almost certainly sorted by CVSS, and that is how a team ends up patching a never-exploited 9.8 in an image library while the 8.1 in OpenSSH with public exploit code waits on the second screen.

EPSS is free, updated daily and covers every published CVE, and most scanners already show it. This post covers how to read the score and its percentile, which threshold to act on, what it does to a CVSS-sorted list, and where it falls short.

What an EPSS score measures

EPSS, the Exploit Prediction Scoring System run through FIRST.org, publishes one number per CVE per day: the probability of exploitation in the wild in the next 30 days. It is a model output, trained on exploitation activity reported by data partners and fed features such as the CVE's age, the affected vendor, whether exploit code is public, whether it appears on exploitation lists such as CISA KEV, its references, CWE and CVSS vector. The model is refit every year or two. The current version, EPSS v5 (model v2026.06.15), started publishing on 15 June 2026, replacing v4 from March 2025.

Three consequences are easy to miss:

• It is a probability, not a rating. 0.05 means five in a hundred. The median CVE scores below 0.01, so "high" starts far lower than intuition says.
• It is about the CVE, not about you. EPSS knows nothing about whether the 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 moves. A CVE can sit at 0.004 on the day it is published and above 0.5 a week later once an exploit is public. A decision based on the score has to be re-evaluated daily.

Score versus percentile: read one, compute with the other

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

{
  "cve": "CVE-2023-45853",
  "epss": "0.031790000",
  "percentile": "0.875660000",
  "date": "2026-09-27"
}

The score is the probability: about a 3% chance of exploitation in the next 30 days. The percentile is the share of scored CVEs with a lower score: this one outranks about 88% of them. Read the percentile when a score looks small, because the distribution is so skewed that 3% puts a CVE near the top eighth.

Never compute with the percentile. It is uniform by construction, so a formula that multiplies by it treats the median CVE as having a 50% chance of exploitation, when its actual score is below 1%.

Which EPSS threshold to act on

FIRST publishes no threshold. Its FAQ calls 0.1 "commonly cited in the field but carries no special authority", and the right cut-off depends on how much your team can fix. This is where the common thresholds fall in the full daily file:

These shares drift daily and jump when a new model version ships, so treat them as bands. A workable policy for a platform team:

1. Everything in CISA KEV, regardless of EPSS. KEV is an observation of exploitation; EPSS is a prediction.
2. EPSS ≥ 0.1, sorted by CVSS.
3. Everything else, closed in bulk by moving to newer base images and chart versions rather than one ticket per CVE.

A worked example: five CVEs, re-sorted

Take five CVEs that turn up in many Debian-based images, the kind any cluster with an ingress controller and a few Python or Node services produces. Sorted by CVSS, they look like this. The EPSS values are illustrative, rounded to keep the arithmetic readable, and are not a snapshot of any one cluster or day. The KEV column is fact.

The three 9.8s are real flaws in packages found in a great many images, and nothing says anyone is using them; the minizip one sits in a contrib component most software built on zlib never uses. Number four is the libwebp heap overflow that was exploited in the wild and has been in the KEV catalogue since September 2023. Number five is the OpenSSH regression that had proof-of-concept code circulating within days of disclosure.

Now sort by Radar Score contribution, which weights CVSS by exploitation likelihood and treats KEV as certainty (contribution = 100 × CVSS/10 × likelihood):

The bottom two rows became the top two. Real scores make the gap wider, not narrower: on 27 September 2026, EPSS had the libwebp CVE at 0.9998 and regreSSHion at 0.995, and the three 9.8s between 0.011 and 0.032. Same order, with the openssh finding at 81.

Across a whole cluster the effect is larger than five rows suggest. Only about 4.5% of scored CVEs reach EPSS 0.1, and KEV lists fewer than 2,000 CVEs, so the findings that clear either bar are a small slice of a typical list, usually concentrated in a handful of images. The rest are not ignored. They are closed in bulk by the same chart bumps and base-image rebuilds, so nobody has to triage 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: "treat as zero" buries real findings and "treat as one" floods the top. StackRadar gives them a deliberately low default (the likelihood of an EPSS score of 0.001) and shows EPSS —.
• It lags on brand-new CVEs. The model has few signals on day one, so a CVE with a working exploit on GitHub can sit low until the score catches up. KEV and vendor advisories are the day-one signal.
• Scores step when the model changes. Every new version shifts the whole distribution on the day it starts publishing. If your SLA is keyed to a fixed EPSS number, expect findings to cross it in bulk that day, in either direction.
• It knows nothing about reachability. A high-EPSS CVE in a library your binary never calls still shows up as a high-EPSS CVE. VEX statements are the tool for that, and they are a separate, slower conversation.

Using EPSS 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 full daily file is one download:

# a few CVEs
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2023-4863,CVE-2024-6387"

# every scored CVE (first line names the model version)
curl -sL https://epss.empiricalsecurity.com/epss_scores-current.csv.gz | gunzip | head

In StackRadar every finding carries its EPSS score and percentile, re-synced daily with KEV, and the contribution ranking above is the default order, so nobody has to do the join by hand.

You can see that order on a sample cluster in the live demo without signing up. To check your own cluster first, the free StackRadar CLI scans every running image from your laptop and flags the CVEs that are on the KEV list.

Frequently asked questions