SSVC Guide: Stakeholder-Specific Vulnerability Categorisation in Practice

SSVC (Stakeholder-Specific Vulnerability Categorisation) is a method for deciding what to do about a vulnerability by answering a short series of questions, instead of reading a single severity score. It was created by the CERT Coordination Center at Carnegie Mellon's Software Engineering Institute with CISA, and it ends in an action such as "Act" or "Track" rather than a number such as 9.8. The questions depend on who you are: a vendor building a patch asks different things from an organisation deciding how fast to deploy one. This guide explains SSVC in plain terms first, then covers the decision points, the CISA and CERT/CC trees, how KEV, EPSS and CISA Vulnrichment data feed it, and how to roll it out. It is written for vulnerability management leads, security engineers and anyone who has to defend a patching timeline.

Key takeaways

• SSVC outputs a decision, not a score. CISA's tree ends in Track, Track*, Attend or Act, and the CERT/CC deployer tree ends in Defer, Scheduled, Out-of-Cycle or Immediate.
• Exploitation status drives most outcomes. In the CERT/CC deployer model, active exploitation never results in Defer, which is why KEV is such a useful input.
• Your context is part of the answer. Mission impact, exposure and well-being are things only you can judge, so two organisations can reach different decisions on the same CVE and both be right.
• CISA already publishes part of the input. Vulnrichment adds Exploitation, Automatable and Technical Impact values to CVE records in the CISA ADP container, free to consume.
• It complements CVSS, it does not replace it. CVSS describes technical severity; SSVC turns severity, exploitation and context into a defensible priority.

What it is

In plain language: SSVC is a decision tree. You answer four or five questions about a vulnerability, such as "is anyone exploiting it?" and "how bad would it be for us if they did?", and the path through the tree tells you how urgently to respond. Because every answer comes from a short, defined list of values, the decision is repeatable and easy to explain to an auditor or a change board.

CERT/CC describes SSVC as a methodology for prioritising vulnerabilities based on the needs of the stakeholders involved in vulnerability management. CISA's SSVC page records that SEI and CISA created SSVC in 2019 and that CISA worked with SEI in 2020 to build its own tree, published in the CISA SSVC Guide (November 2022). The framework is maintained openly at certcc.github.io/SSVC, with a calculator, an explorer and Python code that define decision points and decision tables in versioned namespaces.

Stakeholder models

Most enterprises use either the CISA tree, because its outcomes are widely understood and its calculator is public, or the CERT/CC deployer tree, because it asks directly about system exposure. Software vendors and internal product teams that ship code should also run the supplier tree on their own products.

How it works

The CISA decision points

Mission Prevalence and Public Well-being Impact combine into one value, Mission and Well-being. In the CISA guide, any Essential mission prevalence gives High; Support gives Medium unless well-being is Irreversible (then High); Minimal gives Low, Medium or High as well-being moves from Minimal to Material to Irreversible.

The four CISA outcomes

• Track: no action needed now; monitor and remediate within standard update timelines.
• Track*: specific characteristics call for closer monitoring for changes; still remediate within standard timelines.
• Attend: supervisory staff need to address it, which may include requesting help or publishing a notice; remediate sooner than standard timelines.
• Act: supervisory and leadership staff address it, internal groups meet to decide the response, and remediation happens as soon as possible.

The deployer tree in brief

The CERT/CC deployer model swaps Mission and Well-being for Human Impact (Low, Medium, High, Very High, built from Safety Impact and Mission Impact) and adds System Exposure: Small (local service or tightly controlled network), Controlled (networked with access restrictions or mitigations) or Open (internet or a network where access cannot plausibly be restricted). If you do not know the exposure, CERT/CC says to assume Open. Exposure is also where mitigations show up: a compensating control that genuinely moves a system from Open to Controlled can lower the priority, and CERT/CC counts that as a successful outcome. For a Controlled rating the mitigation must reliably interrupt the attack.

Where the inputs come from

• CISA KEV: a listing is strong evidence for Exploitation = Active. For example, Log4Shell (CVE-2021-44228) was added to KEV on 10 December 2021 and MOVEit Transfer (CVE-2023-34362) on 2 June 2023, both flagged for known ransomware use. The SSVC project also defines an "In KEV" decision point for CISA-based models.
• EPSS: FIRST's Exploit Prediction Scoring System publishes a daily probability that a CVE will be exploited in the next 30 days. CERT/CC is explicit that Exploitation reflects the present state, not a prediction; EPSS can augment the decision or alert you to a likely change (a rising EPSS on a None item is a reason to re-check, not to mark it Active).
• CISA Vulnrichment: CISA enriches CVE records in the CISA ADP (Authorised Data Publisher) container without overwriting the CNA's data. Each analysed CVE gets the three SSVC points as an options list, for example {"Exploitation": "poc"}, {"Automatable": "yes"}, {"Technical Impact": "total"}, plus a KEV block with dateAdded where relevant, CWE where the CNA gave none, and CVSS v3.1 for some higher-risk CVEs. CISA stopped adding CPE strings on 10 December 2024. Check the version string (for example 2.0.3) before parsing, because it changes when the tree changes. Data is available through the CVE Services API or the GitHub repository.
• Your asset data: exposure, mission prevalence and well-being cannot be downloaded. They come from the CMDB, attack surface management and business impact analysis, which is why SSVC works best when asset ownership is already in place.

Rolling it out

