SSVC: vulnerability decision trees for a VOC

Scores invite arguments about thresholds. Is 7.0 the line, or 8.0? Should an EPSS probability of 0.05 count as "likely"? Every threshold is somewhat arbitrary, and people who disagree with an outcome can always argue that the line should move. Stakeholder-Specific Vulnerability Categorization (SSVC) takes a different approach: instead of computing a number, it asks a short sequence of questions with a few discrete answers each, and the path through those answers leads directly to an action.

This guide explains where SSVC comes from, how to evaluate its decision points in practice, how its outcomes map to remediation SLAs, and how to encode a tree so that prioritization becomes auditable. It builds on risk-based prioritization with CVSS v4, EPSS and KEV.

Where SSVC comes from

SSVC was developed by the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute, with the explicit goal of replacing score-based triage with decisions tailored to each stakeholder. The original work defines different trees for different roles — for example, suppliers deciding how urgently to build a fix and deployers deciding how urgently to apply it — because the same vulnerability calls for different decisions depending on who you are.

The US Cybersecurity and Infrastructure Security Agency (CISA) published its own customized version, often called CISA SSVC, which is the variant most vulnerability teams encounter. CISA also contributes SSVC-related data to CVE records through its Vulnrichment program, which makes some decision points easier to populate automatically.

The decision points

The CISA tree uses five decision points. Two of them are combined into one before the tree is applied.

Mission Prevalence and Public Well-being Impact are combined into Mission & Well-being with values Low, Medium or High. The first three decision points describe the vulnerability; Mission & Well-being describes your context. That split is the "stakeholder-specific" part: two organizations can agree on the vulnerability-level answers and still reach different decisions.

The outcomes

CISA's tree produces four outcomes:

• Track — no action beyond monitoring; remediate within standard update timelines.
• Track* — like Track, but the vulnerability has characteristics that warrant closer monitoring for changes.
• Attend — needs attention from supervisory levels; remediate sooner than standard timelines, and consider internal or external communication.
• Act — needs attention from leadership; remediate as soon as possible, applying mitigations immediately if a fix cannot be deployed.

The CERT/CC deployer tree uses a similar four-level scale with different names (Defer, Scheduled, Out-of-Cycle, Immediate). Whichever vocabulary you use, the important property is the same: each outcome is an action with an owner and a timeline, not a severity label.

Evaluating each decision point in practice

Exploitation

This is the most dynamic input and the one worth automating first.

• Active: the CVE is in the CISA KEV catalog, your SOC or threat intelligence has seen exploitation, or a credible vendor advisory reports it.
• Public PoC: exploit code or a detailed technique is publicly available (exploit databases, security research write-ups, public repositories), but active exploitation is not confirmed.
• None: neither of the above.

EPSS is not an Exploitation value, but it is a useful early-warning signal: a sharply rising EPSS score is a good trigger for an analyst to check whether the status has moved from None to Public PoC or Active.

Automatable

Ask whether exploitation can be scripted end to end against many targets without human steps. Network-reachable vulnerabilities without authentication or user interaction usually qualify; vulnerabilities requiring a victim to open a file or an attacker to hold valid credentials usually do not. CVSS v4 has a Supplemental metric called Automatable that captures the same idea and is a good source when vendors populate it.

Technical Impact

Total means the attacker gains full control of the affected software's behaviour or complete disclosure of its information — typically remote code execution or full authentication bypass. Everything else is Partial. The CVSS vector helps: high impact on confidentiality, integrity and availability of the vulnerable system usually indicates Total.

Mission & Well-being

This comes from your asset inventory, not from any feed. Map your criticality tiers to Mission Prevalence once (for example tier 1 → Essential, tier 2 → Support, tiers 3–4 → Minimal), and set Public Well-being Impact per business service. Most enterprise services are Minimal; hospitals, utilities and safety systems are not.

A simplified tree, encoded

The excerpt below is a simplified illustration of how a tree can be encoded as data. It is not a reproduction of CISA's published tree; consult the official guidance before adopting it, and adjust paths to your own risk appetite.

# ssvc-policy.yaml — simplified, illustrative decision table
# order: exploitation, automatable, technical_impact, mission_wellbeing
default: track
rules:
  - when: {exploitation: active, technical_impact: total, mission_wellbeing: high}
    outcome: act
  - when: {exploitation: active, automatable: "yes", mission_wellbeing: high}
    outcome: act
  - when: {exploitation: active, mission_wellbeing: medium}
    outcome: attend
  - when: {exploitation: active}
    outcome: attend
  - when: {exploitation: public_poc, automatable: "yes", technical_impact: total, mission_wellbeing: high}
    outcome: attend
  - when: {exploitation: public_poc, technical_impact: total}
    outcome: track_star
  - when: {exploitation: none, automatable: "yes", technical_impact: total, mission_wellbeing: high}
    outcome: track_star
outcome_to_tier:
  act: P1
  attend: P2
  track_star: P3
  track: P4

import yaml

POLICY = yaml.safe_load(open("ssvc-policy.yaml"))

def decide(finding: dict) -> str:
    """Return the first matching outcome; rules are ordered most to least urgent."""
    for rule in POLICY["rules"]:
        if all(finding.get(k) == v for k, v in rule["when"].items()):
            return rule["outcome"]
    return POLICY["default"]

f = {"exploitation": "active", "automatable": "yes",
     "technical_impact": "total", "mission_wellbeing": "high"}
print(decide(f), POLICY["outcome_to_tier"][decide(f)])  # act P1

Storing the tree as data has two benefits. Changes go through review like any other policy change, and every decision can be explained by pointing at the rule that fired — useful when a team disputes a priority or an auditor asks why something waited.

Two worked examples (hypothetical)

Example A. A remote code execution flaw in a VPN appliance, listed in KEV, exploitable without authentication, on the organization's only remote-access gateway. Exploitation = Active, Automatable = Yes, Technical Impact = Total, Mission Prevalence = Essential → Mission & Well-being = High. Outcome: Act. The VOC opens an emergency change, the SOC adds monitoring for exploitation indicators, and if the vendor patch is not yet available the mitigation in the advisory is applied immediately.

Example B. A privilege escalation flaw in a desktop application with a public proof of concept, requiring local access, on standard employee laptops. Exploitation = Public PoC, Automatable = No, Technical Impact = Total, Mission & Well-being = Low. Outcome under the simplified table: Track*. It goes into the normal patch cycle, and the analyst sets a watch so the decision is re-evaluated if the CVE is added to KEV.

SSVC compared with score-based approaches

The approaches combine well. Many VOCs use EPSS to decide which findings an analyst should look at for a status change, KEV and threat intel to set Exploitation, CVSS vectors to infer Technical Impact and Automatable, and SSVC to make the final call.

Mapping outcomes to SLAs

Outcomes only drive behaviour when they carry deadlines. An example mapping — calibrate it to your capacity and see remediation SLAs for clock rules:

Getting started

1. Automate Exploitation from KEV plus your threat intelligence, and review it daily.
2. Derive Technical Impact and Automatable from CVSS vectors and CISA Vulnrichment where available, with analyst override.
3. Map criticality tiers to Mission Prevalence once, and store Public Well-being Impact per business service.
4. Encode the tree as reviewed data, log which rule fired for every decision, and route outcomes through your remediation workflow.
5. Review a sample of decisions monthly to check that the tree still matches your risk appetite.