It’s Patch Tuesday.
Your software scanners light up with almost 70 percent more vulnerabilities than last month, and by Friday you’re expected to explain, clearly and defensibly, which ones matter, which ones wait, and which ones could put the organization at real risk if ignored. Your teams are already stretched, new AI-enabled software is landing faster than it can be inventoried, and every dashboard insists its prioritization should come first.
Even if you manage to get through this week, the question remains: how do you make vulnerability prioritization sustainable when volume keeps growing, software keeps changing, and risk tolerance is not the same for every system considering the diverse stakeholders.
This is not just hypothetical, in October 2025, Microsoft released fixes for 167 vulnerabilities on a single Patch Tuesday. As Tenable noted in a recent blog post
- Microsoft alone patched more than 1,100 vulnerabilities for the second consecutive year, nearing 2020’s record.
- The year 2025 saw two record-breaking monthly Patch Tuesdays (January and October)
- The “Important” vulnerabilities (over 90 percent) remained the largest category, with “Critical” patches also significant, and a notable rise in actively exploited zero-days (41 in 2025).
- Elevation of Privilege (EoP) and Remote Code Execution (RCE) flaws were dominant.
- The increasing scope of Microsoft’s portfolio, including AI and cloud products, contributes to higher patch counts.
This is the problem the Stakeholder-Specific Vulnerability Categorization (SSVC) framework was created to address.
Since its initial publication in 2019, SSVC has evolved from a set of concepts and questionnaires into a practical decision framework with defined models that organizations can adopt, implement, and operationalize. As adoption has increased, barriers to entry have steadily decreased. New tooling, community-driven interfaces, and APIs, combined with CISA’s Vulnrichment efforts and improved data exchange formats, are making SSVC easier to integrate, automate, and scale.
As a result, more organizations, including smaller teams without dedicated risk engineering staff, can now apply SSVC using data already flowing through their vulnerability management processes. This post traces the milestones that made this shift possible and invites the community to participate, contribute, and benefit from the continued maturation of SSVC.
Transitioning to SSVC
Introducing a new framework for prioritizing vulnerability response presents two problems: stakeholders must be able to access framework data, and they must be able to consume it in support of decisions. In 2019, they could do neither. For starters, stakeholders had to generate their own data by reading and analyzing vulnerability reports. Moreover, the vulnerability ecosystem was geared to support the more popular Common Vulnerability Scoring System (CVSS) scoring and metric values, so adapting to SSVC was an uphill battle that few were inclined to undertake. Transitioning from CVSS V3.1 to SSVC is a greater challenge than translation—it is more analogous to converting from driving a car with an automatic transmission to a motorcycle with a manual transmission, a challenge of spatial awareness and how you interact with your environment. By mid-2024, deployers had some global data, but no way to integrate it. Now, at the start of 2026, deployers have the global data and will soon be able to integrate the data.
SSVC is now more broadly accessible, and it continues to gain adoption, particularly by larger, well-resourced organizations. For example, CISA uses the SSVC framework to prioritize vulnerability response and protect federal networks from active cyber threats.
Increasing Availability of Vulnerability Data Content
SSVC adoption has hinged not just on motivated individuals and organizations integrating it into their own decision-making apparatus, it is also facilitated by the increasing availability of consumable data from trusted and reliable sources:
- CISA KEV and Vulnrichment programs provide SSVC-ready information.
- CVSS V4 and SSVC share semantic compatibility in some attributes by design.
- Both CVE and CSAF data standards are or will soon be incorporating schemas to allow the inclusion of SSVC data.
KEV (since November 2021)
A key question in SSVC is the state of Exploitation for the vulnerability in question. The Known Exploited Vulnerabilities (KEV) catalog, established by CISA in November 2021, contains a “subset of CVEs which have been used to compromise systems in the real world.” KEV records are always Exploitation: Active, per SSVC, and this data can accordingly be represented in decision models. Exploitation is the first decision point in both Supplier and Deployer decision tables for SSVC, foregrounding its significance in vulnerability management. The existence of the KEV catalog attests to the importance of the Exploitation question.
CVSS V4 (Since November 2023)
Released in November 2023, CVSS V4 has two evaluation criteria (metrics in CVSS terminology), Automatable and Value Density, that are identical to the SSVC decision points of the same names. CVSS V4 and SSVC developed these criteria in tandem, and they are functionally interchangeable. Automatable asks whether an attacker can reliably automate creating exploitation events for the vulnerability. Value Density captures the concentration of value in the potential target systems; for example, an organization’s Enterprise Resource Planning (ERP) has higher value density than end-user devices.
Furthermore, the SSVC Public Safety Impact decision point is identical in definition to the CVSS V4 Safety vector. Additionally, CVSS V4 simplified Exploit Maturity (from V3.1) by removing an intermediate value; by doing so, the CVSS V4 Exploit Maturity vector and the SSVC Exploitation decision point converged to semantic equivalence.
An important design goal for SSVC is that the number of possible inputs and outcomes for a decision table should fall within a human’s level of comprehension. In contrast, CVSS V4 has more than 15 million possible input combinations that are reduced to 270 macrovectors that reduce to 101 scores that are further reduced into 4 categories (Low, Medium, High, Critical). The approximately 100 possible outcomes is difficult for a human to consider. The reduction in scale indicates that the greater community is converging toward a number of possible outcomes that is more readily human-manageable, noting that CVSS’s complexity on the input side still means that a lot of analysis is necessary on the front end. Comparatively, the default SSVC deployer decision table has 72 possible input combinations that yield 4 possible outcomes (Defer, Scheduled, Out-of-Cycle, and Immediate), numbers within the realm of human comprehension. Furthermore, the CVSS V4 equivalence sets can be modeled as SSVC decision points, demonstrating how SSVC logic can be applied to other frameworks.
ADPs (Since May 2024)
Historically, there has been an issue of Common Vulnerabilities and Exposures (CVE) entry data lacking sufficient useful information for vulnerability response practitioners. For example, many CVE records lack information about technical impact, state of exploitation, and whether the exploit is automatable. To amend this, since May 2024, CISA has been enriching CVE entries as an Authorized Data Publisher (ADP) to “[augment] the information in a CVE Record.” This Vulnrichment effort contributes SSVC decision points, KEV catalog data, and other updates for CVE data. As a result, Technical Impact, Exploitation and Automatable decision point data are readily available and therefore machine-ingestible. In SSVC, these decision points are stakeholder-agnostic in two important ways: their definitions are universal and consistently understood across roles and contexts, and for a given vulnerability they are expected to be evaluated the same way by different stakeholder roles, from engineers to auditors and researchers. By publicly providing these stakeholder-agnostic evaluations, Vulnrichment reduces the number of questions that individual stakeholders must answer for each vulnerability, making SSVC inherently easier to adopt.
Improving Vulnerability Data Format Records
SSVC Version 2025.9 included JavaScript Object Notation (JSON) schema updates so that SSVC decision points can be automatically ingested with vulnerability data. (For more on SSVC versioning see here.) Beyond improving the JSON schemas, working to make SSVC data machine-readable helped us refine namespaces to better organize the framework for different consumers. Improving the JSON schemas had direct downstream impacts on being able to integrate SSVC decision points into vulnerability data exchange formats.
CVE records (CVE schema version 6)
The CVE Program is expected to release CVE schema version 6, which will introduce SSVC decision point selections, thus enabling standardized, machine-readable SSVC data to be distributed directly from the CVE.org website feed. This will help CVE Numbering Authorities (CNAs) and ADP data providers communicate SSVC evaluations earlier in the lifecycle and support a shift-left approach to vulnerability management.
CSAF records (Release 2.1 )
Common Security Advisory Framework (CSAF) records build on CVE records to provide machine-ingestible data about vulnerabilities. The CSAF 2.1 release integrates the CERT Coordination Center’s SSVC decision point values and selection schema in its specification. By adding the structured SSVC Selection data into CSAF records, automated vulnerability tooling can now exchange SSVC data end-to-end, allowing a broader set of stakeholders to operationalize SSVC more quickly.
Today, Deployers Can Readily Adopt SSVC
In the early days of SSVC, stakeholders had to mine their own CVE data in relation to their decision models. Now, stakeholders can use CISA-provided Vulnrichment data to apply publicly shared SSVC information in their decision models so that stakeholders can improve consistency and efficiency in their vulnerability responses. Particularly, deployers using the default SSVC Deployer Decision Table have an easier path to adopting SSVC. As decision points, the states of Exploitation and whether an exploit is Automatable are universal across systems, making them high-value metrics to communicate when exchanging vulnerability data. With these two decision points provided, deployers only need to consider the decision points System Exposure and Human Impact, which are static from one vulnerability to the next because they are attributes of the system in question. Once deployers assess an inventory of these two decision points, and they can consume data about Exploitation and Automatable decision points, the deployers have all requisite information to use SSVC in their vulnerability management.
The Future of SSVC
As SSVC becomes more widely adopted in support of vulnerability response, we hope that SSVC data will include more vulnerability records and the APIs to consume them. This includes adoption by data producers of the formats that include SSVC data to the tools to consume that data. We ask interested stakeholders to look for SSVC data in formats that they are already consuming, such as in CVE, NIST, and CSAF records.
SSVC will continue to pursue extensibility and customization while preserving a reliable way for these resources to be processed and used in vulnerability prioritization and beyond. If you’re still unsure about SSVC, try our interactive SSVC Calculator, which demonstrates the ability to render and present publicly available CVE data with a decision model. Another tool in our website, SSVC Explorer, allows you create your own policy or help customize ready-made policy for your needs. Finally, if you have suggestions to help us improve SSVC, want to tell us about your use case, or otherwise provide feedback, please don’t hesitate to use our GitHub Discussions as the starting point for a conversation.
