EPSS Scores: How to Prioritize Vulnerabilities by Exploit Probability

The Problem: 30,000 CVEs Per Year

In 2025, the NVD published over 33,000 new CVE identifiers. In 2024, it was 29,000. The number grows every year as more software is cataloged and more researchers report vulnerabilities. For a typical enterprise running hundreds of containerized services, a comprehensive vulnerability scan might surface thousands of findings across their fleet.

The traditional approach is to prioritize by CVSS severity: fix all Critical findings first, then High, then Medium. This sounds reasonable but fails in practice. Approximately 50% of all CVEs receive a CVSS score of 7.0 or higher (High or Critical). That means half of those 30,000 CVEs are “high priority” according to CVSS alone. No team has the bandwidth to fix 15,000 vulnerabilities a year.

Worse, CVSS measures theoretical impact, not real-world risk. A CVE with a CVSS score of 9.8 (Critical) might never be exploited because no usable exploit exists, the vulnerable code path is rarely triggered, or the affected software is not internet-facing. Meanwhile, a CVE with a CVSS score of 7.5 (High) might have a public exploit kit being actively used by ransomware groups. CVSS alone cannot distinguish between these scenarios.

What Is EPSS?

EPSS (Exploit Prediction Scoring System) is a machine learning model developed and maintained by FIRST.org (the same organization behind CVSS). It estimates the probability that a CVE will be exploited in the wild within the next 30 days.

EPSS outputs a probability score between 0 and 1 (0% to 100%). A score of 0.15 means there is a 15% chance the vulnerability will see active exploitation in the next month. A score of 0.001 means a 0.1% chance. EPSS also provides a percentile ranking showing where a CVE falls relative to all other scored vulnerabilities.

The model is trained on observed exploitation data from multiple sources: IDS/IPS signatures that have triggered, exploit code published on GitHub, mentions in dark web forums, proof-of-concept demonstrations, and CISA KEV additions. It considers over 1,400 features including vulnerability characteristics, time since publication, affected vendor and product, and exploitation signals from threat intelligence feeds.

Critically, EPSS scores are updated daily. A CVE that had a 0.5% EPSS score yesterday might jump to 40% today if a working exploit was published overnight. This dynamic nature makes EPSS far more actionable than static CVSS scores that rarely change after initial publication.

EPSS vs CVSS: Why CVSS Alone Fails

CVSS and EPSS answer fundamentally different questions:

• CVSS asks: “How bad could it be if this vulnerability is exploited?”
• EPSS asks: “How likely is it that this vulnerability will be exploited?”

Consider a real-world analogy: CVSS is like rating the potential damage of a natural disaster (Category 5 hurricane = Critical). EPSS is like the weather forecast telling you the probability of that hurricane actually hitting your area. You would not evacuate every time a Category 5 hurricane forms somewhere in the ocean. You evacuate when the forecast says it is heading toward you.

Research from FIRST.org shows that using EPSS for prioritization is significantly more efficient than CVSS alone:

• Prioritizing by CVSS Critical/High covers only 50% of actually-exploited CVEs while requiring you to address 50% of all CVEs
• Prioritizing by EPSS top 10% covers approximately 80% of actually-exploited CVEs while requiring you to address only 10% of all CVEs

This is an 8x improvement in efficiency. You catch more of the threats that matter while spending less time on vulnerabilities that will never be exploited.

How EPSS Works: The Machine Learning Model

EPSS v3 (the current version) uses a gradient-boosted decision tree model trained on:

• Vulnerability characteristics: CWE type, affected vendor/product, CVSS vector components, age since publication
• Exploit availability signals: Metasploit modules, ExploitDB entries, GitHub proof-of-concept repositories, nuclei templates
• Threat intelligence: Dark web forum mentions, underground marketplace listings, social media discussion volume
• Historical patterns: Exploitation rates for similar vulnerability types, vendor patching velocity, typical time-to-exploit for the CWE class

The ground truth label is binary: was the CVE observed being exploited in the 30-day window following the score date? This data comes from IDS/IPS vendors, honeypot networks, and incident response intelligence sharing.

The model is retrained and scores are recomputed daily. This daily cadence means EPSS can reflect rapid changes in the threat landscape. When a new Metasploit module is published for a CVE, its EPSS score typically increases within 24-48 hours.

Practical Prioritization Matrix

Combining CVSS severity, EPSS probability, and CISA KEV status creates a practical prioritization framework. Here is the matrix we recommend:

This matrix is a starting point. Adjust thresholds based on your organization's risk tolerance and the asset's exposure (internet-facing vs internal).

Real Examples: CVEs with Surprising EPSS Scores

The following real CVEs illustrate why CVSS alone is insufficient for prioritization:

How ScanRook Uses EPSS

ScanRook integrates EPSS data directly into its scanning pipeline. Every vulnerability finding includes:

• EPSS probability: The raw probability score (0.0 to 1.0)
• EPSS percentile: Where this CVE ranks relative to all scored CVEs
• CISA KEV status: Boolean flag indicating active exploitation
• Combined priority: ScanRook computes a priority tier (P0-P4) using the matrix above

In the ScanRook dashboard, findings are sortable by EPSS score, allowing you to immediately see which vulnerabilities have the highest exploitation probability. The findings view also supports filtering by priority tier, so you can focus on P0 and P1 findings that require immediate attention.

For teams using ScanRook in CI/CD, the policy engine can gate deployments based on EPSS thresholds. For example, you can configure a policy that blocks deployment if any finding has EPSS > 50% and CVSS > 7.0, while allowing deployment with findings that have EPSS < 1% regardless of CVSS score.

Implementing EPSS-Based Prioritization

Here is a step-by-step guide to adopting EPSS-based prioritization in your organization:

Step 1: Establish Baseline

Scan your current production workloads and categorize findings using the prioritization matrix. Most teams discover that only 5-10% of their findings are P0 or P1, dramatically reducing the immediate workload compared to “fix all Critical/High” policies.

Step 2: Define SLAs by Priority

Set remediation timelines by priority tier:

• P0: 24 hours (emergency patch or mitigation)
• P1: 7 days (current sprint)
• P2: 30 days (next sprint)
• P3: 90 days (quarterly planning)
• P4: Accept risk or defer (annual review)

Step 3: Monitor EPSS Changes

EPSS scores change daily. A P3 finding today might become P1 tomorrow if an exploit drops. ScanRook's notification settings can alert you when a finding's EPSS score crosses your configured thresholds.

Step 4: Report on Coverage

Track the percentage of P0/P1 findings remediated within SLA. This is a more meaningful security metric than “total open CVEs” because it focuses on actual risk rather than theoretical severity.

Common Pitfalls

• Ignoring low-EPSS Critical CVEs entirely: While they are lower priority, they should still be tracked. EPSS scores can change rapidly when new exploit information emerges. Schedule them for remediation; just do not treat them as emergencies.
• Using EPSS thresholds that are too high:Setting your P1 threshold at EPSS > 50% means you are only reacting to vulnerabilities that are almost certainly being exploited. The 10% threshold catches threats earlier in the exploitation lifecycle.
• Not accounting for asset exposure: An EPSS score of 5% for a vulnerability in an internet-facing service is far more dangerous than the same score for an internal service behind multiple network controls. Adjust your thresholds based on exposure.
• Treating EPSS as absolute truth: EPSS is a prediction model with known limitations. It cannot predict zero-days, it may underestimate targeted attacks against niche software, and it has a false negative rate. Use it as one input among several, not the sole decision-maker.