Open any vulnerability report and you'll see some combination of these five acronyms attached to the same CVE. They're not competing standards — each one measures something the others don't, and a mature vulnerability management program uses all five together rather than picking one.
This glossary gives you a canonical, citable definition for each term, followed by a worked example of how they combine into a single triage decision.
What We'll Cover
- CVSS — Common Vulnerability Scoring System
- EPSS — Exploit Prediction Scoring System
- CISA KEV — Known Exploited Vulnerabilities Catalog
- VEX — Vulnerability Exploitability eXchange
- SSVC — Stakeholder-Specific Vulnerability Categorization
- Quick-reference table
- How the systems combine in practice
CVSS — Common Vulnerability Scoring System
CVSS (Common Vulnerability Scoring System) is a 0.0–10.0 score describing how severe a vulnerability could be if exploited, derived from static technical characteristics — attack vector, attack complexity, privileges required, user interaction required, and impact on confidentiality, integrity, and availability. It does not measure whether exploitation is likely, only how bad the outcome would be if it happened. Maintained by FIRST.org, currently on version 4.0, and referenced by nearly every published CVE record worldwide.
CVSS is set once at disclosure (or when a scoring error is corrected) and rarely changes afterward. A CVE scored 9.8 in 2019 still reads 9.8 today, regardless of whether anyone has ever exploited it. That static nature is CVSS's core limitation: it's a snapshot of theoretical blast radius, not a live threat signal. It remains the industry standard for compliance frameworks (PCI-DSS, FedRAMP, HIPAA) because it's deterministic and auditable — the same vulnerability produces the same score regardless of who's scoring it or when. For the full comparison against EPSS, see CVSS vs EPSS.
EPSS — Exploit Prediction Scoring System
EPSS (Exploit Prediction Scoring System) is a 0.0–1.0 probability score estimating the likelihood a vulnerability will be exploited in the wild within the next 30 days, generated by a machine learning model trained on real-world exploitation signals rather than a human analyst's static judgment. Unlike CVSS, EPSS is dynamic — FIRST.org retrains the model and republishes every CVE's score daily as new threat intelligence arrives, so the number moves as exploitation activity actually changes.
EPSS ingests signals CVSS never considers: published proof-of-concept code, mentions in exploit databases and malware repositories, dark-web chatter, and observed scanning activity. Research from the FIRST EPSS team shows at most ~6% of all published CVEs are ever actually exploited — the most generous published estimate, with stricter datasets nearer 1–2%. EPSS exists to identify that slice before exploitation happens, rather than after. A CVE can carry a low CVSS score and a high EPSS score (an easy-to-weaponize authentication bypass) or a high CVSS score and a near-zero EPSS score (a theoretically catastrophic flaw nobody has bothered to exploit). See What is EPSS? for the full model methodology.
CISA KEV — Known Exploited Vulnerabilities Catalog
CISA KEV (Known Exploited Vulnerabilities Catalog) is a curated, continuously updated list of CVEs that the U.S. Cybersecurity and Infrastructure Security Agency has confirmed are being actively exploited in the wild right now — not predicted, not modeled, confirmed by direct evidence. Unlike EPSS's probabilistic forecast, KEV membership is a binary, evidence-based fact: a CVE is either on the catalog because CISA has verified real-world exploitation, or it simply isn't there yet. Maintained by CISA.
KEV entries carry a dueDate — the deadline by which U.S. federal civilian agencies must remediate. This was set by Binding Operational Directive 22-01, now superseded by BOD 26-04, which derives timelines from a four-factor risk matrix rather than KEV membership alone. Even outside federal compliance scope, KEV membership is treated industry-wide as the strongest possible "patch now" signal — it's confirmation, not prediction. A vulnerability with a modest CVSS score of 5.3 and no EPSS elevation still demands same-day attention the moment it lands on KEV. Full mechanics in CISA KEV Explained.
VEX — Vulnerability Exploitability eXchange
VEX (Vulnerability Exploitability eXchange) is a machine-readable document format that states whether a specific product is actually affected by a given vulnerability in one of its components, using standardized status values — affected, not affected, fixed, or under investigation — asserted by the vendor who knows how the component is actually used. Where CVSS, EPSS, and KEV describe a vulnerability in the abstract, VEX narrows that down to your specific product's real exposure. Advanced by the CISA-facilitated VEX working group as a companion to SBOM data.
The problem VEX solves is SBOM noise. A Software Bill of Materials might list libxml2 as a dependency, and a scanner flags 12 CVEs against that library. But your product might call libxml2 in a way that never reaches the vulnerable code path in 10 of those 12 — VEX lets the vendor state that explicitly, so downstream consumers don't waste triage effort on vulnerabilities that can't actually be exploited in their deployment. A vendor publishing accurate VEX statements alongside an SBOM turns "12 CVEs found" into "2 CVEs that matter." For the full walkthrough — status categories, format comparison (CSAF, OpenVEX, CycloneDX), and how to create your first VEX statement — see What is VEX?
SSVC — Stakeholder-Specific Vulnerability Categorization
SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision-tree framework that converts vulnerability data — exploitation status, technical impact, automatability, and mission/safety impact — into one of four discrete recommended actions: Track, Track, Attend, or Act — tailored to the specific operational role of the organization applying it, whether vendor, deployer, or coordinator.* Unlike CVSS, EPSS, or KEV, each of which outputs a single number or flag, SSVC outputs an actual, actionable decision rather than a one-size-fits-all severity rating. Developed jointly by CISA and Carnegie Mellon University's Software Engineering Institute.
SSVC is "stakeholder-specific" because the same CVE can land on a different branch of the decision tree depending on who's asking. A vulnerability in a library used only in internal tooling might resolve to "Track" for a SaaS company, while the same CVE in a medical device's firmware resolves to "Act" because the mission/safety impact input differs. This is the piece CVSS, EPSS, and KEV don't provide on their own — they describe the vulnerability; SSVC tells a specific organization what to do about it, using those other signals as inputs.
Quick-Reference Table
For a one-glance summary of what each system outputs and who maintains it — not a recommendation on which to use, see CVSS, EPSS, KEV, SSVC, and LEV Compared for that:
| System | Output | Type | Question Answered | Maintained By | Update Cadence |
|---|---|---|---|---|---|
| CVSS | 0.0–10.0 score | Static, deterministic | How bad could this be? | FIRST.org | Set once at disclosure |
| EPSS | 0.0–1.0 probability | Dynamic, probabilistic (ML) | Will this be exploited in 30 days? | FIRST.org | Daily |
| CISA KEV | Binary (on list / not) | Evidence-based, confirmed | Is this being exploited right now? | CISA | Continuous, as confirmed |
| VEX | Status enum per product | Vendor-asserted, product-specific | Does this vulnerability actually affect my product? | CISA VEX working group | Per release / per advisory |
| SSVC | Decision (Track/Attend/Act) | Rule-based decision tree | What should my organization do about this? | CISA / CMU SEI | Applied per-assessment |
Read this table by column, not by row — no single system is "better" than another because they're not measuring the same thing. CVSS and EPSS describe the vulnerability itself from two different angles (impact vs. likelihood). KEV confirms exploitation has already happened. VEX narrows the vulnerability's relevance to your specific product. SSVC takes all of that as input and outputs an action.
This page covers the five systems most teams encounter day to day. For a deeper comparison that also brings in NIST's newer LEV (Likely Exploited Vulnerabilities) metric, see CVSS, EPSS, KEV, SSVC, and LEV Compared.
How the Systems Combine in Practice
Here's a single CVE moving through all five systems, in the order a mature triage workflow would apply them:
CVE-2026-EXAMPLE — authentication bypass in a bundled logging library
1. CVSS: 6.5 (Medium)
"Moderate technical severity — network-exploitable, no auth required,
but limited impact to confidentiality only."
2. EPSS: 0.61 (61% probability of exploitation in 30 days)
"Elevated — public PoC code exists, scanning activity observed."
3. KEV: Not yet listed
"Not yet confirmed as actively exploited — but EPSS is trending up."
4. VEX: "affected" for Product A (calls the vulnerable code path directly)
"not_affected" for Product B (uses the library in a mode that never
reaches the flaw)
5. SSVC: Product A → "Act" (affected + high EPSS + internet-facing deployment)
Product B → "Track" (not affected — no action required despite
the same CVE and the same CVSS/EPSS scores)
Notice that CVSS and EPSS are identical for both products — they describe the vulnerability, not your deployment. VEX is what splits the outcome: Product A needs emergency remediation and Product B needs nothing, despite sharing the exact same CVE, CVSS score, and EPSS score. SSVC formalizes that split into an explicit recommended action for each stakeholder.
This is also the logic behind the 3-Signal Triage Method: CISA KEV membership overrides everything else and means patch today; absent KEV, a high EPSS score combined with a reachable CVSS-scored impact means patch this week; everything else follows normal patch cadence. VEX and SSVC formalize the "reachable" and "for whom" parts of that judgment call into standardized, machine-readable outputs instead of tribal knowledge.
What is the difference between CVSS and SSVC?
CVSS produces a single severity number describing a vulnerability in the abstract. SSVC produces a specific recommended action (Track, Attend, or Act) for a specific type of stakeholder, using CVSS-adjacent inputs like technical impact alongside exploitation status and mission/safety impact. CVSS answers "how bad is this vulnerability?" — SSVC answers "what should my organization do about it?"
Do I need to implement all five scoring systems myself?
No. CVSS and EPSS scores are published centrally by FIRST.org and available via API for any CVE. CISA publishes the KEV catalog as a downloadable JSON feed. VEX statements come from the vendors of the software you use — you consume them, you don't generate them for third-party components. SSVC is the one framework you typically apply yourself, using the other four as inputs to walk your own decision tree, or you adopt a scanning platform that has already encoded the decision logic for you.
Is VEX the same thing as an SBOM?
No, but they're designed to work together. An SBOM is an inventory — it lists every component in your software and their versions. VEX is a exploitability statement layered on top of that inventory, telling you whether a specific vulnerability in a specific listed component actually affects the product. An SBOM without VEX tells you what CVEs theoretically apply to your dependency tree; VEX tells you which of those actually matter.
Why isn't my scanner using EPSS or KEV yet?
Many vulnerability scanners still default to CVSS-only sorting because it requires no additional data source — the score ships embedded in the CVE record itself. EPSS and KEV both require a separate daily data feed and enrichment step. Scanners that skip this step aren't wrong, exactly — they're just incomplete, surfacing severity without exploitation context. npm audit is a well-known example of a CVSS-only tool that doesn't factor in real-world exploitation likelihood.
Does SSVC replace CVSS and EPSS?
No — SSVC consumes CVSS-adjacent technical-impact data and can incorporate EPSS/KEV status as inputs to its decision tree; it doesn't compete with them or replace their outputs. Think of CVSS, EPSS, KEV, and VEX as the four inputs, and SSVC as the decision function that turns those inputs into an action for a specific type of organization.
Every finding, scored five ways — automatically.
Scan your dependencies now → — GeekWala enriches every vulnerability with CVSS severity, EPSS exploitation probability, and CISA KEV status out of the box, so you can triage by what's actually exploitable instead of sorting by CVSS alone. No account needed.
