Security teams drowning in vulnerability alerts have a math problem, not a tooling problem. The National Vulnerability Database logged more than 40,000 new CVEs in 2024 alone, yet research from the Cyentia Institute consistently finds that only about 5% of published CVEs are ever exploited in the wild. If your prioritization strategy is "patch everything CVSS rates 7.0 or higher," you're chasing roughly half of all CVEs to catch a sliver of actual risk. This is exactly the gap the Exploit Prediction Scoring System (EPSS) was built to close, and it's exactly where many teams running Prisma Cloud still get stuck, because CVSS-first workflows dominate the default experience. Below, we break down what an EPSS score actually measures, why CVSS alone keeps failing security teams, how this plays out for Prisma Cloud users specifically, and how Safeguard operationalizes EPSS to cut remediation queues down to what actually matters.
What Is an EPSS Score, Exactly?
An EPSS score is a probability, between 0 and 1, that a given CVE will be exploited in the wild in the next 30 days. It's maintained by FIRST.org, the same nonprofit that stewards CVSS, and it's built on a machine learning model trained on real-world exploitation signals: honeypot data, scanning activity from GreyNoise, exploit code availability on GitHub and Metasploit, references in security advisories, and social chatter. EPSS v3, released in March 2023, improved on earlier versions by widening its feature set and jumped from roughly 65% to over 80% precision at capturing exploited vulnerabilities within a fixed alert budget, according to FIRST's own published performance benchmarks. A CVE with an EPSS score of 0.97 means the model estimates a 97% chance it gets exploited in the next month. A CVE sitting at 0.02 is very unlikely to see active exploitation in that window, no matter how severe its theoretical impact looks on paper. The score updates daily as new evidence comes in, which is the part most legacy tooling still doesn't handle well.
Why Does CVSS Alone Fail to Prioritize Vulnerabilities?
CVSS alone fails because it measures theoretical severity, not observed likelihood, and those two things correlate far less than most patch policies assume. CVSS asks "how bad could this be if exploited," scoring things like attack vector, complexity, and impact on confidentiality, integrity, and availability. It says nothing about whether anyone is actually trying to exploit it. Cyentia and Kenna Security's joint "Prioritization to Prediction" research series found that of all CVEs rated 9.0+ on CVSS, fewer than 3% had confirmed exploitation activity within a year of disclosure. Meanwhile, plenty of CVEs sitting at CVSS 6.0-7.0, "medium" by most SLA policies, ended up as the delivery mechanism for real breaches because they were trivially exploitable and widely targeted. Log4Shell (CVE-2021-44228) is the textbook case: CVSS 10.0, but the number that mattered operationally was how fast its EPSS score climbed past 0.97 within days of disclosure in December 2021, correctly flagging it as an active, mass-exploited threat before most CVSS-only dashboards had even finished triaging it.
How Does Prisma Cloud Handle EPSS Scoring Today?
Prisma Cloud surfaces EPSS as a data point inside its vulnerability details view, but it's presented as supplementary metadata rather than the primary axis teams are pushed to act on. The default risk-based ranking in Palo Alto Networks' vulnerability management workflows still leans heavily on CVSS severity tiers combined with asset context (internet exposure, running processes) layered through their "Net Effective Risk Score." That's a reasonable model, but customers report that EPSS isn't a first-class filter you can build SLA policies around out of the box, it takes custom query building or add-on configuration to make EPSS score threshold the actual triage lever. For teams running lean AppSec functions without a dedicated Prisma Cloud administrator tuning custom risk factors, the practical result is the same CVSS-heavy queue with an EPSS column added for reference, not a queue that's actually reordered by exploitation probability. That's a meaningful difference when the SOC has bandwidth to patch 40 things this sprint out of a backlog of 4,000.
How Much Backlog Reduction Does an EPSS-First Approach Actually Deliver?
An EPSS-first approach typically cuts remediation backlogs by 80-94% compared to CVSS-only triage, based on FIRST.org's published modeling. Their research shows that patching only the CVEs with an EPSS score above 0.36 (a common threshold used in production SLA policies) captures roughly 82% of all CVEs that go on to be exploited, while requiring remediation of less than 5% of the total CVE population in a typical enterprise environment. Compare that to a CVSS-only policy requiring remediation of everything scored 7.0+: that captures a similar share of exploited CVEs but forces action on nearly 50% of your total CVE inventory to get there. For a mid-size engineering org tracking 3,000 open findings across its software supply chain, that's the difference between a weekly patch cycle covering 150 items versus 1,500. Time-to-remediate SLAs get easier to hit, on-call engineers stop context-switching on noise, and the vulnerabilities that do get fixed are the ones with a measurable chance of being weaponized against you in the next month.
Do EPSS Scores Change Fast Enough to Matter in Production?
Yes, EPSS scores are recalculated daily, and that update cadence is often the difference between catching a threat window and missing it entirely. A CVE can sit at EPSS 0.03 on disclosure day and cross 0.80 within 72 hours once a public proof-of-concept lands, exactly what happened with CVE-2023-4966 ("Citrix Bleed"), which climbed sharply through late October 2023 as exploitation activity from ransomware groups was confirmed by CISA. A static, point-in-time CVSS score assigned at disclosure never reflects that shift. Any vulnerability management program that only pulls EPSS scores during a monthly or quarterly review is functionally running on stale data for weeks at a time, during exactly the window when newly disclosed CVEs are most likely to see their exploitation probability spike. Continuous ingestion of the daily EPSS feed, not a cached snapshot, is a requirement for the score to do the job it's designed for.
How Safeguard Helps
Safeguard treats EPSS score as a first-class, continuously updated signal across the entire software supply chain, not a secondary column bolted onto a CVSS-sorted list. Every CVE surfaced in your SBOMs, container images, and dependency graphs is enriched with its live EPSS score, pulled and refreshed on FIRST.org's daily cadence, and correlated directly against your actual exposure: is the affected package reachable in your runtime, is it internet-facing, is it in a component your build pipeline pulls in daily. That context turns "EPSS 0.91" into an actionable, prioritized ticket instead of an abstract statistic.
Safeguard's risk scoring engine lets teams set remediation policy directly on EPSS thresholds out of the box, no custom query building required, so a rule like "auto-escalate anything crossing EPSS 0.5 within 24 hours, regardless of CVSS" is a native workflow, not a workaround. When a CVE's exploitation probability spikes, the way Log4Shell's and Citrix Bleed's did within days of disclosure, Safeguard flags the shift in near real time and routes it into your existing ticketing and CI/CD gates automatically.
For teams evaluating a move away from Prisma Cloud, or running Safeguard alongside it during a transition, this means your backlog gets reordered by what's actually being exploited, not just what looks scary on a CVSS chart. Combined with Safeguard's software supply chain provenance data and SBOM-level reachability analysis, EPSS becomes one input in a fuller risk picture, exploitability, exposure, and business context together, so remediation effort goes exactly where attackers are already looking.
If your team is still triaging by CVSS severity alone, or treating EPSS as a nice-to-have data point rather than a policy driver, that gap is measurable in wasted engineering hours every single sprint. Safeguard is built to close it.