Stakeholder-Specific Vulnerability Categorization (SSVC) Explained

Each year, tens of thousands of new vulnerabilities are disclosed. And yet, most security teams are forced to rely on legacy scores like CVSS or limited probabilistic models like EPSS to decide what to fix first. These models tell us how bad a vulnerability might be, or how likely it is to be exploited, but they don’t tell us what we should do about it.

That’s where Stakeholder-Specific Vulnerability Categorization (SSVC) comes in. Created by the Carnegie Mellon University SEI and CISA, SSVC introduces a decision-making framework based not on theoretical severity, but on mission impact, exploit status, and the stakeholder’s role. It’s not another risk score, it’s a tailored decision tree designed to help each organization take the right action, at the right time.

Instead of treating every critical CVE the same, SSVC asks:

• How important is the affected asset to your organization?
• Is the vulnerability actively exploited?
• Do you have compensating controls in place?
• And based on all this, should you fix now, schedule later, or watch and wait?

This blog explores how SSVC works, presents a real-life CVE case study, highlights its benefits for organizations, examines its limitations, and explains how it can be complemented by other prioritization tools and metrics.

Why Existing Scoring Models Fall Short

Traditional risk scoring systems like CVSS are asset-agnostic. A CVE on a public-facing server gets the same score as one on a sandbox VM. While useful for gauging theoretical severity, these scores lack operational context.

EPSS improves this by estimating short-term exploitation probability. But even EPSS doesn’t account for whether the vulnerable asset is critical, or if the vulnerability is already mitigated by controls.

As a result, security teams are overwhelmed with "critical" vulnerabilities, many of which don’t merit urgent action. They waste time chasing low-risk findings and struggle to justify deprioritization.

SSVC changes this. It replaces “one-size-fits-all” prioritization with a structured decision model rooted in stakeholder needs, mission impact, and real-world context.

What Is SSVC and How Does It Work?

Stakeholder-Specific Vulnerability Categorization (SSVC) is a structured decision-tree model developed to help organizations prioritize vulnerability remediation based on context, mission impact, and real-world exploitation status. 

SSVC Decision Outcomes: Act, Attend, Track*, Track

Unlike traditional vulnerability scoring systems like CVSS, which assign numerical severity values (e.g., 7.5 or 10.0), SSVC delivers qualitative outcomes based on real-world context and organizational priorities. These outcomes guide how urgently a vulnerability should be addressed.

SSVC defines four possible outcomes.

• Act: Take immediate coordinated action. This is the highest priority. It’s reserved for vulnerabilities with active exploitation, high impact, and strong mission relevance.

• Attend: Remediate sooner than your normal patching cycle. This indicates elevated concern but not emergency-level response.

• Track*: Monitor the vulnerability closely. Its status or context may change, potentially increasing risk.

• Track: Continue routine monitoring and remediation on a standard timeline. No exceptional action is currently needed.

These outcomes are the result of evaluating key decision factors such as exploitation status, technical impact, automobility, and asset relevance. The goal is to move beyond generic scores and deliver clear, defensible action paths for each stakeholder.

SSVC Models: Vendor vs. Deployer

CISA’s implementation of SSVC includes two primary models:

• Vendor Model – Used by software and hardware vendors to decide whether and how to publish advisories or create patches.

• Deployer Model – Designed for asset owners and operators (such as U.S. government agencies, SLTTs, and critical infrastructure organizations) to inform remediation priorities based on their operational environment.

This blog focuses on the Deployer Model, which enables defenders to make stakeholder-aligned, evidence-based decisions, helping reduce noise, avoid over-prioritization, and focus efforts where exploitation poses the greatest risk

Breaking Down the SSVC Deployer Decision Tree

The Deployer SSVC model guides vulnerability response using a structured decision tree. Each decision point evaluates a different contextual factor related to the vulnerability, helping organizations make consistent and risk-informed prioritization choices.

CISA’s Deployer model includes the following key decision points:

(State of) Exploitation: Is this vulnerability being used in the wild?

Assesses whether there’s real-world evidence of exploitation.

None: No public exploitation or PoC.

• Example: CVE-2024-35951 (Windows Kernel Elevation of Privilege) was disclosed but hasn’t been weaponized or seen in threat reports yet.

