EPSS Score Explained: Stop Ranking Vulnerabilities by CVSS Alone
September 17, 2026
Amir Tavafi
10 min read
An EPSS score is a 0-to-1 probability a vulnerability gets exploited in the next 30 days, and most teams skip it when deciding what to patch first. They patch by CVSS severity instead, which measures how bad a bug would be, not how likely anyone is to use it. Abloomify ranks security posture by CVSS severity and EPSS probability, in the same platform as DORA metrics and PR flow, because patching the wrong bug first is its own velocity problem.
Key Takeaways
Q: What is an EPSS score?
A: A number from 0 to 1 (often shown as a percentage) estimating the probability a vulnerability will be exploited in the wild within 30 days. It's produced daily by FIRST, the same nonprofit standards body behind CVSS, but it answers a different question: likelihood, not severity.
Q: Why isn't CVSS severity enough on its own?
A: CVSS tells you how bad a vulnerability would be if someone used it. It says nothing about whether anyone will. Most published CVEs, including plenty of "Critical" 9.8s, have an EPSS probability near zero because no working exploit exists and nobody is trying to build one.
Q: How often does EPSS update?
A: Daily. FIRST's model recalculates every CVE's score each day using fresh signals: exploit code appearing on GitHub, chatter on attacker forums, scanner activity. A vulnerability that scored 0.01 last week can jump to 0.6 the day someone publishes a working exploit.
Q: How does Abloomify use EPSS scores?
A: Abloomify pulls security posture from Dependabot and code scanning, ranks it by CVSS severity and EPSS exploit probability, and puts it in the same platform as DORA metrics, PR flow, and CI/CD health, so a security backlog shows up next to the delivery numbers it threatens instead of in a fourth vendor login.
Q: What EPSS number should trigger action?
A: Many security teams treat anything above roughly 0.1, a 10% predicted exploitation probability, as worth moving up the queue, especially paired with a CVSS score of 7 or higher. There's no single official threshold, so read EPSS as a ranking signal, not a hard gate.
What is an EPSS score?
An EPSS score is a probability, produced daily by the Exploit Prediction Scoring System and maintained by FIRST (the Forum of Incident Response and Security Teams), estimating how likely a specific published CVE is to be exploited in the wild in the next 30 days. The score runs from 0 to 1: a vulnerability scored 0.02 has roughly a 2% predicted chance of exploitation, while one scored 0.85 is treated as very likely to be actively targeted. EPSS answers a question CVSS was never designed to answer. CVSS rates how severe a vulnerability would be if exploited, the access gained, the technical difficulty, and says nothing about whether an attacker is actually trying. EPSS fills that gap with a machine learning model trained on real exploitation data: exploit code in public repos, scanner traffic, chatter on forums attackers use. The result is a daily-refreshed likelihood number that sits alongside CVSS severity instead of replacing it.
How is an EPSS score calculated?
An EPSS score gets recalculated every single day for every CVE FIRST tracks, which is the detail most CVSS-only shops miss: severity is static once assigned, but exploitation likelihood moves in real time. The underlying model pulls in dozens of signals, weighted and updated continuously, including whether public exploit code exists for the CVE (a repo on GitHub, a Metasploit module), whether the vulnerability is being scanned for or actively exploited according to threat intelligence feeds, how old the CVE is, what vendor or product it affects, and how much attacker discussion it's generating. None of that comes from a static CVSS vector string filled out once at disclosure. That's why a vulnerability can sit at EPSS 0.01 for months and then jump to 0.7 within days of a proof-of-concept exploit going public, the score reacting to what's actually happening in the wild rather than to a fixed severity rating assigned on day one.
EPSS vs CVSS: severity and likelihood are different questions
EPSS and CVSS measure different things, and ranking a patch queue by either one alone routinely produces the wrong order. CVSS answers "how bad would this be," scored 0 to 10 based on technical factors like attack complexity and privileges required, fixed at disclosure and rarely revisited. EPSS answers "how likely is this," scored 0 to 1, recalculated daily from real exploitation signals. Put them side by side and the mismatches show up fast: a CVSS 9.8 remote code execution bug with an EPSS of 0.02 is a fire that, based on everything known right now, probably never starts, no public exploit, no scanner chatter, no attacker interest. A CVSS 6.5 "Medium" bug with an EPSS of 0.85 is a fire that's already spreading. Security teams that patch strictly by CVSS severity end up burning sprint time on the first bug and leaving the second one open, which is backwards from what an actual attacker is doing that week.
How to use EPSS scores to prioritize vulnerabilities
Using EPSS to prioritize patching takes five steps, and most teams can run this against an existing backlog in under an hour once the CVSS and EPSS numbers are sitting next to each other instead of in separate tools:
- Pull both scores for every open CVE. CVSS from your scanner, EPSS from FIRST's public API or a platform that already imports it. Neither number alone is the ranking; the pair is.
- Flag the high-severity, high-probability overlap first. CVSS 7+ paired with EPSS above roughly 0.1 is the queue that actually matters this week.
- Deprioritize high-CVSS, near-zero-EPSS findings, don't delete them. A Critical severity bug with no exploit activity still gets fixed, just not ahead of something attackers are already probing.
- Add exposure context before locking the order. Internet-facing and production-adjacent code moves up regardless of score; an internal dev sandbox can wait even with a moderately high EPSS.
- Re-run the ranking weekly, not once. EPSS updates daily specifically because exploitation activity changes. A backlog ranked in January and never revisited is ranked on stale risk by March.
Why vulnerability data shouldn't live in a separate tool
Vulnerability prioritization sitting in a fourth AppSec login, disconnected from the delivery metrics engineering leadership actually reports upward, is the same fragmentation problem that shows up everywhere else in a modern engineering stack. A VP of Engineering already tracks DORA metrics, PR cycle time, and CI/CD health in one place. Bolting a separate vulnerability dashboard on top means security posture never gets read next to the deploy frequency and change failure rate it directly affects, and a standalone tool for it is one more subscription in the pile that already runs $50K-$100K a year in SaaS waste at a typical midmarket tech company. Abloomify's engineering intelligence layer pulls security posture from Dependabot and code scanning, ranks it by CVSS severity and EPSS exploit probability, and puts it in the same view as DORA metrics, PR flow, and CI/CD pipeline health with flaky-test detection. When a high-EPSS vulnerability sits in a repo with a slipping change failure rate, that's a signal worth seeing in one place, not two.
This is the same argument Abloomify makes about the wider AI developer tools stack: measuring any one signal in isolation, whether it's an AI coding tool's acceptance rate or a scanner's raw CVE count, tells you less than reading it against the delivery data it's supposed to protect or improve. Security posture is not a side quest from engineering velocity. A team burning sprint capacity patching low-EPSS Criticals while a high-EPSS Medium sits open is losing velocity to a prioritization mistake, not a security mistake.
Choosing a platform that combines EPSS, CVSS, and delivery metrics
Evaluating a security posture tool starts with one question: does it show you the vulnerability ranked by both severity and exploit likelihood, or just one. A scanner that reports CVSS alone is giving you half the picture and calling it prioritization. From there, check whether that ranking lives anywhere near the metrics your engineering org already reports: DORA bands, PR cycle time, CI/CD stability. If security posture requires a separate login to check, it's structurally set up to be checked less often than the dashboard your team already has open, which is exactly backwards for a signal that changes daily. Abloomify's engineering intelligence layer connects to GitHub, GitLab, and Bitbucket alongside Jira and Linear, PII-free and SOC 2 Type II certified, so a VP of Engineering gets security posture, delivery health, and AI tool ROI in one Engineering Velocity Score instead of four separate vendor consoles that have never spoken to each other. Big AppSec platforms bring dashboards nobody opens. A number that already sits next to the metrics you check anyway gets used.
FAQ
What is an EPSS score?
An EPSS score is a number between 0 and 1 that estimates the probability a specific vulnerability will be exploited in the wild in the next 30 days. It's produced by the Exploit Prediction Scoring System, maintained by FIRST, and updated daily as new exploit data comes in.
Is EPSS the same as CVSS?
No. CVSS scores severity: how bad a vulnerability would be if exploited. EPSS scores likelihood: how probable exploitation actually is. A CVSS 9.8 with an EPSS of 0.02 is a fire that probably never starts. A CVSS 6.5 with an EPSS of 0.85 is one that already has.
What counts as a high EPSS score?
There's no universal cutoff, but many security teams treat anything above roughly 0.1 (a 10% predicted exploitation probability in 30 days) as worth prioritizing, since most published CVEs score far below that. Pair the EPSS threshold with CVSS severity rather than using either number alone.
How often does an EPSS score change?
Daily. FIRST recalculates every published CVE's EPSS score each day as new signals come in, like exploit code showing up on GitHub or a CVE getting mentioned in attacker forums, so a low score today can jump fast once real-world exploitation activity starts.
Can Abloomify show EPSS scores next to engineering metrics?
Yes. Abloomify's engineering intelligence layer pulls security posture from Dependabot and code scanning, ranked by CVSS severity and EPSS exploit probability, in the same platform as DORA metrics and PR flow, so a slipping security posture shows up next to the delivery numbers it puts at risk instead of in a separate AppSec login.
Does a high EPSS score mean you should patch immediately?
It means you should look immediately, not necessarily patch immediately. Check what the vulnerable component actually touches (internet-facing vs internal, production vs a dev sandbox) before deciding sequence. EPSS tells you what's likely to get exploited; your own exposure context tells you what happens if it does.
Amir Tavafi
Co-Founder & CEO
Product leader and innovator with over 15 years of experience in the tech sector, grounded in AI and robotics. Previously led product development in fraud detection and AI solutions at Nasdaq Verafin.