Five vulnerability scoring systems compete for developer attention: CVSS (severity), EPSS (exploitation probability), CISA KEV (active exploitation), SSVC (stakeholder-specific decisions), and LEV (likely exploited, NIST 2025). Each answers a different question. This guide compares all five so you can choose the right signals for your team's workflow. (Looking for quick, citable definitions instead of a deep comparison? See the Vulnerability Scoring Systems Glossary, which also covers VEX.)
The Scoring System Landscape
Before diving into each system, here's the high-level comparison:
Vulnerability Scoring Systems at a Glance
System Maintained By Measures Scale Updated Best For
──────────────────────────────────────────────────────────────────────────────────────────────
CVSS FIRST.org Theoretical severity 0–10 Per-CVE Baseline assessment
EPSS FIRST.org Exploitation probability 0–100% Daily Prioritization
KEV CISA Active exploitation Yes/No As needed Compliance + urgent patches
SSVC CISA Stakeholder decisions Track/Attend/ Per-assessment Enterprise risk management
Act
LEV NIST Likely exploitation Score (TBD) Periodic Bridging CVSS and EPSS
──────────────────────────────────────────────────────────────────────────────────────────────
Each system was designed to address a specific gap in vulnerability management. Understanding what question each one answers — and what it deliberately ignores — is the key to combining them effectively.
CVSS: The Baseline (and Its Limitations)
What it is: The Common Vulnerability Scoring System, maintained by FIRST.org, is the industry standard for describing vulnerability characteristics. Every CVE in the National Vulnerability Database has a CVSS score.
What it measures: Theoretical worst-case severity. CVSS evaluates attack vector (network vs. local), complexity (low vs. high), privileges required, user interaction needed, and impact on confidentiality, integrity, and availability. The result is a score from 0 to 10 and a severity label: Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).
What it does well:
- Universal — every CVE has one
- Standardized — consistent methodology across vendors
- Detailed — base, temporal, and environmental metric groups allow contextual adjustment
- Well-understood — most security tools and compliance frameworks reference CVSS
The limitation that created the need for everything else:
CVSS cannot tell you whether anyone will actually exploit a vulnerability. It measures how bad it could be, not how likely it is to happen.
The numbers make this concrete: roughly 54% of CVEs score 7.0 or higher ("High" or "Critical"), but at most about 6% of all CVEs are ever exploited in the wild — and stricter datasets put it nearer 1–2%. If you treat every CVSS 7.0+ finding as urgent, you're working with a false-positive rate above 90%.
When to use it: As a baseline input to other prioritization systems. CVSS tells you the blast radius — pair it with EPSS or KEV to understand whether the bomb is likely to go off. For a detailed comparison, see our CVSS vs EPSS deep dive.
EPSS: The Probability Engine
What it is: The Exploit Prediction Scoring System, also maintained by FIRST.org, is a machine learning model that estimates the probability a CVE will be exploited in the wild within the next 30 days.
What it measures: Exploitation likelihood, expressed as a percentage from 0% to 100%. The model incorporates hundreds of features: CVE age, whether exploit code exists, social media mentions, similarity to previously exploited vulnerabilities, and real-world exploitation telemetry.
How it differs from CVSS: CVSS is static — once assigned, a base score rarely changes. EPSS is dynamic — scores update daily as new exploitation signals emerge. A CVE that was 0.2% yesterday can jump to 35% tomorrow if a proof-of-concept exploit hits GitHub.
Accuracy: EPSS identifies approximately 82% of actually exploited CVEs within the top 5% of its score distribution. That means if you focus your patching on the top 5% of EPSS scores, you'll catch the vast majority of vulnerabilities that attackers are targeting.
Key thresholds for practitioners:
- EPSS > 10%: Strong exploitation signals. Prioritize immediately.
- EPSS 1-10%: Moderate signals. Schedule for upcoming maintenance.
- EPSS < 1%: Low exploitation likelihood. Deprioritize but monitor.
When to use it: Daily prioritization and triage. EPSS is the best available answer to "which of my 200 open vulnerabilities should I fix first?" For a comprehensive guide, read our EPSS deep dive.
CISA KEV: The Hard Evidence
What it is: The Known Exploited Vulnerabilities catalog, maintained by the Cybersecurity and Infrastructure Security Agency, is a curated list of CVEs with confirmed, active exploitation in the wild.
What it measures: A binary signal — is this CVE being actively exploited? Yes or no. There is no score or probability. If a CVE is on KEV, CISA has evidence that attackers are using it against real systems right now.
Size and growth: The catalog contains approximately 1,300 entries and grows as CISA confirms new exploitation activity. Entries are never removed — once exploited, always exploited.
Compliance significance: CISA's Binding Operational Directive 22-01 (BOD 22-01) originally required all US federal agencies to remediate KEV entries within fixed timeframes. It has since been superseded by BOD 26-04, which sets remediation timelines from a four-factor risk matrix — KEV status, asset exposure, exploit automation potential, and technical impact — rather than KEV membership alone. Either way these directives bind only federal agencies, but many private organizations still adopt KEV as a mandatory-patch list because it represents the highest-confidence exploitation data available.
The limitation: KEV is conservative. CISA only adds vulnerabilities with strong evidence of exploitation, which means there's a lag between initial exploitation and KEV listing. Some actively exploited CVEs aren't on KEV yet, and some may never be added if exploitation evidence doesn't meet CISA's bar.
When to use it: Compliance (BOD 22-01, now superseded by BOD 26-04), immediate patching decisions, and as the highest-priority filter in any triage workflow. KEV + EPSS together cover both confirmed exploitation (KEV) and predicted exploitation (EPSS). For more detail, see our CISA KEV guide.
SSVC: Stakeholder-Specific Decisions
What it is: The Stakeholder-Specific Vulnerability Categorization framework, developed by CISA and Carnegie Mellon's SEI, is a decision tree for determining how to respond to a vulnerability based on your specific context.
What it measures: Not a score in the traditional sense. SSVC produces a recommended action:
- Track — monitor the vulnerability, no immediate action needed
- Track* — monitor more closely, may require action soon
- Attend — requires attention from internal staff, plan remediation
- Act — requires immediate attention, engage the highest-priority response
How it differs from CVSS/EPSS: SSVC is contextual. The same CVE can produce different SSVC outcomes for different organizations depending on:
- Exploitation status: Is there active exploitation? (Similar to KEV)
- Technical impact: Partial vs. total compromise
- Automatable: Can an attacker automate exploitation at scale?
- Mission prevalence: How critical is the affected system to your organization?
- Public well-being: Does the affected system impact public safety?
Best for: Enterprise teams managing diverse asset portfolios. A vulnerability in your internet-facing payment system deserves a different response than the same vulnerability in an internal development tool. SSVC formalizes that distinction.
The limitation: SSVC requires per-assessment input. You need to classify each vulnerability against your specific infrastructure, which doesn't scale without automation. For teams managing hundreds of assets, this means investing in tooling or only applying SSVC to high-priority findings.
When to use it: Enterprise risk management with varied asset criticality. If your team has 5-10 different system classifications (internet-facing, internal, safety-critical), SSVC helps you make different decisions for each context. Solo developers and small teams can skip SSVC in favor of the simpler EPSS + KEV combination.
LEV: The New Kid (NIST 2025)
What it is: Likely Exploited Vulnerabilities, a metric introduced by NIST in 2025, aims to identify CVEs that are likely being exploited based on statistical and behavioral analysis — even without the direct evidence CISA requires for KEV inclusion.
What it measures: The likelihood that a CVE is being exploited, based on patterns observed in similar vulnerabilities, dark web intelligence, and exploitation infrastructure indicators. Where KEV says "we have evidence this is exploited" and EPSS says "we predict this might be exploited," LEV says "based on behavioral patterns, this is probably being exploited."
How it complements EPSS: Think of LEV as occupying the space between EPSS (forward-looking prediction) and KEV (backward-looking confirmation):
Certainty Spectrum for Exploitation
Low certainty High certainty
│ │
▼ ▼
EPSS LEV CISA KEV
"X% chance of "Behavioral patterns "Confirmed active
exploitation in suggest likely exploitation with
next 30 days" exploitation" evidence"
Current status: LEV was introduced in 2025 and is still evolving. The methodology, scoring scale, and update cadence are being refined. It is not yet widely integrated into vulnerability management tooling.
When to use it: Watch this space. LEV may become a valuable complement to EPSS by providing exploitation likelihood signals from a different analytical approach. For now, the EPSS + KEV combination provides the most actionable and mature data. As LEV matures, it may fill the gap between "predicted" and "confirmed" exploitation.
The 3-Signal Triage Method: Combining the Best of Each
With five scoring systems available, which ones should you actually use? GeekWala's recommended approach — the 3-Signal Triage Method — combines three signals that together cover the full risk picture:
The 3-Signal Triage Method
┌──────────┐
│ CVSS │ "How bad could it be?"
│ Severity │ Baseline context
└────┬─────┘
│
┌────▼─────┐
│ EPSS │ "Will anyone exploit it?"
│Probability│ Primary prioritization signal
└────┬─────┘
│
┌────▼─────┐
│ CISA KEV │ "Is it being exploited NOW?"
│ Evidence │ Highest-priority override
└──────────┘
Why three signals beat one:
- CVSS alone gives you severity without context — you can't distinguish the few percent that matter from the overwhelming majority that don't
- EPSS alone gives you probability but misses the confirmed exploitation that KEV provides — and some KEV entries have modest EPSS scores
- KEV alone is the highest-confidence signal but only covers ~1,300 CVEs — EPSS fills the gap across the rest of the published corpus (355,000+ CVEs and counting)
Together, KEV catches what's being exploited right now, EPSS catches what's likely to be exploited soon, and CVSS provides tiebreaker context when EPSS scores are similar. Each compensates for the others' blind spots.
Where SSVC and LEV fit: SSVC adds organizational context on top of the 3-Signal Method — useful for enterprises but unnecessary overhead for smaller teams. LEV may eventually supplement EPSS as a second probability signal, but it's not mature enough for production workflows yet.
Which System Should You Use?
The right combination depends on your team size and compliance requirements:
Recommended Scoring Systems by Team Profile
Team Profile Recommended Combination Skip
──────────────────────────────────────────────────────────────────
Solo developer EPSS + KEV SSVC, LEV
Small team (2-15) 3-Signal Triage Method SSVC, LEV
(CVSS + EPSS + KEV)
Mid-size (15-50) 3-Signal + SSVC for LEV
critical assets
Enterprise (50+) SSVC + EPSS + KEV + Nothing
LEV (when mature)
Compliance-required KEV mandatory, —
(BOD 26-04) EPSS strongly recommended
──────────────────────────────────────────────────────────────────
For most development teams, the 3-Signal Triage Method — CVSS as baseline, EPSS for prioritization, KEV for confirmed threats — is the sweet spot. It's simple enough to implement without enterprise tooling and powerful enough to eliminate 90%+ of alert noise.
GeekWala implements all three signals out of the box. Every dependency scan returns findings enriched with CVSS severity, daily EPSS scores, and CISA KEV status — sorted by actual exploitation risk, not theoretical severity.
See all three signals in action — scan your dependencies free →
Frequently Asked Questions
Can I use multiple scoring systems together?
Yes — and you should. No single scoring system answers every question about vulnerability risk. The 3-Signal Triage Method combines CVSS (severity baseline), EPSS (exploitation probability), and CISA KEV (confirmed exploitation) into a single workflow. Start with KEV for immediate threats, use EPSS to prioritize everything else, and use CVSS as a tiebreaker.
Is CVSS being replaced?
No. CVSS remains the universal baseline — every CVE has a CVSS score, and most compliance frameworks reference it. What's changing is how CVSS is used. Instead of treating CVSS as the primary prioritization signal, modern workflows use it as one input among several. EPSS and KEV supplement CVSS by adding exploitation context that CVSS was never designed to provide.
Where can I get EPSS scores for my dependencies?
The raw EPSS data is available through the FIRST.org EPSS API, but it requires you to look up each CVE individually. GeekWala enriches every dependency finding with daily EPSS scores automatically — just paste your manifest file or import your GitHub repository. No manual lookups needed.
Is LEV ready for production use?
Not yet. NIST introduced the LEV concept in 2025 and the methodology is still evolving. The scoring scale, update cadence, and integration pathways are being defined. For now, EPSS + CISA KEV provide mature, actionable exploitation signals. Monitor LEV development — it may become a valuable complement to EPSS as it matures, particularly for identifying exploitation activity that doesn't yet meet CISA's evidence threshold for KEV inclusion.
