SSVC: Stakeholder-Specific Vulnerability Categorization, explained

SEI's own December 2019 announcement of the methodology states it presents "a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some of the problems with the Common Vulnerability Scoring System (CVSS)." CVSS — see our CVSS v4 vs v3.1 guide — produces one portable severity number regardless of who reads it. SSVC instead starts from the observation that a vendor deciding whether to rush a patch, an organization deciding whether to deploy one, and a coordinator triaging an incoming report are answering three different questions, so SSVC gives each of them its own decision tree with its own inputs and its own categorical outcome, rather than asking all three to interpret the same number differently.

CISA's own SSVC resource page lists the five values that feed its government/critical-infrastructure decision tree. The values column follows the CERT/CC decision point reference:

CERT/CC defines Automatable precisely: "yes" means attackers can reliably automate the first four kill-chain steps (reconnaissance, weaponization, delivery and exploitation). Exploitation "active" needs shared, reliable evidence of use in the wild, not a rumour.

The broader CERT/CC reference documentation — the methodology's academic and engineering home — documents a wider set of decision points used across its full family of trees, including Safety Impact, System Exposure, Value Density, Mission Impact, and several points specific to suppliers (e.g., Supplier Involvement) and coordinators (e.g., Report Credibility, Public Value Added). Which decision points apply depends on which stakeholder tree — supplier, deployer, or CISA's own adapted tree — is in use.

SSVC decisions take the shape of simple conditional logic. CERT/CC's own how-to documentation gives this illustrative form:

"IF (Exploitation IS Public PoC) AND (System Exposure IS controlled) AND (Automatable IS no) AND (Human Impact IS medium) THEN priority is scheduled."

CISA's adapted tree for government and critical-infrastructure use resolves to one of four named outcomes, as stated on CISA's SSVC page:

It is worth being precise here: this four-outcome scale (Track / Track* / Attend / Act) is CISA's own 2020 adaptation, not the original SEI methodology's output. The CERT/CC documentation for the general-purpose SEI trees describes a different outcome scale for deployers — immediate, scheduled, out-of-cycle, and defer. An organization adopting "SSVC" should confirm which published tree, and which outcome labels, it is actually implementing before building tooling or SLAs around them.

A device maker that builds and ships the fix is a supplier in SSVC terms, so the supplier patch development tree is the natural fit; the deployer tree describes the decision your customers make when your update arrives. The CERT/CC documentation publishes each tree as a full decision table:

Two supplier inputs are composites. Utility combines Automatable with Value Density: "laborious" (not automatable, diffuse), "efficient" (one of the two) or "super effective" (automatable and concentrated). Public Safety Impact is "minimal" when Safety Impact is negligible and "significant" when it is marginal, critical or catastrophic. Safety Impact itself uses IEC 61508-style harm levels, which a medical, industrial or automotive device maker usually has in its hazard analysis already.

CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", on 10 June 2026. It supersedes BOD 19-02 and BOD 22-01 and applies to US federal civilian executive branch agencies. The directive states that its Table 1 remediation timelines are "informed by the SSVC system". Instead of a flat due date for every KEV entry, the deadline now depends on four yes/no-style inputs. Selected rows of the published decision table:

The directive binds agencies, not vendors. A device maker selling into US federal sites will still feel it: an agency that must patch an internet-facing, KEV-listed device within three days needs a fixed firmware build and a clear advisory from you inside that window.

Some values describe the vulnerability and can be shared by everyone; others describe your product or your customer's deployment and only you or they can set them.

CISA's Vulnrichment project adds three SSVC decision points — Exploitation, Automatable and Technical Impact — to every CVE its ADP (Authorized Data Publisher) container covers. Its README says the data follows the CISA Coordinator tree and carries version 2.0.3 (SSVC 2.0, tree version 3). BOD 26-04 relies on the same program for KEV status, automation and technical impact. Our NVD backlog and Vulnrichment guide shows where these fields sit in a CVE record. FIRST's EPSS fits in too: the CERT/CC page on using EPSS with SSVC shows EPSS probabilities as an input to the Exploitation decision point and percentiles as a way to amplify an outcome.

Device makers and PSIRTs already juggling multiple prioritization signals can treat these as complementary rather than competing: CVSS (our guide, or the CVSS calculator) measures intrinsic technical severity; CISA's KEV catalog and FIRST's EPSS (our guide) measure real-world exploitation and the probability of future exploitation; SSVC is the layer that turns any of those signals, plus context like exposure and mission impact, into a concrete action for a specific organization. A mature vulnerability-handling process (see CVD process: ISO/IEC 29147 and 30111) can use CVSS or EPSS as one input into an SSVC-style decision rather than treating any single score as the whole answer.

• Mixing outcome scales. "Attend" and "out-of-cycle" belong to different trees; a dashboard that mixes them cannot be audited.
• Copying CISA's ADP values without reading them. "Automatable: yes" is assessed for the vulnerability in general; a service that is disabled by default on your device can change the picture, and the reason belongs in the record.
• Treating "defer" as "closed". Defer is a priority, not a VEX status. The CVE stays open and is re-run when an input changes.
• Leaving safety to the security team alone. Public Safety Impact should come from the same hazard analysis your safety engineers maintain.
• No date on the inputs. Exploitation changes; an outcome without the date its inputs were read cannot be defended later.

SoftWSP extracts a firmware SBOM and matches its components against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories, and orders the matches KEV first, then EPSS, then CVSS. That gives a PSIRT the public inputs for the Exploitation decision point and the CVSS context for Technical Impact, with sources cited in an AI-drafted report that an engineer reviews. SoftWSP does not compute an SSVC outcome, does not read CISA's ADP SSVC values, and does not judge value density, safety impact or reachability; those stay with your engineers. To build an SSVC-based triage workflow around that data, see PSIRT services and the firmware security testing pillar guide.

This guide summarises public CISA and Carnegie Mellon SEI publications; it does not constitute legal or compliance advice.