Public PoC: Exploit code exists in platforms like GitHub or hacker forums.

• Example: CVE-2024-4577 (PHP CGI Argument Injection) had a working PoC released on GitHub within hours of disclosure.

Active: Reliable confirmation of exploitation in the wild.

• Example: CVE-2024-3400 (Palo Alto PAN-OS command injection) was actively exploited by APT groups like UTA0178 within days of disclosure, leading to CISA KEV inclusion.

Source Types: Vendor advisories, NVD, ISAC bulletins, threat intel reports

Technical Impact: What happens if the vulnerability is exploited?

Measures the outcome if exploited:

Partial: Limited access, e.g., DoS or local file read.

• Example: CVE-2023-4863 (Chrome WebP heap buffer overflow) can crash the browser but needs chaining for broader impact.

Total: Full takeover or unrestricted access.

• Example: CVE-2024-3400 allows unauthenticated attackers to execute arbitrary code as root on vulnerable firewalls, complete compromise of perimeter defenses.

Automotable: Can attackers exploit this at scale?

Can the attack be reliably executed at scale without human intervention?

Yes: Suitable for scripting or worms; widely exposed services with RCE.

• Example: CVE-2024-20353 (Cisco ASA/FTD) enabled automated exploitation using a single HTTP request, making it ideal for botnet deployment.

No: Requires chaining, manual reconnaissance, or authenticated access.

• Example: CVE-2025-22457 (Ivanti Connect Secure) required a session hijack chain and custom payloads, not readily automatable out-of-the-box.

This dimension evaluates the ease of scaling the attack across environments.

Mission Prevalence: Does this vulnerability affect a mission-critical asset?

Is the vulnerable asset directly tied to critical operations?

Minimal: Not tied to MEFs.

• Example: A vulnerability in a print server for internal comms in a non-critical office setting.

Support: Enables critical ops but isn't central.

• Example: Authentication server for HR systems used across a national agency.

Essential: Directly supports mission-critical infrastructure.

• Example: Firewall appliances exposed to the internet at healthcare or energy facilities using vulnerable PAN-OS (CVE-2024-3400).

Public Well-Being Impact: Could exploitation harm public safety or services?

Assesses real-world human harm, not just IT risk:

Minimal: Limited to digital consequences.

• Example: Exposure of internal metrics dashboard credentials.

Material: May disrupt public services or cause financial losses.

• Example: CVE-2024-1708 (ConnectWise ScreenConnect) was used by ransomware groups to gain access to MSP environments, causing downstream business disruption.

Irreversible: Threatens lives, safety, or systemic collapse.

• Example: Vulnerability in hospital infusion pumps allowing remote tampering with medication delivery, or ICS vulnerabilities affecting water treatment facilities.

Case Study: SSVC Evaluation of Ivanti CVE-2025-22457

CVE-2025-22457 is an authentication bypass vulnerability affecting Ivanti Connect Secure and Policy Secure gateways. Attackers exploited it in the wild shortly after public disclosure, often in conjunction with another Ivanti RCE (CVE-2025-21834). It enabled unauthorized remote access and was widely used in espionage campaigns.

(State of) Exploitation

Active – This CVE was exploited in the wild by APT actors and added to the KEV list by CISA shortly after discovery.

Technical Impact

Total – The bypass allowed unauthenticated remote access to administrative interfaces and chained with RCEs for full takeover.

Equivalent to privilege escalation + remote code execution.

Automatable

No – While exploitation was reliable, it required session hijack setup, custom payloads, and was not fully wormable out-of-the-box.

Chaining required, limiting scale.

Mission Prevalence

Support – Ivanti gateways are widely used in the U.S. SLTT government networks and critical sectors but aren’t MEFs themselves.

Supports secure access, not direct mission execution.

Public Well-Being Impact

Material – Used in espionage and supply chain targeting of MSPs and government entities, risking disruption of sensitive access but not lives.

Could result in data breaches or operational delays.

Final SSVC Decision: Attend

Per the decision matrix on page 10 of the CISA SSVC Guide, an active, non-automatable, total impact vulnerability affecting systems with support-level mission prevalence and material public impact maps to an Attend decision.

How SSVC Enhances Communication Between Security and Stakeholders

