TL;DR: CVSS tells you how bad a vulnerability could be. SSVC tells you what you should actually do about it — right now, given your exposure. If your patch queue is still sorted by CVSS score alone, this article explains what you're missing and how to close the gap.
The Problem with CVSS-Only Triage
Most vulnerability management programs still prioritize remediation by CVSS severity. A 9.8 goes to the top of the queue. A 6.5 waits. The logic feels sound — until you realize that CVSS was designed to measure intrinsic severity, not operational urgency.
CVSS doesn't tell you whether a vulnerability is being actively exploited in the wild. It doesn't tell you whether an attacker can script the entire kill chain without human effort. And it doesn't account for whether the affected system is mission-critical to your organization or sitting in an isolated test lab.
The result: security teams burn cycles chasing high-CVSS vulnerabilities that pose no real-world threat today, while lower-scored vulnerabilities with active exploitation and full automation potential sit unpatched.
CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) framework was built to fix exactly this.
1. Exploitation
Answers: Is there evidence that this vulnerability is being exploited?
|
Value |
Meaning |
|
None |
No credible public reporting of exploitation activity |
|
Public PoC |
A proof-of-concept exploit exists publicly, but no confirmed active exploitation |
|
Active |
Confirmed, reliable reports of exploitation in the wild (e.g., CISA KEV catalog, vendor advisories, threat intel feeds) |
This is arguably the single most important input in the entire model. A vulnerability with active exploitation demands a fundamentally different response than one with only theoretical risk — regardless of what its CVSS score says.
2. Automatable
Answers: Can an attacker script the entire attack chain — reconnaissance, weaponization, delivery, and exploitation — without human intervention?
|
Value |
Meaning |
|
No |
At least one step in the kill chain requires human effort, judgment, or interaction |
|
Yes |
The full attack chain from initial recon to exploitation can be automated end-to-end |
This decision point captures something CVSS doesn't: scalability of attack. A vulnerability that requires manual, targeted exploitation is a different class of threat than one where an attacker can write a script and spray it across the internet. CISA also considers vulnerability chaining — if two vulnerabilities in the same product can be chained together to make the exploitation fully automated, each vulnerability is scored as Automatable: Yes.
3. Technical Impact
Answers: What level of control does the exploit give the attacker over the affected component?
|
Value |
Meaning |
|
Partial |
The exploit gives the threat actor limited control or limited information exposure. A denial-of-service attack is a form of limited control |
|
Total |
The exploit gives the adversary total control over the behavior of the software, or total disclosure of all information on the system |
This is the closest SSVC gets to CVSS's severity concept, but it's scoped to the affected component and simplified to a binary: partial or total.
SSVC in USEM
Starting with the September release (plugin version 30.7.0) of the Vulnerability Response Integration with NVD, USEM customers can now ingest and operationalize these three CISA-scored SSVC attributes directly within their vulnerability management workflows.
Ingestion: SSVC Attributes on CVE Records
The NVD integration now parses and maps the SSVC data that CISA publishes as an Authorized Data Publisher (ADP) through its Vulnrichment program. When the NVD integration runs, three new fields are populated on CVE records (sn_vul_nvd_entry):
→ Exploitation — None, Public PoC, or Active
→ Automatable — Yes or No
→ Technical Impact — Partial or Total
Propagation: Visibility on Third-Party Entries (TPEs)
SSVC attributes are ingested at the CVE level, but vulnerability management workflows in USEM also operates at the Third-Party Entry (TPE) and Finding (VIT) level. A TPE is a scanner-specific vulnerability definition — a Qualys QID, a Tenable Plugin ID, a Rapid7 finding — and each TPE maps to one or more CVEs.
The SSVC fields roll up from CVE records to their linked TPE records, following the same propagation pattern that existing enrichment fields like CISA KEV status, EPSS score, and ransomware indicators already use. This means customers can query, filter, and build rules against SSVC attributes at the TPE level — which is where scanner findings connect to your actual asset estate via Vulnerable Items.
Operationalization: Risk Calculator, RT Rules, and Grouping
With SSVC attributes available at the TPE level, USEM customers can leverage them across three core prioritization engines:
Risk Calculator: SSVC attributes can be used as inputs to the severity calculator, enabling risk scores that reflect real-world exploitation context rather than CVSS severity alone. When an SSVC value changes on a CVE (e.g., Exploitation moves from "None" to "Active"), the recalculation flag is triggered, and the severity calculator automatically re-scores every active VIT, AVIT, and CVIT tied to that CVE — ensuring risk scores stay current as the threat landscape evolves.
Remediation Target (RT) Rules: RT rules set remediation due dates on Vulnerable Items. With SSVC attributes available, customers can build RT rules that map directly to risk-based remediation timelines. For example, a rule can enforce a 3-day remediation window for vulnerabilities where Exploitation = Active, Automatable = Yes, and Technical Impact = Total — aligning with the most aggressive tier in CISA's BOD 26-04 guidance.
Grouping: SSVC attributes can be used as grouping criteria, enabling security teams to organize their remediation workload by exploitation status, automation potential, or impact level rather than by CVSS score bands alone.
Getting Started
If you're a USEM customer looking to operationalize SSVC attributes:
- Ensure your NVD integration is current — The September release (plugin version 30.7.0) of the Vulnerability Response Integration with NVD includes the SSVC ingestion capability. Verify your integration is running the latest version.
- Validate SSVC fields on CVE records — After the NVD integration runs, confirm that Exploitation, Automatable, and Technical Impact are populated on your CVE records.
- Check TPE propagation — Verify that the SSVC attributes have rolled up from CVEs to their linked Third-Party Entries, making them available for downstream rule evaluation.
- Build or update your Risk Calculator rules — Add SSVC attributes as inputs to your severity calculator to shift risk scoring from CVSS-only to exploitation-aware.
- Configure Remediation Target rules — Create RT rules that map SSVC attribute combinations to remediation timelines aligned with your organization's risk tolerance — or with BOD 26-04's tiered model if you're adopting it as a benchmark.
- Review Grouping configurations — Consider grouping Vulnerable Items by Exploitation status or Automatable flag to surface the highest-urgency findings first in your remediation queues.
