If you have spent any time in vulnerability management, you know the pain of staring at a list of thousands of CVEs, each stamped with a CVSS score that tells you roughly how bad they could be, but nothing about how likely they are to actually be exploited. That gap is precisely what the Exploit Prediction Scoring System (EPSS) was built to fill.
What Is EPSS?
EPSS is a model maintained by FIRST (the Forum of Incident Response and Security Teams) that estimates the probability a vulnerability will be exploited in the wild within the next 30 days. The output is a score between 0 and 1, where 0.95 means there is a 95% chance the vulnerability will see active exploitation in the coming month.
The model uses a combination of features drawn from the CVE description, references, timing data, and real-world exploit activity observed by threat intelligence feeds. It is updated daily, so the score for a given CVE can shift as new evidence emerges.
Why CVSS Alone Falls Short
CVSS is a severity metric, not a risk metric. A vulnerability can receive a CVSS 9.8 because it is remotely exploitable and requires no authentication, yet it might affect software that is rarely deployed and has no public exploit code. Meanwhile, a CVSS 7.5 in a widely used library with a Metasploit module is far more dangerous in practice.
Organizations that patch based purely on CVSS scores end up in a perpetual firefight. Every quarter brings hundreds of criticals and highs, and the team burns out trying to address them all with equal urgency. EPSS helps break this cycle by adding a probability dimension.
Consider the numbers. According to research published by FIRST, only about 2-5% of all published CVEs are ever exploited in the wild. That means the vast majority of CVSS-critical vulnerabilities will never actually be weaponized. EPSS helps you focus on the ones that will.
How the Model Works
The EPSS model is a logistic regression trained on a dataset that combines vulnerability metadata with exploit activity data. Key feature categories include:
CVE metadata -- age of the vulnerability, the CWE (weakness enumeration) type, the vendor and product involved, and keywords extracted from the description.
Exploit code availability -- whether public exploit code exists in databases like Exploit-DB, GitHub, or Metasploit.
Threat intelligence signals -- indicators from real-world scanning and exploitation activity, including data from sources like Fortinet, AlienVault, and others.
Social and reference signals -- references to the vulnerability in security advisories, mailing lists, and social media.
The model is retrained regularly and the scoring is transparent. FIRST publishes the full score set daily as a downloadable CSV, which means you can integrate it into your own tooling without relying on a proprietary API.
EPSS vs. CVSS: A Practical Comparison
Let's walk through a concrete scenario. Suppose your scanner surfaces two vulnerabilities:
- CVE-2023-XXXX: CVSS 9.8, affects a niche industrial control system library. No public exploit. EPSS score: 0.02.
- CVE-2023-YYYY: CVSS 7.5, affects Apache Commons Text. Public exploit available. EPSS score: 0.85.
A CVSS-only policy would prioritize the first one. An EPSS-informed policy would flip that priority, and rightly so. The second vulnerability is actively being targeted, has tooling available, and affects software that is nearly ubiquitous.
This does not mean you ignore the first vulnerability forever. It means you triage intelligently. Patch the high-probability exploit first, then address the theoretical risk on a reasonable timeline.
Using EPSS in Practice
Tiered Patching Policies
One common approach is to combine CVSS and EPSS into a risk matrix:
- CVSS High + EPSS High: Patch immediately (within 48 hours)
- CVSS High + EPSS Low: Patch within the standard SLA (e.g., 30 days)
- CVSS Low + EPSS High: Investigate and potentially escalate -- this is the category most organizations miss
- CVSS Low + EPSS Low: Schedule for the next maintenance window
Integrating with Your Tooling
Most modern vulnerability management platforms are starting to incorporate EPSS data. If yours does not, you can pull the daily CSV from the FIRST EPSS API and join it against your CVE inventory by CVE ID. A simple Python script or database join is all you need.
Communicating Risk to Leadership
EPSS scores translate well to business conversations. Telling an executive "this vulnerability has a 90% chance of being exploited in the next month" is far more impactful than "this vulnerability has a CVSS score of 9.1." Probability is intuitive in a way that abstract severity ratings are not.
Limitations to Be Aware Of
EPSS is not a silver bullet. A few things to keep in mind:
It only covers known CVEs. Zero-days and vulnerabilities without CVE assignments are not scored.
It predicts exploitation, not impact. A vulnerability with a high EPSS score in a system you do not run is irrelevant to you. You still need asset context.
The model has a recency bias. Older vulnerabilities with stable, well-known exploits may not always score as high as newly trending ones.
It does not account for your specific environment. EPSS tells you about global exploitation probability, not whether your particular network configuration makes you more or less vulnerable.
These are not reasons to avoid EPSS. They are reasons to use it as one input among several, rather than a single decision point.
The Broader Trend: Risk-Based Vulnerability Management
EPSS is part of a larger shift in the industry toward risk-based vulnerability management (RBVM). The old model of "scan, find all criticals, patch everything" does not scale. Modern RBVM combines severity, exploitability, asset criticality, and business context to produce actionable priorities.
CISA's Known Exploited Vulnerabilities (KEV) catalog is another data point in this direction. While KEV is a binary list (exploited or not), EPSS provides a probability gradient that is useful for vulnerabilities not yet on the KEV list.
The organizations that get this right treat vulnerability data as a risk signal, not a compliance checkbox. They correlate EPSS scores with their asset inventory, overlay business criticality, and produce a prioritized remediation queue that their engineering teams can actually execute against.
How Safeguard.sh Helps
Safeguard.sh integrates EPSS scoring directly into its vulnerability management workflow. When you import SBOMs or run dependency scans, each identified vulnerability is enriched with the current EPSS score alongside CVSS data, KEV status, and reachability analysis.
This means your security team sees a unified risk view without having to manually download CSV files or build custom integrations. Safeguard.sh also lets you define policy gates based on EPSS thresholds, so you can automatically flag builds that introduce dependencies with high exploit probability. Instead of drowning in thousands of CVEs, you focus on the ones that actually matter -- and you can prove to auditors exactly why you prioritized what you did.