Stakeholder-Specific Vulnerability Categorization (SSVC)

Stakeholder-Specific Vulnerability Categorization (SSVC) is a vulnerability prioritization method from CERT/CC, adopted by CISA, that replaces a severity score with a decision table. A few categorical facts, such as whether a flaw is exploited, automatable, or gives total control, map directly to an action like Track or Act. Since June 2026, SSVC sets federal patch deadlines.

SSVC asks "what should we do about this vulnerability?" instead of "how bad is it?" Each input, called a decision point, takes two to four named values. A decision table lists every combination of values and the action it produces, so any outcome can be traced back to the facts behind it. For the new CVEs it assesses, CISA publishes three of those facts inside the CVE record itself, through its Vulnrichment program. On June 10, 2026, BOD 26-04 made an SSVC table the source of federal remediation deadlines, from 3 days to "fix on system upgrade."

Our position: SSVC is the right shape for triage, and a better input than a CVSS score. It is explicit, versioned, and auditable. It has two blind spots that matter for open source. The values CISA publishes describe a library in the abstract, not the way your application uses it. And SSVC only ranks CVEs, so it has nothing to say about a malicious package.

SSVC works by enumerating decisions instead of computing a number. A stakeholder picks a small set of decision points, lists every combination of their values, and assigns each combination an outcome. The result is a lookup table, not a formula.

The design is a direct response to the Common Vulnerability Scoring System (CVSS). A CVSS 3.1 base score folds eight metrics into a number from 0.0 to 10.0 through a formula whose constants the specification never justifies. Jonathan Spring and colleagues at the CERT Coordination Center (CERT/CC) introduced SSVC in a November 2019 report that put the objection plainly: "CVSS avoids talking about decisions and instead takes technical severity as its fundamental concept." In SSVC, technical severity is one input among several.

SSVC models three stakeholder roles, each with its own decision points and outcomes. These come from the CERT/CC SSVC documentation:

• Suppliers build and ship patches. Their outcomes are Defer, Scheduled, Out-of-cycle, and Immediate.
• Deployers decide when to apply patches. They use the same four outcomes, driven by Exploitation, System Exposure, Automatable, and Human Impact.
• Coordinators triage reports and decide whether to publish. CISA acts as a coordinator, and its published SSVC data comes from a coordinator table.

The decision points CISA relies on are short and concrete:

• Exploitation: none, public PoC, or active. Active means credible, observed use in the wild.
• Automatable: yes if an attacker can reliably automate reconnaissance, weaponization, delivery, and exploitation, the first four steps of the kill chain. Unauthenticated remote code execution is usually yes.
• Technical Impact: partial or total. Total means full control of the software or full disclosure of its data. Denial of service counts as partial.

Everything in SSVC is versioned. Each decision point, value set, and table carries a semantic version, and CERT/CC recommends that every decision be timestamped and marked with the SSVC version used. In June 2026 the project formally renamed "decision trees" to "decision tables" (ADR-0014, shipped in SSVC v2026.6). The tree drawings remain, but the table is the normative artifact.

CISA published its own SSVC table in November 2022. It uses Exploitation, Automatable, and Technical Impact, plus a fourth point, Mission and Well-being Impact, which only the affected organization can answer. Mission and Well-being is low, medium, or high, derived from how essential the affected system is to the organization's mission and how much harm exploitation could do to the public.

The four CISA outcomes are defined by who needs to pay attention and how fast:

• Track: no action now. Remediate within standard update timelines.
• Track*: same timelines, but the vulnerability deserves closer monitoring for changes.
• Attend: supervisory staff get involved. Remediate sooner than standard timelines.
• Act: leadership gets involved. Remediate as soon as possible.

The table has 3 × 2 × 2 × 3 = 36 rows. We counted the outcomes in CERT/CC's machine-readable copy, cisa_coordinator_2_0_3.csv: 18 rows say Track, 4 say Track*, 10 say Attend, and 4 say Act.

The figure shows all 36 rows. The same data as a table:

Three properties fall out of the table that no CVSS calculator would show you:

• Act requires active exploitation. All four Act rows have Exploitation: active. A public proof of concept never produces more than Attend.
• Mission dominates. With Mission and Well-being low, only 2 of 12 rows rise above Track, and both are actively exploited and automatable.
• Half the table is Track. The default answer is "patch on your normal cycle," which is what most vulnerabilities deserve.

