SSVC Explained: CISA's Decision Tree for Patch Prioritization

A score is the wrong output type for a prioritisation system.

Every number needs a threshold. Every threshold is a policy. Almost nobody writes that policy down, so the number quietly becomes the policy, and a decision that should have been made deliberately by your team gets made accidentally by whoever calibrated a scoring formula for a different organisation.

SSVC inverts this. The policy is the artefact, and the output is a verb.

What SSVC Is and Where It Came From

SSVC stands for Stakeholder-Specific Vulnerability Categorization. It was developed at the CERT Coordination Center at Carnegie Mellon's Software Engineering Institute, and adapted by CISA into a coordinator decision tree that CISA uses for its own triage and publishes for everyone else.

Both sources are worth reading directly: the CERT/CC documentation for the theory and the tree-building method, and CISA's SSVC page for the concrete tree and its calculator.

How SSVC Differs From CVSS in One Sentence

CVSS produces a number that you must then interpret; SSVC produces a decision that you have already agreed to in advance.

Everything else is detail. The argument still happens, but it happens once, when you build the tree, in a room with the right people, rather than every Tuesday in a triage meeting.

Decision Point 1: Exploitation

The first question is the strongest signal available, and it has three values:

• none: no evidence of exploitation and no public proof of concept.
• public proof of concept: working exploit code is publicly available, or the method is well known and reliably reproducible.
• active: reliable evidence of exploitation in the wild.

Membership in the CISA KEV catalog is the clearest available evidence for active. A public PoC is a genuinely weaker and distinct signal: plenty of vulnerabilities have exploit code on GitHub and no observed attacks, and conflating the two is how teams end up firing emergency change control at research artefacts.

Decision Point 2: Automatable, the Question Nobody Else Asks

Automatable asks whether an attacker can reliably automate steps one to four of the kill chain, meaning reconnaissance, weaponisation, delivery and exploitation, across many targets.

This is the decision point with no CVSS 3.1 equivalent, and it is the one that best predicts whether you will read about the vulnerability in the news. A flaw that someone must hand-drive against one target at a time is a different operational problem from a flaw that gets mass-scanned by a botnet within 48 hours, even when the two have identical technical impact.

Worth noting: CVSS 4.0 added Automatable as a supplemental metric, which is the same idea arriving from the other direction. If your provider populates it, you can feed it straight into this decision point.

Decision Point 3: Technical Impact

Deliberately coarse, with two values:

• partial: the attacker gains limited control, or limited information disclosure, or can cause a limited denial of service.
• total: the attacker gains full control of the vulnerable component, or can render it completely unavailable.

Two values, not ten. The coarseness is intentional. Fine-grained impact scoring is where CVSS spends most of its complexity budget, and SSVC's position is that the extra resolution rarely changes what you do this week.

Decision Point 4: Mission and Well-Being Impact

This combines mission prevalence, how essential the affected system is to your organisation's function, with public well-being impact, the potential for physical, environmental, financial or psychological harm to people. The combined value is low, medium or high.

This is the stakeholder-specific part, and it is the reason the same CVE legitimately produces different decisions at a hospital and at a photo-sharing app.

The Four Outcomes: Track, Track*, Attend, Act

The asterisk in Track* is not decoration. It means you have committed to a specific condition, usually a change in the Exploitation value, that automatically promotes the item. Without that trigger written down, Track* is just Track with extra steps.

Where CVSS, EPSS and KEV Feed the Tree Rather Than Compete With It

The framing that SSVC "replaces" CVSS is the most common misreading, and it makes SSVC sound like a competing standard when it is a consumer of the others.

• CVSS supplies Technical Impact. The vector's impact metrics map onto partial versus total more or less directly.
• KEV supplies the strongest evidence for Exploitation equals active.
• EPSS supplies a probability that helps you decide between none and public proof of concept when direct evidence is thin, and it is the right tiebreaker for a large backlog.
• You supply Mission and Well-Being, which nobody else can.

We set out the division of labour between severity and likelihood in CVSS vs EPSS; SSVC is the layer that sits on top and turns those inputs into an action. Combining severity, exploitation and probability into a single ordering is what our risk scoring does automatically, and you can inspect the resulting order across the whole corpus in the CVE screener.

Forking the Tree for a Ten-Person Engineering Team

CISA's coordinator tree is built for a coordinator's job, which is not your job. SSVC is explicitly designed to be forked, and a small team should fork it aggressively.

Here is a four-question tree that works for a product engineering team with no dedicated security function. Replace the abstract Mission and Well-Being point with something your engineers can answer without a meeting:

Q1. Is it being exploited? KEV listing, or a credible vendor statement, or your own telemetry. Yes leads to Q3. No leads to Q2.

Q2. Is there public exploit code? Yes leads to Q3. No leads to Track, unless technical impact is total and the asset is internet-facing, in which case Track*.

Q3. Is the affected system internet-facing, or does it hold customer data? This single question replaces mission prevalence and well-being impact, and a small team can answer it from its own asset list in seconds. Yes leads to Q4. No leads to Attend.

Q4. Can an attacker automate it at scale? Mass-scannable, unauthenticated, no unusual preconditions. Yes leads to Act. No leads to Attend.

Four questions, one afternoon to agree, and every future disagreement about a CVE becomes a lookup rather than a debate. Write the examples down beside each question, because that is what makes two different engineers reach the same answer.

Mapping SSVC Outcomes Onto Patch SLAs

A decision without a deadline is still not a policy. The final step is to bind each outcome to a number of days, and if you have already adopted the four-tier framework in our patch management strategy, the mapping is one to one:

Now the two artefacts compose: the tree decides, the SLA schedules, and neither requires a fresh argument.

When SSVC Is the Wrong Tool

Three honest limits.

A decision tree is only as good as its inputs. If your Exploitation value is stale because nobody is watching KEV, the tree will confidently return Track for something that is being actively exploited. Automating the input is more valuable than refining the tree.

Mission and Well-Being is a judgement call. Two reasonable engineers will disagree unless you write down worked examples for each value. This is the single largest source of inconsistency in practice, and it is entirely fixable with a paragraph of examples per level.

It does not scale to an unfiltered firehose. SSVC is a triage instrument, not a filter. If thousands of irrelevant CVEs are reaching the tree, the problem is upstream: you need applicability matching against your actual stack before triage, not a better decision procedure after it.

Fix the inputs, fork the tree, bind the outcomes to deadlines. Then stop scoring things and start deciding them.