In 2024, more than 40,000 new vulnerabilities were added to the CVE database. Yet many security teams still rely on legacy scoring models and incomplete context to decide which vulnerabilities matter and what to fix first.
Whether it’s a CVSS 10.0 flaw buried behind layers of compensating controls or a KEV-listed CVE that’s already mitigated in your environment, the challenge is the same: without context and validation, severity scores become noise.
To cut through that noise, the industry now leans on a growing mix of prioritization metrics, CVSS, EPSS, KEV, SSVC, and most recently, LEV. Each provides a different lens on risk. But they all share a common blind spot: they can’t tell you what’s actually exploitable in your unique IT environment.
This is where the Picus Exposure Score (PXS) adds the missing layer, evidence.
This blog will break down what each model does, where it falls short, and how PXS complements the stack by turning scores into actionable proof.
The Common Vulnerability Scoring System (CVSS) has been the backbone of vulnerability prioritization for nearly two decades. It provides a numerical score (0.0 – 10.0) representing the technical severity of a vulnerability based on impact, exploitability, and scope.
Why it matters: CVSS provides a common, standardized language for describing vulnerability risk. It is widely supported by vulnerability scanners and databases, helping organizations align their vulnerability assessments and ensure consistency across security teams and tools.
Where it falls short: CVSS reflects the maximum theoretical impact of a vulnerability in isolation.
|
CVSS is global, static, and asset-agnostic, meaning it applies the same score to a vulnerability on a business-critical system as it does on a sandboxed test VM. |
It doesn’t indicate whether the vulnerability is actually exploitable in your environment, whether it’s already mitigated by compensating controls like firewalls or EDR, or whether exploitation requires privileges that aren’t granted (e.g., admin access on a non-admin service).
As a result, high CVSS scores often create urgency for low-risk vulnerabilities. This makes it harder for security teams to deprioritize vulnerabilities that do not matter and focus on real threats..
To move beyond static severity scores, the Exploit Prediction Scoring System (EPSS) predicts the likelihood that a vulnerability will be exploited in the next 30 days. Developed by FIRST, EPSS uses real-world exploit data, threat intel, and machine learning to output a score between 0 and 1.
Why EPSS matters: EPSS helps teams prioritize based on exploit likelihood, not just technical severity. It highlights which CVEs may actually be targeted soon in the wild, focusing attention on probable threats.
Where it falls short: EPSS analyzes internet-scale exploit signals to predict the probability of a vulnerability being exploited. While valuable for broad prioritization, it doesn't consider your specific enterprise context.
EPSS doesn't account for compensating controls like firewalls, IPS/IDS, and EDRs, SIEM, nor does it determine if an attacker can even reach the vulnerable asset within your network.
|
A high EPSS score might indicate significant risk in the wild, but if your systems inherently block the exploit or the asset is isolated, the actual risk to your organization is much lower. |
Therefore, always integrate EPSS with your internal security posture and asset exposure for effective, contextualized risk management.
CISA’s Known Exploited Vulnerabilities (KEV) catalog offers something the other models don’t, confirmation. If a CVE is on the KEV list, it means it’s been exploited in the wild.
Why it matters: KEV helps reduce noise by confirming which vulnerabilities have been exploited in the wild. It offers binary clarity, a CVE has either been weaponized or it hasn’t. While not environment-specific, this signal is credible and useful for prioritizing triage, aligning stakeholders, and driving faster response.
Where it falls short: KEV is reactive, binary, and global.
|
CISA’s KEV confirms that a vulnerability has been exploited somewhere, but offers no insight into whether it poses real risk in your environment. |
A KEV-listed CVE may not be accessible, may require conditions that don’t exist in your setup, or may already be mitigated through layered defenses, vendor signatures, or targeted hardening. In many cases, no patching is required, yet KEV treats all environments the same, creating a false sense of urgency even when the risk is already neutralized.
Stakeholder-Specific Vulnerability Categorization (SSVC), created by SEI and CISA, takes a different approach. Rather than assigning a score, SSVC guides organizations through a decision tree that includes exploit status, technical impact, mission relevance, and more.
Why it matters: SSVC introduces a structured decision-making model that prioritizes vulnerabilities based on context, not just severity scores. Instead of reacting to every high CVSS rating, it guides stakeholders to take action aligned with asset relevance, mission impact, and exploitation status through outcomes like Act, Attend, Track*, or Track.
Where it falls short: SSVC is manual, subjective, and not scalable across large vulnerability volumes.
|
It relies on human interpretation at each decision point and lacks integration with control telemetry. |
Most critically, it does not validate whether an exploit would actually succeed in your environment, leaving decisions based on logic rather than evidence.
Introduced by NIST in 2025, the Likely Exploited Vulnerabilities (LEV) metric estimates the probability that a vulnerability has already been exploited, based on historical EPSS scores.
Why it matters: LEV adds a retrospective dimension to vulnerability prioritization by estimating the likelihood that a CVE has already been exploited in the wild. It helps identify vulnerabilities that may not appear in KEV but exhibit historical patterns of exploitation based on EPSS trends.
Where it falls short: LEV is a global, statistical model built entirely on historical EPSS data.
|
It does not confirm real-world exploitation and assumes that attacker activity is statistically independent across time windows, an assumption that doesn’t hold in practice. |
LEV also lacks visibility into attacker intent, target selection logic, or enterprise-specific factors such as exploit paths and control coverage. As a result, it may highlight CVEs that are statistically interesting but irrelevant in your environment, or miss those that are exploitable due to local misconfigurations or unmonitored segments.
LEV is useful for surfacing patterns, but without validation, it remains just that: probability, not proof.
Most scoring models assess how severe a vulnerability could be, how likely it is to be exploited, or how important the affected asset is.
|
But none of them answer the most critical question: Can this vulnerability actually be exploited in my environment? |
Picus Exposure Score (PXS) is the only metric in this group that validates risk through real-world simulation, bridging the gap between theoretical scoring and operational exposure.
How it works: For each CVE, Picus simulates adversary behavior using techniques observed in active malware, APT campaigns, and threat intelligence. It then measures how your controls, EDR, IPS, firewalls, and more, respond: do they block, detect, or miss the attack?
The result is a dynamic, control-aware score that reflects actual exploitability based on your infrastructure. Unlike legacy models, PXS doesn’t rely on assumptions. It tests, observes, and scores what matters, proof, not predictions.
Let’s say Log4Shell (CVE-2021-44228) is detected on three different systems:
Traditional models treat all three as equal.
|
CVSS assigns a 10.0 to each. EPSS predicts a high likelihood of exploitation. All three assets are tagged as critical due to the sensitive data they handle. Based on this, most vulnerability management programs would push to patch everything immediately. |
But that’s not how attackers, or your environment, work.
When adversarial simulations are run using Picus Exposure Validation, each system responds differently based on its actual controls and architecture:
This shift from external scoring to internal validation reveals what truly matters. Instead of treating every CVE the same, security teams can focus remediation where it counts, extend SLAs where defenses are working, and reduce unnecessary disruption.
By moving from assumed risk to proven exposure, PXS enables data-driven prioritization that aligns with both your control posture and attacker behavior.
A mid-sized financial organization was drowning in vulnerability data. Their scanners identified 15,000 open issues across 10,000 assets, 9,400 of them labeled “high” or “critical” by CVSS alone.
After incorporating EPSS scores and asset value using risk-based vulnerability management tools, the list dropped to 6,700. Helpful, but still overwhelming.
Then they added exposure validation.
By simulating real attacks using Picus Exposure Validation and measuring control responses, they found only 1,300 vulnerabilities were actually exploitable in their environment. After hardening controls using vendor-specific mitigations and tuning detection policies, that number fell even further, to just 300.
|
That's a 97% reduction from the original patch list. |
Not through assumptions, but through evidence. Exposure Validation gave them clarity, cut the noise, and helped the team reclaim their time, while keeping risk front and center.
Rather than replacing these metrics, PXS enhances them. It bridges the gap between theory and proof, between static scores and operational outcomes.
|
Model |
Primary Focus |
Limitation |
What PXS Adds |
|
CVSS |
Technical severity |
Asset-agnostic; ignores control posture |
Validates if "critical" CVEs are actually exploitable in your environment |
|
EPSS |
Short-term exploitation likelihood |
Global signal only; lacks environment awareness |
Confirms whether high-likelihood CVEs bypass or are blocked by your defenses |
|
KEV |
Confirmed exploitation in the wild |
Binary, reactive, and not environment-specific |
Determines if KEV-listed CVEs still pose real risk in your infrastructure |
|
SSVC |
Contextual, mission-aligned decisions |
Manual and subjective; no technical validation |
Supports SSVC outcomes with control-aware evidence |
|
LEV |
Probability of past exploitation |
Based on historical EPSS data; probabilistic |
Distinguishes theoretical likelihood from practical exploitability in your setup |
|
PXS |
Real-world exploitability in your environment |
Converts assumptions into evidence; enables data-driven prioritization aligned with actual |
Each scoring model in the modern vulnerability stack plays an important role:
CVSS gives technical severity.
EPSS adds predictive likelihood.
KEV confirms known threats.
SSVC provides mission-aligned guidance.
LEV brings retrospective probability.
But these models are still proxies for risk, not proof.
Picus Exposure Score (PXS) is different. It doesn’t estimate; it validates.
|
Where others say "this might matter," PXS says, "this does, or doesn't, in your environment, right now." |
That validation is what turns prioritization into a defensible, evidence-based process. It’s what also makes deprioritization possible, cutting through noise to focus efforts where they matter most, without the risk of overlooking real threats.
Used together, these models form a layered approach. But it’s PXS that turns the entire process from reactive guesswork into proactive, data-driven defense.
Because in cybersecurity, it’s not about how bad a CVE could be. It’s about whether it can breach you, and what you’ll do about it.