SSVC differs from CVSS in what it outputs: an action for a specific stakeholder, not a severity number for the flaw. CVSS answers how bad a vulnerability could be in the worst case. SSVC answers what this organization should do this week. The two also fail differently, and so does the Exploit Prediction Scoring System (EPSS), the third signal teams usually reach for.

Verdict: use SSVC as the policy that turns facts into actions, because it is the only one of the three that produces a decision you can defend line by line. Feed it observed exploitation from the CISA KEV catalog, use EPSS to sort inside an outcome, and keep CVSS for tie-breaking. Our longer treatment of the ordering is in vulnerability prioritization.

The volatility gap is concrete. curl's CVE-2024-11053, a netrc credential leak, drew a CVSS 9.1 from CISA's ADP in December 2024, an episode the curl project cited when it publicly rejected CVSS. The curl team rated the bug low severity. The same CVE record now carries a CISA CVSS of 3.4 (LOW). CISA's SSVC values for it, assessed on December 15, 2024, read Exploitation poc, Automatable no, Technical Impact partial. Under the CISA table, that is Track at low or medium mission impact and Track* at high. A score that moved 5.7 points on one record is a weak basis for a deadline. The SSVC values on the same record land where the maintainers did.

SSVC data for individual CVEs comes from CISA's Vulnrichment program, which writes it into the CVE record's Authorized Data Publisher (ADP) container. CISA launched Vulnrichment in May 2024, as the National Vulnerability Database (NVD) backlog passed 10,000 unenriched CVEs. The CVE Program added CISA as an ADP on June 4, 2024, so the data ships in the official CVE JSON and in the cisagov/vulnrichment repository.

Here is the ADP container from the record for CVE-2024-3094, the xz backdoor, pulled from that repository:

curl -s https://raw.githubusercontent.com/cisagov/vulnrichment/develop/2024/3xxx/CVE-2024-3094.json \
  | jq '.containers.adp[]
        | select(.title == "CISA ADP Vulnrichment")
        | .metrics[].other | select(.type == "ssvc") | .content'

{
  "id": "CVE-2024-3094",
  "role": "CISA Coordinator",
  "options": [
    {
      "Exploitation": "none"
    },
    {
      "Automatable": "yes"
    },
    {
      "Technical Impact": "total"
    }
  ],
  "version": "2.0.3",
  "timestamp": "2024-04-02T04:00:23.138684Z"
}

Four details in that object matter if you consume it:

• Mission and Well-being is missing on purpose. CISA publishes the three vulnerability facts. The fourth input describes your organization, and only you can supply it.
• The version string encodes two things. In "2.0.3," 2.0 is the SSVC version and 3 is the revision of the CISA Coordinator table, per the Vulnrichment README. Parse the version before you trust the values.
• Value spellings differ from the spec. Vulnrichment writes "poc" where CERT/CC's tables say "public poc." A strict lookup against the CERT/CC CSV will miss every PoC row unless you normalize.
• The timestamp is the assessment date. The xz values carry a timestamp of April 2, 2024, four days after disclosure, and the record shows no later assessment. Exploitation is a fact about the world that changes, so an old "none" is weak evidence.

The same record's CNA container, written by Red Hat, gives the xz backdoor a CVSS 3.1 score of 10.0. Note what the ADP container does not have: a KEV block. Vulnrichment adds one to every CVE in the CISA KEV catalog, and the xz backdoor is not in it.

Coverage is the weak link. Vulnrichment assesses new and recent CVEs, so most older records carry no SSVC data at all. The gap matters more now that NIST has stopped routinely enriching most CVEs, as of April 2026, which leaves CISA's ADP as the main federal source of post-publication analysis.

BOD 26-04 uses an SSVC decision table with four yes-or-no inputs to set a remediation deadline for every vulnerability on a federal civilian system. CISA issued the directive on June 10, 2026. It revokes BOD 22-01, the 2021 directive behind the original KEV deadlines. CERT/CC published the table as an SSVC object the next day, in SSVC v2026.6.

The four inputs:

• In KEV: is the CVE in CISA's Known Exploited Vulnerabilities catalog?
• Publicly Exposed: is the asset accessible to unauthenticated or untrusted entities via public networks? This is the only input about the asset rather than the vulnerability.
• Automatable: the standard SSVC decision point.
• Technical Impact: the standard SSVC decision point.

The figure lays out all 16 rows of CERT/CC's cisa_bod_26_04_1_0_0.csv. The same data:

