← Glossary

Scoring & Metrics

SSVC (Stakeholder-Specific Vulnerability Categorization)

Also: Stakeholder-Specific Vulnerability Categorization · CISA SSVC · Track Attend Act · SSVC decision tree

Last reviewed:

In one sentence

SSVC is a decision-tree method (from CISA and Carnegie Mellon) that turns a few yes/no questions about a vulnerability into one of four actions — Track, Track*, Attend or Act — instead of a single severity number.

Why it matters

A CVSS base score answers "how bad could this be in the worst case?" — but a team drowning in 9.8s needs a different question: "given our situation, what do we do about this one, and by when?" SSVC answers that. It replaces a number you have to interpret with a decision you can act on and defend.

The payoff is triage that survives an audit. Instead of "we patched the 9s first", you can show why a given CVE was Act and another was Track: the same inputs (is it being exploited? is it exposed? what happens if it is?) always reach the same outcome, and the path is recorded. That is exactly the accountability regulators and boards ask for.

How the deployer tree works

The most-used variant is the deployer tree (for organisations running the affected software, as opposed to the vendor who ships it). You answer five decision points:

  • Exploitation — None / Public PoC / Active (evidence of in-the-wild use).
  • Exposure — Small / Controlled / Open (internet-facing).
  • Automatable — can steps 1–4 of the kill chain be reliably automated (No / Yes)?
  • Technical impact — Partial / Total control of the component.
  • Mission & well-being — Low / Medium / High impact on essential functions or safety.

Those combine into one of four outcomes, from least to most urgent: Track (standard patch cycle), Track* (watch closely, escalate if conditions change), Attend (act within days — engage the patch/IR teams), and Act (immediate; treat as an active incident risk). SSVC does not replace CVE and EPSS — it consumes them: EPSS and KEV inform the Exploitation answer, and CVSS impact informs Technical impact.

Try it yourself hands-on

You have an internet-facing service affected by a CVE with a public exploit. Score it properly rather than guessing from the CVSS.

  1. First establish exploitation. Paste the CVE into the EPSS Score Lookup: a high percentile or a CISA KEV flag means "Active"; a public PoC but no in-the-wild evidence means "Public PoC".
  2. Open the SSVC Decision Tree and walk the five points. Say you answer Exploitation = Active, Exposure = Open, Automatable = Yes, Technical impact = Total, Mission = High. The tool returns Act — Immediate (days, not weeks) and shows the exact path it took (“Active + Total impact + non-small exposure → Act”).
  3. Now change one answer: set Exposure = Small (the box is on an isolated management VLAN). Re-compute — the same vulnerability can drop to Attend. That difference is the whole point: context, not the CVSS number, moved the decision.
  4. Add the CVE ID and asset name in the context fields and use Export Markdown to drop the decision and its rationale straight into your change ticket or risk register.

Cross-check the "how bad" side with the CVSS v3.1 Calculator if you need an impact number for the same record.

Common misreadings

  • SSVC is not a replacement for CVSS — it uses it. Technical impact and exploitability feed the tree; you still need the underlying data.
  • "Track" does not mean "ignore". It means the standard patch cycle. Track* is the "keep an eye on it" bucket that escalates when exploitation or exposure changes.
  • Answer for your environment, not the CVE's worst case. The Exposure and Mission answers are about your deployment; copying another org's SSVC outcome defeats the "stakeholder-specific" part.