SSVC isn’t just a better prioritization model, it’s a better communication model. It gives CISOs, vulnerability managers, and SOC teams a shared decision framework that is:

• Tailored – SSVC reflects your actual environment and business impact.

• Transparent – Each decision is traceable through clearly defined logic.

• Actionable – It doesn’t just rate vulnerabilities; it recommends what to do next.

• Defensible – Regulators and auditors want to see rationale. SSVC provides it.

This clarity helps reduce friction between technical teams and executive stakeholders, and bridges the gap between detection and decision.

SSVC in the Modern Risk Prioritization Stack

SSVC is not designed to replace CVSS, EPSS, or asset criticality tagging. It complements them by introducing a structured prioritization lens on top of technical severity and exploitation likelihood.

A modern prioritization workflow might look like this:

• Use CVSS for severity

• Use EPSS for likelihood

• Use Asset Tags for business context

• Use SSVC for stakeholder-aware decision-making

Better yet, combine SSVC with validation platforms like Picus Exposure Validation to not only prioritize based on risk, but prove exploitability via real-world simulation.

The Limits of SSVC: Where Logic Falls Short

While SSVC offers a structured and context-aware approach to vulnerability response, it has several inherent limitations:

Subjective Decision-Making

SSVC relies heavily on human judgment at each decision point—such as determining whether a vulnerability affects a mission-essential function or whether it’s automatable.

Without well-defined internal standards, this can lead to:

• Inconsistent prioritization between analysts

• Biased or incomplete assessments

• Difficulty scaling decisions across large teams

Subjectivity weakens reliability, especially in fast-moving environments.

No Native Integration with Security Controls

SSVC does not account for whether your current security tools, like EDRs, firewalls, or SIEMs, successfully detect or prevent the exploit attempts being evaluated.

It focuses only on:

• Potential impact of exploitation

• Known external threat data

But it lacks awareness of actual control performance, which limits its real-world precision.

Static and Manual

Applying for SSVC is a manual process. Analysts must walk through the decision tree for each vulnerability. In large environments with tens of thousands of CVEs, this becomes unscalable unless paired with automation.

Other downsides include:

• No automatic updates from new threat intelligence

• No integration with real-time control telemetry

• High time cost for vulnerability teams

No Evidence-Based Validation

SSVC evaluates risk using logical trees and qualitative context, but it doesn’t test exploitability in practice.

There’s no:

• Simulated attack behavior

• Empirical evidence from your environment

• Feedback loop from control testing

This means organizations still rely on assumptions rather than proof.

Limited Visibility into False Positives and Negatives

Because SSVC doesn’t simulate real-world attacks, it can’t reliably detect:

• False positives: CVEs that look risky but are blocked or irrelevant in your setup

• False negatives: CVEs that appear low-risk but are actually exploitable due to gaps in visibility or control coverage

This reduces trust in the model’s output and leaves security teams exposed to blind spots.

How Picus Exposure Score (PXS) Fills the Gaps

Picus Exposure Score (PXS) is built to complement and surpass traditional models like SSVC by introducing evidence-based validation into the prioritization process.

PXS vs. SSVC: A Side-by-Side Comparison

From Prioritization to Proof

Modern vulnerability prioritization models like SSVC have taken important steps to reduce noise by introducing stakeholder-aware logic. Instead of assigning abstract severity ratings, SSVC encourages action based on mission impact, exploitation status, and operational relevance.

But even SSVC has its limits. It relies on subjective inputs, lacks integration with real-time control telemetry, and doesn't validate whether a vulnerability is actually exploitable in your environment.

That’s where the Picus Exposure Score (PXS) fills the gap.

PXS goes beyond policy-driven prioritization. It delivers empirical, continuously updated, control-aware validation—proving which vulnerabilities are exploitable in practice, not just in theory. While SSVC tells you what to do based on context, PXS justifies why based on evidence.

Used together, SSVC and PXS create a powerful, layered decision-making framework:

• SSVC helps structure internal conversations and align remediation with stakeholder priorities.

• PXS ensures those decisions are backed by technical proof, not assumptions.

In a world of expanding attack surfaces and shrinking resources, this combination brings both clarity and confidence to vulnerability management.

Because at the end of the day, real risk isn’t what a score says, it’s what an attacker can do. PXS makes sure you know the difference.