1. Choose one tree. Pick the CISA tree or the CERT/CC deployer tree and write down why. Do not mix outcomes from both in one queue.
2. Pre-score your assets. Assign Mission Prevalence (or Mission Impact) and exposure to each business service once, owned by the service owner, and store it in the CMDB so it is reused for every CVE.
3. Automate the vulnerability-side inputs. Pull Vulnrichment SSVC values and KEV membership for each CVE your scanners report; use an analyst override field with a reason when your evidence differs.
4. Map outcomes to SLAs. For example Act or Immediate: emergency change, hours to days; Attend or Out-of-Cycle: next available window; Track*: standard SLA with weekly review; Track or Defer: normal patch cycle. Record these in the vulnerability management policy.
5. Run in shadow mode for one or two patch cycles. Compute SSVC alongside your current CVSS-based queue, compare where they disagree, and review those cases with service owners before switching.
6. Re-evaluate on change. Recompute when KEV, Vulnrichment or exposure changes; an item moving from Public PoC to Active should reopen automatically. Keep the previous CVSS queue available as a rollback for the first quarter.

Why it matters

Most estates report far more high and critical CVSS findings than any team can patch quickly, so a severity-only queue ends up ordered by score and age, not by danger. SSVC forces the two questions that matter most, exploitation and impact on your mission, into every decision, and it records the answers so you can show why something waited. The CitrixBleed 2023 case shows the pattern SSVC is built to catch: an internet-facing gateway (Open exposure), automatable exploitation once a public proof of concept appeared on 25 October 2023, then mass exploitation. Moving from Public PoC to Active on an Open, mission-essential system is exactly the path that lands on Act or Immediate. The case also shows that remediation is more than patching: stolen sessions stayed valid until they were terminated, which CERT/CC's note that remediation is not permanent and must be monitored anticipates.

Measuring it

• Time to remediate by outcome: median and 90th percentile for Act/Immediate versus Track/Defer; Act should be measured in days.
• KEV-listed items open past SLA: the most defensible single number to report upwards.
• Override rate: share of decisions where analysts changed an automated input, and the top reasons; a high rate points at bad asset data.
• Coverage of asset context: percentage of assets with an assigned mission prevalence and exposure; unknowns default to Open, which inflates priority.
• Re-evaluation latency: time between a KEV addition and the corresponding SSVC re-decision.

Framework mapping

Common misconceptions

• "SSVC replaces CVSS." It does not. CVSS vectors help answer Technical Impact and Automatable, and the SSVC project even publishes CVSS v4 analyst models. See the CVSS v4 Guide.
• "A rising EPSS score means Exploitation is Active." No. Active needs credible reports of real exploitation. EPSS is a prediction and a prompt to re-check.
• "CISA's Vulnrichment values are our decision." They cover only the vulnerability-side points. Without your Mission and Well-being or exposure values you have half a decision, and the same CVE can be Act for one organisation and Track for another.
• "Track means ignore." Track still means remediate within standard timelines and watch for change. Treating Track as risk acceptance creates a hidden backlog; formal acceptance belongs in the exceptions process. See the Security Exceptions and Risk Acceptance Guide.
• "Unknown exposure is low exposure." CERT/CC says the opposite: assume Open until you know. Teams that default unknowns to Small hide internet-facing assets from the Act queue.
• "Once patched, done." Rollbacks, old images and stolen credentials or sessions can bring the risk back, as CitrixBleed showed. Verify remediation and revoke secrets where the flaw exposed them.

Related concepts

• CVSS: technical severity scoring, the most common input to Technical Impact. See the CVSS v4 Guide.
• CVE, CWE and CPE: the identifiers that Vulnrichment enriches and that your scanner results must match to. See the CVE, CWE and CPE Guide.
• Risk-based vulnerability management: the wider programme SSVC sits inside. See the Risk-Based Vulnerability Management Guide and the Vulnerability Prioritisation Guide.
• Remediation SLAs: SSVC outcomes need agreed timelines and an exception route. See the Remediation SLAs and Vulnerability Exceptions Guide.
• Where identity fits: when a vulnerability exposes credentials, tokens or service account keys (gateways, CI/CD tools, secrets stores), Technical Impact is effectively Total for everything those identities can reach. Add credential rotation to the remediation plan. See the Top 10 NHI Risks.

Practitioner checklist

• Choose the CISA tree or the CERT/CC deployer tree and record the rationale in the vulnerability management policy.
• Assign mission prevalence (or mission impact) and exposure to every business service, owned by a named service owner.
• Default unknown exposure to Open and report the count of unknowns monthly.
• Ingest KEV and CISA Vulnrichment SSVC values automatically, checking the SSVC version string before parsing.
• Use EPSS as a re-check trigger, never as evidence of active exploitation.
• Map each outcome to a remediation SLA and change route, including an emergency path for Act or Immediate.
• Run SSVC in shadow mode for at least one patch cycle and review disagreements with the current queue.
• Log every analyst override with a reason and review overrides quarterly.
• Recompute decisions automatically when KEV, Vulnrichment or exposure data changes.
• Include credential, token and session revocation in remediation for flaws that expose secrets.

Standards and references

• CERT/CC: Stakeholder-Specific Vulnerability Categorization (SSVC) documentation
• CISA: Stakeholder-Specific Vulnerability Categorization
• CISA: SSVC Guide
• CERT/CC: SSVC Deployer Patch Deployment Priority model
• CISA: Vulnrichment repository
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Vulnerability Prioritisation Guide · Risk-Based Vulnerability Management Guide · CVSS v4 Guide · CVE, CWE and CPE Guide · Vulnerability Management Policy Template