Every vulnerability management team knows the feeling. You run a scan, get back 12,000 findings, and 40% of them are rated Critical or High. Your development team has capacity to fix maybe 200 this sprint. Which 200?
For over a decade, CVSS has been the default answer. Sort by score, patch from the top. It is a reasonable starting point, but it has a fundamental problem: CVSS measures the theoretical severity of a vulnerability in isolation. It does not measure whether anyone is actually exploiting it, whether the vulnerable component is reachable in your application, or whether mitigating controls already reduce the risk.
In 2025, two complementary technologies have matured enough to change this equation: the Exploit Prediction Scoring System (EPSS) and Vulnerability Exploitability eXchange (VEX).
The CVSS Problem, Quantified
CVSS was designed to provide a standardized severity rating for vulnerabilities. It does that job well. But severity and risk are not the same thing, and the gap between them creates real operational problems.
Consider the numbers. The NVD published over 28,000 CVEs in 2024. Roughly 10% received a CVSS score of 9.0 or higher (Critical). Another 30% landed between 7.0 and 8.9 (High). That means approximately 11,000 vulnerabilities per year are rated Critical or High.
No organization can remediate 11,000 critical vulnerabilities per year across their software portfolio. The result is alert fatigue, arbitrary prioritization, and wasted engineering effort on vulnerabilities that pose little real-world risk.
Research from multiple sources has consistently shown that fewer than 5% of all published CVEs are ever exploited in the wild. The vast majority of Critical-rated vulnerabilities will never be weaponized. But CVSS alone cannot tell you which ones those are.
EPSS: Predicting Exploitation Probability
The Exploit Prediction Scoring System, developed by FIRST (the same organization behind CVSS), takes a fundamentally different approach. Instead of measuring what a vulnerability could do in theory, EPSS estimates the probability that a vulnerability will be exploited in the wild within the next 30 days.
EPSS uses a machine learning model trained on observed exploitation data, including:
- Historical exploitation patterns from IDS/IPS signatures, honeypots, and threat intelligence feeds.
- Vulnerability characteristics like CWE type, vendor, and product category.
- Social media and dark web mentions.
- Public exploit availability (Metasploit modules, proof-of-concept code).
- Time since disclosure.
The output is a probability score between 0 and 1. A score of 0.95 means the model predicts a 95% chance the vulnerability will be exploited in the next 30 days. A score of 0.001 means a 0.1% chance.
Why EPSS Changes Prioritization
When you combine CVSS severity with EPSS probability, the prioritization picture changes dramatically. Consider two vulnerabilities:
Vulnerability A: CVSS 9.8 (Critical), EPSS 0.002 (0.2% exploitation probability). This is a theoretically severe vulnerability that almost nobody is actually exploiting. It is likely in a niche product, requires unusual conditions, or has no public exploit code.
Vulnerability B: CVSS 7.5 (High), EPSS 0.85 (85% exploitation probability). This is a moderately severe vulnerability that attackers are actively targeting. There are probably Metasploit modules, active scanning campaigns, and real-world compromises.
Under CVSS-only triage, Vulnerability A gets patched first. Under EPSS-informed triage, Vulnerability B gets immediate attention. The second approach reflects actual risk far more accurately.
EPSS Performance Data
FIRST publishes regular performance metrics for EPSS. The model's coverage and precision have improved significantly. At an EPSS threshold of 0.1 (10% exploitation probability), the model captures the majority of actually-exploited vulnerabilities while filtering out a large percentage of the total CVE volume.
In practical terms, setting an EPSS threshold of 0.1 reduces the "urgent" vulnerability population by 80-90% compared to CVSS-only triage, while catching most of the vulnerabilities that actually get exploited. That is the kind of signal-to-noise improvement that makes vulnerability management operationally feasible.
VEX: Contextual Exploitability
While EPSS addresses the question "Is this vulnerability being exploited in the wild?", VEX addresses a different but equally important question: "Is this vulnerability exploitable in my specific product or deployment?"
A Vulnerability Exploitability eXchange (VEX) document is a machine-readable assertion from a software supplier about whether a known vulnerability in a component actually affects their product. VEX defines four status values:
- Not Affected: The vulnerability exists in a component we use, but it is not exploitable in our product (e.g., the vulnerable function is never called, the vulnerable code path is disabled, or compensating controls prevent exploitation).
- Affected: The vulnerability is exploitable in our product, and users should take action.
- Fixed: The vulnerability was previously exploitable but has been remediated in this version.
- Under Investigation: We are still assessing whether the vulnerability affects our product.
Why VEX Matters for SBOM-Driven Security
VEX becomes essential in a world of SBOMs. When you generate an SBOM for a modern application, you might find hundreds of transitive dependencies. Scanning those dependencies against vulnerability databases produces a long list of CVEs. But many of those CVEs exist in functions, modules, or code paths that your application never invokes.
Without VEX, every CVE in every dependency is treated as a potential risk. With VEX, suppliers can communicate that specific CVEs are "Not Affected" in their product, allowing consumers to focus on the vulnerabilities that actually matter.
The challenge is that VEX requires supplier participation. Someone has to analyze each vulnerability and determine whether it affects their specific product. This is labor-intensive, which is why VEX adoption has been gradual.
VEX Format Landscape
Two primary VEX formats have emerged:
CSAF VEX: Based on the Common Security Advisory Framework (CSAF) standard, CSAF VEX is the more comprehensive format. It supports detailed product trees, remediation guidance, and complex product-vulnerability relationships. CSAF is favored by traditional enterprise software vendors.
CycloneDX VEX: Embedded directly within CycloneDX SBOMs or as standalone documents, CycloneDX VEX is designed for tight integration with the SBOM lifecycle. It is simpler to generate and consume, making it popular in DevSecOps environments.
Both formats are valid. The important thing is that VEX data exists and flows through the software supply chain alongside SBOMs.
Combining EPSS, VEX, and CVSS
The most effective vulnerability prioritization in 2025 uses all three signals together:
- CVSS establishes the baseline severity. A CVSS 2.0 vulnerability is low priority regardless of other signals.
- EPSS filters for exploitation likelihood. Among your Critical/High CVSS findings, which ones are actually being exploited or are likely to be exploited soon?
- VEX adds product-specific context. Among the vulnerabilities that are severe and likely to be exploited, which ones are actually reachable and exploitable in your specific product?
This three-layer approach reduces the actionable vulnerability population by 90-95% compared to CVSS-only triage. The remaining vulnerabilities represent genuine, exploitable risk that warrants engineering effort.
Reachability Analysis as Automated VEX
One emerging trend is using static analysis and call-graph analysis to automate VEX determinations. If a tool can prove that a vulnerable function in a dependency is never called by your application, it can automatically generate a "Not Affected" VEX status.
This approach, often called reachability analysis, bridges the gap between SBOM-level vulnerability scanning and code-level exploitability assessment. It is not perfect -- some vulnerabilities are exploitable through data flow rather than direct function calls -- but it eliminates a significant portion of false positives.
Organizational Adoption Challenges
Adopting EPSS and VEX is not purely a technology problem. It requires changes to processes and culture:
Security teams need to accept that not every Critical CVSS vulnerability requires immediate remediation. This can be difficult for teams that have built their processes and SLAs around CVSS scores.
Development teams need to trust that the prioritization is sound. If security reduces the vulnerability backlog by 80%, developers need confidence that the remaining 20% genuinely matters.
Compliance and audit functions need to understand that EPSS and VEX represent more sophisticated risk management, not less. Regulators and auditors who are accustomed to CVSS-based SLAs may need education.
Tooling needs to support all three signals. Many vulnerability scanners still present CVSS scores as the primary (or only) prioritization metric.
How Safeguard.sh Helps
Safeguard integrates EPSS scores alongside CVSS data for every vulnerability it identifies, giving teams an immediate view of exploitation probability without manual lookups. The platform's policy engine supports EPSS-based thresholds, so you can define policies like "Critical CVSS with EPSS greater than 0.1 must be remediated within 72 hours" while allowing lower-probability findings to follow standard timelines.
For VEX, Safeguard consumes and generates VEX documents as part of the SBOM lifecycle. When a supplier publishes a VEX assertion that a vulnerability is "Not Affected," Safeguard automatically adjusts the risk status, reducing noise for downstream consumers. The platform also performs reachability analysis to identify cases where vulnerable functions are never invoked, enabling automated "Not Affected" determinations.
The combination of SBOM generation, vulnerability scanning, EPSS enrichment, and VEX support in a single platform means teams can move from CVSS-only triage to genuine risk-based prioritization without stitching together multiple point solutions.