SSVC, short for Stakeholder-Specific Vulnerability Categorization, prioritizes vulnerabilities by walking you through a short decision tree instead of calculating a score. If your organization applies patches, the tree asks four questions. Is the vulnerability being exploited? How exposed is the affected system? What would a compromise do to your mission? Could it harm anyone's safety? The answers lead straight to an action: Defer, Scheduled, Out-of-Band or Immediate. Researchers at Carnegie Mellon University's Software Engineering Institute (SEI) proposed it in November 2019 as an alternative to prioritizing by CVSS score alone.
This post explains the decision points, the outcomes and the separate tree for software developers. It then works through an example and compares SSVC with CVSS-only prioritization.
What is SSVC?
SSVC comes from the SEI paper Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization, by Jonathan Spring, Eric Hatleback, Allen Householder, Art Manion and Deana Shick. The SEI is home to the CERT Coordination Center, which has spent decades coordinating vulnerability disclosure.
"Stakeholder-specific" is the key idea. The organization that writes a fix and the organization that installs it face different decisions, so SSVC gives each its own tree. The paper defines two: one for patch developers and one for patch appliers. A tree for coordinators was left for future work.
The authors are candid about maturity. They describe the proposal as "a detailed hypothesis to test or a conversation starter; it is not a final proposal," and they invite others to test and improve it. Treat it as a well-reasoned framework to adapt, not a finished standard.
Why not just prioritize by CVSS score?
CVSS describes the technical severity of a vulnerability. It doesn't tell you what to do, and the SSVC paper raises three specific concerns about using it alone.
- False precision. CVSS, in the paper's words, appears to say that "4.6 is more severe than 4.5." The authors note that CVSS was designed to be accurate only within ±0.5 and that, in practice, it is scored with errors of around ±1.5 to 2.5. An error that size can move a vulnerability across a severity boundary.
- Missing context. The CVSS Base score, which is what most people use, leaves out whether anyone is exploiting the flaw, how exposed your system is and how much the system matters. CVSS treats those factors as optional extras, while in SSVC they sit at the center of the decision.
- A number isn't a decision. Most teams using CVSS end up mapping score bands to actions. SSVC skips the intermediate number and produces the action directly.
What are the decision points for patch appliers?
If you run IT or security operations, the patch applier tree is the one you'll use. It has four decision points, and exploitation comes first.
Exploitation
This decision point records the current state of exploitation. It doesn't try to predict the future.
| Value | Meaning |
|---|---|
| None | No evidence of active exploitation and no public proof of concept |
| PoC | Proof of concept: private evidence of exploitation that isn't shared, widespread hearsay, public exploit code, or a well-known exploitation method |
| Active | Shared, observable, reliable evidence that attackers are using the exploit in the wild, with credible public reporting |
Exposure
Exposure describes the accessible attack surface of the affected system in your environment.
| Value | Meaning |
|---|---|
| Small | Local service or program, or a highly controlled network |
| Controlled | Networked service with some access restrictions or mitigations already in place |
| Unavoidable | Internet or another widely accessible network where access can't plausibly be restricted |
Mitigations can change this answer. If you can't patch yet but can restrict access to the vulnerable service, you may move from Unavoidable to Controlled and lower the priority. The paper counts that as a legitimate success.
Mission impact
Mission impact asks what a compromise would do to your organization's mission essential functions (MEFs), the functions you must keep performing even during a disruption. The values are None, Non-Essential Degraded, MEF Support Crippled, MEF Failure and Mission Failure.
If you have business continuity plans, you've probably identified these functions already. The answer depends mostly on the system rather than the specific vulnerability, so you can work it out in advance and reuse it.
Safety impact
Safety impact covers harm to people, taken in a broad sense. Alongside physical harm, the paper includes financial, psychological and environmental effects, and effects on system operators. The values are None, Minor, Major, Hazardous and Catastrophic.
For most office IT, the answer will usually be None or Minor. It matters a great deal for systems that support healthcare, industrial processes or anything cyber-physical.
What do the four outcomes mean?
Every path through the tree ends in one of four priorities. The paper defines them for patch appliers as follows:
| Outcome | What you do |
|---|---|
| Defer | Do not act at present |
| Scheduled | Act during regularly scheduled maintenance time |
| Out-of-Band | Act more quickly than usual to apply the fix out-of-band, during the next available opportunity, working overtime if necessary |
| Immediate | Act immediately, focusing all resources on applying the fix as quickly as possible, including pausing regular operations if necessary |
Each outcome is a class, not a rank. If three vulnerabilities all land in Scheduled, the paper treats them as equal priority, and you can order them by other factors such as the cost or disruption of patching.
What about the patch developer tree?
Software vendors and in-house development teams use a separate tree for deciding how urgently to build a fix. It shares Exploitation and Safety Impact with the applier tree and adds two decision points of its own:
- Technical impact: Partial (limited control or information exposure) or Total (full control of the software or disclosure of all information on the system).
- Utility: how useful the vulnerability is to an attacker, rated Laborious, Efficient or Super Effective. It combines virulence (whether the attack steps can be reliably automated) with value density (whether the target system holds concentrated or diffuse resources).
The outcomes carry the same four names but describe development work, from deferring the fix to drawing on all available resources to release one. The paper suggests developers publish the priority they assigned. If a vendor rates one fix Out-of-Band and two others Scheduled, you could use that to break ties within your own Scheduled queue.
A worked example
Suppose a remote code execution vulnerability is disclosed in a web application platform you run. It carries a CVSS v3.1 Base score of 9.8 (Critical). You run the platform in two places:
- A customer portal on the internet. If it were compromised, activities that directly support a core business function would be crippled.
- An internal reporting server that sits behind network access controls. A compromise would degrade a non-essential function.
Neither system has a safety impact. Here is how the applier tree handles them, first on disclosure day and again after credible reports of active exploitation appear:
| System and timing | Exploitation | Exposure | Mission impact | Safety impact | SSVC outcome |
|---|---|---|---|---|---|
| Portal, at disclosure | None | Unavoidable | MEF Support Crippled | None | Scheduled |
| Reporting server, at disclosure | None | Controlled | Non-Essential Degraded | None | Defer |
| Portal, active exploitation | Active | Unavoidable | MEF Support Crippled | None | Out-of-Band |
| Reporting server, active exploitation | Active | Controlled | Non-Essential Degraded | None | Scheduled |
CVSS rates both systems 9.8 at every stage. SSVC separates them by exposure and mission, and it escalates both when exploitation evidence changes. If the portal were your main revenue channel and a compromise meant MEF Failure, the tree would return Immediate once active exploitation was confirmed.
The Defer on day one might feel uncomfortable for a Critical vulnerability. Defer doesn't mean ignore: it means you don't act yet, and you revisit the decision when the facts change. The tree also makes your assumptions visible. If you disagree with a branch, you can change it deliberately and document why.
How does SSVC compare with CVSS-only prioritization?
| CVSS-only | SSVC (patch applier tree) | |
|---|---|---|
| Output | A score from 0.0 to 10.0 | One of four actions |
| Main inputs | Technical characteristics of the flaw | Exploitation, exposure, mission and safety impact |
| Your environment | Optional Environmental metrics | Built into every decision |
| Over time | Base score is fixed | Re-evaluate as exploitation evidence changes |
| Explaining a decision | Formula and vector string | A readable path through the tree |
| Effort | Scores are published for you | You need asset and mission knowledge |
The two aren't mutually exclusive. The CVSS vector still helps you understand a vulnerability's mechanics, and it can inform the Exposure answer.
How can you start using SSVC?
- Do the reusable work first. Record exposure and mission impact for each system or system group. That needs an asset inventory, an understanding of your network layout and input from the people who own business continuity planning.
- Define your exploitation evidence. Decide which sources of exploit code and exploitation reports you'll check, and how often you'll recheck open items.
- Use conservative defaults when you don't know. SSVC deliberately has no "unknown" value. The paper suggests assuming Unavoidable exposure, MEF Support Crippled mission impact and Major safety impact until you have evidence otherwise.
- Map outcomes to your processes. Agree what Scheduled and Out-of-Band mean in days and maintenance windows for your organization.
- Run it alongside your current method. Score a month or two of vulnerabilities both ways and review where the results differ. The disagreements will show you where to adjust.
Frequently asked questions
Does SSVC replace CVSS?
Not necessarily. SSVC replaces the step where you turn a CVSS score into a priority. You can keep reading CVSS vectors to understand how a vulnerability works.
Is SSVC ready for production use?
Its authors say they don't claim it is ready as-is and describe it as a proposal to test and refine. Many teams will still find the decision points useful as a structured, explainable way to triage, provided they adapt the trees to their own risk appetite.
What if we can't answer one of the questions?
Use the defaults the paper suggests: Unavoidable exposure, MEF Support Crippled mission impact and Major safety impact. With no evidence of exploitation, that combination produces a Scheduled outcome. Refine the answers as your asset and mission data improves.
Key takeaways
- SSVC replaces a severity score with a decision: Defer, Scheduled, Out-of-Band or Immediate.
- The patch applier tree uses four decision points: Exploitation, Exposure, Mission Impact and Safety Impact.
- A separate patch developer tree helps vendors decide how urgently to build fixes.
- Most of the effort goes into knowing your exposure and mission impact, and that work is reusable across vulnerabilities.
- The framework is an explicit proposal from its authors. Pilot it, compare it with your current approach and adapt the branches that don't fit.