Read the table, not the summaries. Several write-ups describe the forensic tier as any KEV entry with total impact. That is wrong. A KEV vulnerability with total impact on an asset that is neither exposed nor automatable gets 14 days. Forensic investigation requires In KEV, total impact, and at least one of exposure or automation. The lowest tier is just as specific: a vulnerability that is not in KEV, not exposed, and not automatable waits for the next system upgrade even when its technical impact is total.

Compared with CISA's 2022 table, BOD 26-04 dropped two inputs. Three-level Exploitation became binary In KEV, so a public proof of concept no longer changes anything. Mission and Well-being, the most subjective input, was replaced by Publicly Exposed, a fact an asset inventory can answer. Every input is now either published per CVE by CISA or known to the asset owner.

Run the xz backdoor through both tables. Its published values are Exploitation none, Automatable yes, and Technical Impact total, and it is not in KEV:

The deadlines reach beyond agencies. FedRAMP requires cloud providers to adopt vulnerability rules that meet "the timelines, prioritization requirements, and approach set out in BOD 26-04," effective December 7, 2026.

SSVC values published for an open source library describe the library in general, not your application. CISA's coordinator answers "can an attacker automate exploitation?" for every deployment at once. For a library, the honest answer often depends on how the calling code uses it.

CVE-2025-29927, the Next.js middleware bypass, shows the gap. Vulnrichment rates it Exploitation none, Automatable yes, Technical Impact total, which is reasonable for the worst case. The CVE description says an attacker can bypass authorization only "if the authorization check occurs in middleware." Self-hosted apps that enforce auth in middleware were exposed to a one-header bypass. Apps hosted on Vercel or Netlify, static exports, and apps that check authorization elsewhere were not. Every one of those apps inherits the same three SSVC values.

SSVC's deployer table has a decision point for this, System Exposure, defined by CERT/CC as "The Accessible Attack Surface of the Affected System or Service." For a network appliance, exposure is a firewall question. For a vulnerable function inside a dependency, the attack surface is whether any path in your code reaches that function. That is what reachability analysis computes.

SSVC is built to be extended. CERT/CC encourages organizations to define their own decision points, and a "vulnerable code reachable" input slots in naturally: unreachable findings drop toward Track or Defer, and reachable ones keep the published values. The cost is a call-graph analysis per application, and the result is only as good as that analysis. Socket's reachability engine over-approximates on purpose, marking a finding reachable or unknown when it cannot prove there is no path. In Socket's Tier 1 Reachability launch, full application analysis typically marked about 80% of CVE findings unreachable. Socket's security policy rules can match on both a CISA KEV true or false field and a reachability field, so the In KEV and reachable inputs can be enforced as policy.

One caveat for federal teams. BOD 26-04 asks whether the asset is publicly exposed, not whether the vulnerable code path is reachable. Reachability can shrink a commercial team's queue, but it does not change a federal deadline.

SSVC only categorizes vulnerabilities that have a CVE, and most supply chain attacks never get one. Vulnrichment enriches CVE records. BOD 26-04 keys on CVEs and KEV entries. A typosquat or a purpose-built malicious package on npm or PyPI usually never enters the Common Vulnerabilities and Exposures (CVE) system, so no SSVC table ever sees it.

The rare malicious package that does get a CVE does not fit the decision points either. SSVC's decision points describe flaws: mistakes that any attacker can find and exploit once they are known. A backdoor is a capability its author holds. The xz backdoor accepted commands only in an SSH certificate payload that, according to the xzbot analysis, "must be encrypted and signed with the attacker's ED448 key." No one else could trigger it. CISA's values, Exploitation none and Automatable yes, are each defensible on their own. Together they describe a severe bug that nobody has used yet. That is the wrong model for code planted by an adversary who can use it at will.

A malicious npm package is even further outside the model. Its payload usually runs during installation, through the same lifecycle scripts any legitimate package can use. There is no flaw to reach, no exploit to automate, and no exposed asset to measure. The right outcome is always "block the install and rotate what it could touch," and that answer has to come from analyzing what the package actually does, before it runs.

SSVC settled the argument about whether vulnerability triage should be a decision or a score. The open problem is the input layer. Its decision points assume a public CVE, a CISA analyst, and a fact like "exploited in the wild" that stays true long enough to schedule a patch. Open source attacks now move in minutes to hours, through code that was never a vulnerability in the first place.