EPSS—the Exploit Prediction Scoring System—provides something CVSS doesn’t: an estimate of how likely a specific CVE is to be exploited in the next 30 days, based on observed exploitation patterns and vulnerability characteristics. Updated daily by FIRST, EPSS scores range from 0 to 1, with higher scores indicating higher exploitation probability.
The appeal for vulnerability prioritization is obvious. If you’re choosing between two CVEs with the same CVSS score, the one with a higher EPSS score is more likely to be exploited in the near future. Working the higher-EPSS CVE first is rational risk prioritization.
Where EPSS falls short in container environments—and where it becomes most powerful when combined with additional data—is the gap between “this CVE is likely to be exploited somewhere” and “this CVE is actually exploitable in this specific container deployment.”
What EPSS Measures and What It Doesn’t?
EPSS estimates exploitation probability in the wild—not exploitation probability in your specific environment. The model is built on data about CVE exploitation across the internet broadly: which CVEs are being actively exploited in honeypots and threat intelligence feeds, what characteristics of the CVE correlate with exploitation (public exploit code, ease of exploitation, affected component prevalence).
This is valuable data. But it’s population-level data. A CVE with a high EPSS score is being exploited broadly; that doesn’t mean it’s exploitable in your specific application container.
The gap is most significant in container environments where the same package may be present in an image but not loaded by the application. A high-EPSS vulnerability in curl is genuinely dangerous in environments where curl is used in an internet-facing context. In a container where curl is installed as an incidental OS package but the application never calls it, the high-EPSS score reflects risk in other environments, not in this one.
The EPSS + reachability combination closes this gap.
Combining EPSS with Runtime Execution Context
Automated vulnerability remediation programs in container environments that layer EPSS data on top of runtime execution profiling produce a more accurate prioritization signal than either alone:
High EPSS + executes at runtime: Genuine high priority. The CVE is likely being exploited broadly and the vulnerable component is active in this container. This is the combination that demands urgent attention.
High EPSS + does not execute at runtime: The CVE is dangerous in environments where the package runs. In this container, the package doesn’t execute. Remove the package through image minimization—this eliminates the CVE without patching and without the theoretical exploitation risk materializing.
Low EPSS + executes at runtime: The CVE is present and reachable, but currently unlikely to be exploited. Monitor and remediate within standard SLA timelines.
Low EPSS + does not execute at runtime: Lowest priority. The CVE is in a dormant package with low current exploitation probability. Remove the package opportunistically.
This matrix produces a prioritization framework where the actionable queue—CVEs in executing packages with high exploitation probability—is a fraction of the total CVE inventory.
Reading EPSS Data Effectively
EPSS scores have non-intuitive distribution characteristics that matter for threshold setting:
The distribution is extremely skewed. The vast majority of CVEs have EPSS scores below 0.1 (10% probability of exploitation in 30 days). Only about 3-5% of CVEs have EPSS scores above 0.1. A threshold of 0.1 (10% exploitation probability) filters to the top few percent of CVEs by exploitation likelihood.
EPSS scores change. Daily updates mean a CVE’s score can change significantly as new exploitation data emerges. A CVE that was EPSS 0.02 six months ago may be EPSS 0.85 today if a public exploit was released. Vulnerability management systems that cache EPSS scores without refreshing them are using stale data.
Absolute EPSS thresholds need calibration. An EPSS threshold that’s appropriate for a high-security environment (financial institution, government contractor) may be more conservative than what’s appropriate for a lower-risk environment. The appropriate threshold depends on the organization’s risk tolerance and the cost of remediation.
Practical Steps for EPSS Integration
Add EPSS to your vulnerability management data model. If your current vulnerability management platform doesn’t ingest EPSS data, evaluate whether it can be added through API integration. FIRST provides EPSS data as a downloadable CSV and through an API.
Define EPSS thresholds before using them for prioritization. Decide what EPSS score constitutes “high exploitation probability” in your context before applying thresholds. Typical choices: 0.1 (top ~3-5% of CVEs), 0.5 (top 1%), or 0.9 (very high probability of near-term exploitation). Document the threshold and the reasoning.
Cross-reference EPSS against CISA KEV. Container CVE response programs that monitor both EPSS and KEV get complementary signals: EPSS provides a probabilistic forecast; KEV provides confirmed exploitation evidence. CVEs that are high-EPSS but not yet in KEV may be approaching KEV inclusion; treat them with elevated priority.
Track EPSS score changes for your highest-priority CVEs. EPSS scores for specific CVEs can change as new exploitation data emerges. A monitoring process that alerts when a CVE’s EPSS score crosses a threshold—indicating increasing exploitation activity—enables proactive response before the CVE appears in KEV.
Report on EPSS-based prioritization accuracy. After operating EPSS-prioritized remediation for two to three quarters, review whether the CVEs you prioritized based on high EPSS scores subsequently appeared in KEV or in threat intelligence feeds as actively exploited. This retrospective analysis validates the framework and identifies calibration adjustments.
Frequently Asked Questions
What is EPSS and how does it help with vulnerability prioritization?
EPSS (Exploit Prediction Scoring System) is a probabilistic model maintained by FIRST that estimates the likelihood a CVE will be exploited in the next 30 days, updated daily based on real-world exploitation data. For vulnerability prioritization, EPSS provides a signal CVSS lacks: current exploitation probability rather than theoretical severity. A CVE with a high EPSS score is being exploited broadly now or is structurally similar to CVEs currently being exploited—making it a more urgent remediation target than a high-CVSS CVE with no exploitation activity.
How do you combine EPSS with runtime reachability for container vulnerability prioritization?
The most effective container vulnerability prioritization combines EPSS with runtime execution profiling: a high-EPSS CVE in a package that executes at runtime is a genuine urgent finding, while a high-EPSS CVE in a package that doesn’t execute in the container should be handled by removing the package through image minimization rather than patching. This combination closes the gap between population-level EPSS data (which measures exploitation across all environments) and environment-specific risk (which depends on whether the vulnerable package actually runs in your container).
What EPSS threshold should be used to prioritize vulnerabilities?
EPSS score distributions are highly skewed—most CVEs have EPSS below 0.1 (10% probability of exploitation in 30 days), with only 3-5% of CVEs exceeding that threshold. Common thresholds used for vulnerability prioritization tiers are: 0.1 (top ~5% by exploitation probability, appropriate for elevated attention), 0.5 (top ~1%, appropriate for urgent remediation), and 0.9 (very high probability, treat as near-certain exploitation). The right threshold depends on your organization’s risk tolerance; document the chosen threshold and the reasoning before applying it to remediation queues.
How does EPSS relate to the CISA KEV catalog in a vulnerability prioritization framework?
EPSS and CISA KEV are complementary signals: KEV provides confirmed exploitation evidence (binary—a CVE is in KEV or not), while EPSS provides a probabilistic forecast of near-term exploitation. CVEs with high EPSS scores that aren’t yet in the KEV catalog may be approaching inclusion—they represent the early-warning tier of the prioritization stack. A complete vulnerability prioritization framework uses KEV as the highest-urgency signal, high-EPSS-plus-reachable as the second tier, and CVSS severity as context for the remainder.
The Signal Stack
No single prioritization signal is sufficient. The stack that produces the most accurate prioritization for container CVEs:
- KEV membership — confirmed exploitation, highest urgency
- High EPSS + executes at runtime — likely exploitation, confirmed reachable
- High EPSS + doesn’t execute at runtime — likely exploitation elsewhere, remove the package
- CVSS tier + executes at runtime — severity context for remaining findings
- Standard SLA — everything else
EPSS is most valuable in the second tier—catching CVEs that are being actively exploited in the wild before they appear in KEV, for components that actually run in the specific container environment. At that tier, EPSS + runtime reachability provides earlier warning and better prioritization than CVSS alone.