Prioritising Vulnerabilities With SSVC: Decisions Before Scores
Security teams face a problem that severity scores alone cannot solve: on any given week there are more vulnerabilities than there is time to fix, and a single number cannot say which ones to fix first. A vulnerability with a high severity score in a system nobody can reach may matter less than a medium vulnerability in a system that is exposed to the internet and already being exploited. SSVC, short for Stakeholder-Specific Vulnerability Categorization, addresses this by turning prioritisation into a decision process. Instead of asking how bad a vulnerability is in the abstract, it asks a sequence of concrete questions about the specific situation, and the answers lead to a priority decision. The SSVC Decision Calculator walks through those questions with values you supply, so a team can reach a consistent, explainable decision for each vulnerability.
SSVC was developed by the Carnegie Mellon Software Engineering Institute, and its central idea is that prioritisation depends on the stakeholder. A software supplier, a deployer, and a coordinator may reasonably reach different decisions about the same vulnerability, because they face different risks and control different remedies. A supplier decides whether to publish a fix. A deployer decides whether to apply it urgently. A coordinator decides whether to alert a community. Each role uses its own decision tree, but all trees share the same style: a small set of decision points, each with a few defined values, leading to one of four outcomes, typically track, track with extra attention, attend to promptly, or act immediately. The outcome is a scheduling decision, not a measure of technical severity, and that distinction is the point.
How it works
A decision calculator works by asking the decision points in order and combining the answers. The most influential point is usually exploitation status: is the vulnerability actively exploited, is there a public proof of concept, or is there no known exploitation? Active exploitation pushes priority sharply upward, because the threat is no longer theoretical. The next points concern exposure and impact. Is the affected system reachable from the internet, or only from an internal network? Would exploitation affect safety, mission-critical functions, or only convenience? Is a fix available, and how disruptive is applying it? Each answer narrows the outcome, and the tree is designed so that the same answers always give the same outcome, which makes decisions consistent across team members and across weeks.
The calculator's value lies less in arithmetic than in discipline. Without a tree, prioritisation drifts with whoever shouts loudest, with the newest headline, or with the highest severity number, even when that number describes a scenario unlike your own. With a tree, a team can explain a decision afterwards: this vulnerability was scheduled for immediate action because it is actively exploited and the affected system is internet-facing, while that one was scheduled for routine tracking because no exploitation is known and the system is internal. That explanation matters for audits, for management reporting, and for the next team member who inherits the queue, because a decision without a reason cannot be reviewed or improved.
Worked example
Consider two vulnerabilities with sample values for illustration. Vulnerability A has a high severity score, but no known exploitation, no public proof of concept, and it affects an internal reporting tool that is not reachable from the internet. Its impact if exploited would be limited to that tool's data. Walking the decision tree, the answers are: exploitation, none known; exposure, internal only; impact, limited. The outcome is routine tracking, with a fix applied in the normal patch cycle. Vulnerability B has a medium severity score, but it is actively exploited, it affects a public-facing web server, and exploitation would disrupt a customer-facing service. Its answers are: exploitation, active; exposure, internet-facing; impact, mission disruption. The outcome is immediate action, ahead of Vulnerability A, despite the lower severity score.
That reversal is the lesson of the example. A severity score describes a vulnerability's technical properties in a generic scenario, while SSVC describes its priority in your scenario, and the two can disagree. A team that patches strictly by severity would fix A first and leave B exposed while it worked, which is exactly the wrong order. A team that uses the decision tree fixes B first, schedules A normally, and can explain both decisions in one sentence each. The sample values are invented for illustration, but the pattern is common in real queues, where a handful of actively exploited, internet-facing issues deserve immediate attention regardless of their scores, and a long tail of high-scoring internal issues can safely wait for the normal cycle.
Mistakes to avoid
The most common mistake is treating the SSVC outcome as a severity score and comparing it across organisations as if it were universal. An outcome is specific to the stakeholder and the situation that produced it, so the same vulnerability can legitimately yield different outcomes for a supplier and a deployer, and neither is wrong. A second mistake is answering decision points with guesses instead of evidence. Exploitation status in particular must be based on reliable reporting, not on rumour, because marking everything as actively exploited collapses the tree: if everything is urgent, nothing is, and the prioritisation value is lost. A third mistake is using the calculator once and filing the result away. Exploitation status changes, systems move from internal to internet-facing, and fixes become available, so decisions should be revisited when the facts change, not frozen at first assessment.
A fourth mistake is ignoring the fix side of the decision. A vulnerability with no available fix cannot be patched no matter how urgent it is, and the decision then becomes about mitigation, such as restricting access, adding monitoring, or isolating the system, rather than about patching speed. The tree accounts for this, but only if the team answers honestly about fix availability. Finally, the handling rule for vulnerability work: decision inputs are usually not secret, but details of unpatched vulnerabilities in your own systems can be sensitive, because they describe weaknesses an attacker could use. Share decision outcomes and reasoning within the team, but do not paste internal network details, credentials, or exploit code into external tools that do not need them.
Putting it into practice
Adopt SSVC for the weekly vulnerability queue: for each new vulnerability, record the decision-point answers, the outcome, and the date, and review outcomes when exploitation status or exposure changes. Start with the deployer tree if you run systems, since that is the role most teams occupy, and use the outcomes to order the patch schedule, not to replace it. For neighbouring tools, the Threat Intelligence Report Builder helps organise the reporting that feeds exploitation assessments, and the Multi-Format Log Parser helps examine the logs that show whether an attack is actually occurring. For background reading, the related guide surveys security tools generally, which helps place a decision calculator among the scanners and monitors that feed it information.
Key points
- SSVC prioritises by stakeholder situation, not by abstract severity alone
- Exploitation status, exposure, and impact together determine the decision outcome
- The same vulnerability can legitimately yield different outcomes for different stakeholders
- Record the answers behind each decision, and revisit decisions when the facts change