The CVSS (Common Vulnerability Scoring System) base score is a tool commonly used to prioritize the application of vulnerability patches. It is a common shortcut that nevertheless has significant consequences for the vulnerability management process.

Why the base CVSS score is not suitable for prioritization

The CVSS was never intended to be used for prioritizing vulnerabilities. Its specification states that it is primarily a score used to measure the severity of a vulnerability. The base score—the one generally available in public records—assesses only the intrinsic characteristics of the vulnerability. Thus, it takes absolutely no account of factors such as whether the vulnerability has actually been exploited or how it manifests in the information system where it is found.

Risk management experts know this well: severity is not the same as priority.

Priority is first and foremost a business matter. It is assessed in terms of the risk or the value that an action brings to business operations.

In contrast, severity is a functional metric. It is used to assess the technical impact of a vulnerability.

Thus, a vulnerability with a significant technical impact may very well have a very low business impact for various reasons:

• The affected system is not significant in terms of technical impact (e.g., a vulnerability affecting the availability of an asset that is not business-critical);
• The vulnerability is not being actively exploited, and the probability of it being successfully exploited is therefore low;
• The asset’s position within the information system and the implementation of defense-in-depth mechanisms make exploitation ineffective or highly unlikely.

If you still need convincing, let's take a look at the distribution of CVSS base scores by severity across the CVE (Common Vulnerabilities and Exposures) database:

Reference: https://nvd.nist.gov/general/nvd-dashboard

We observe that more than half of the vulnerabilities assessed by the NVD (National Vulnerability Database) are rated as high or critical. Out of a total of nearly 200,000 vulnerabilities assessed by the NVD, this represents more than 100,000 vulnerabilities that should each be addressed in the short term.

Current events are forcing you to rethink your priorities

A combination of factors makes any attempt at comprehensive patching impossible in practice:

• In 2025, more than 50,000 vulnerabilities were published in the CVE, and the trend for 2026 points to a new record;
• Since 2024, NIST (National Institute of Standards and Technology) has faced challenges in maintaining the NVD and enriching its data due to the sheer volume. They have announced that they will no longer classify all vulnerabilities but only those they consider a priority;
• The creation and availability of advanced LLM models such as Mythos and Fable 5 signal a democratization of vulnerability research with dual implications: more vulnerabilities will be documented, but there will also be more undocumented vulnerabilities.

Now more than ever, it is important to implement basic security hygiene measures, particularly regarding network segmentation.

When it comes to applying patches, a pragmatic approach is recommended: it is impossible to fix everything, so it is necessary to focus on what truly impacts business operations.

Prioritizing: A Different, Effective Approach

Let’s start by describing SSVC (Stakeholder-Specific Vulnerability Categorization), the framework used by CISA (Cybersecurity and Infrastructure Security Agency) to prioritize the release of vulnerability advisories.

Although its acronym is similar to CVSS, SSVC takes a completely different approach.

First, it is not a score but a decision tree. Based on vulnerability-related metrics, it helps determine the priority level for implementing risk mitigation measures.

Here is an overview:

The SSVC is based on four criteria that allow users to navigate the decision tree and arrive at the recommended course of action:

• Exploitation: whether or not a vulnerability is being exploited and whether exploit code exists;
• Automation: whether or not the exploitation of a vulnerability can be automated;
• Technical impact: partial (limited control over the system or data) or total (full access);
• Mission and well-being: this metric concerns the business impact and the consequences a vulnerability could have on humans or machines.

The first three metrics are generally easy to determine and are specified as part of CISA’s Vulnrichment initiative, which adds them to CVE records: 

To date, approximately half of all CVE entries have been enriched in this way by CISA.

The mission and well-being metric is the most complex to determine and is not assessed as part of Vulnrichment. This is to be expected, since it involves evaluating the business impact. It takes two factors into account:

• Impact on mission: this refers to the impact on a function that supports or is even essential to the business;
• Impact on well-being: this can be minimal, material (i.e., causing repairable damage or recoverable injuries), or irreversible (irreparable damage or serious injuries).

Once the four metrics have been determined, simply navigate through the branches of the tree to arrive at the recommended prioritization decision.

It is worth noting that the metrics in the SSVC prioritization process are cumulative. It is the combination of each of these elements that determines whether a high priority level is assigned or not.

These prioritization levels are classified into four categories:

• Track: No specific risk mitigation measures are required (beyond normal handling), but developments must be monitored and trigger a reassessment if necessary;
• Track*: No risk mitigation measures are required, but close monitoring is necessary, especially if a difficulty in addressing the vulnerability is identified;
• Attend: attention from third parties outside the vulnerability management process is required, and it may be necessary to communicate about the vulnerability;
• Act: coordination with all stakeholders is necessary to ensure the rapid implementation of risk mitigation measures.

Prioritization is a hot topic in the first half of 2026. Although the SSVC has been in place since 2019, CISA issued a new directive, BOD 26-04, on June 10, 2026, which clarifies the process and, most importantly, the prioritization deadlines that U.S. government agencies must adhere to.

Of course, you are not required to follow this guideline to the letter if you are not directly affected, but it provides a general idea of the level of responsiveness expected in light of the risks perceived by CISA in the context of a vulnerability disclosure.

In this context, the agency drew on the SSVC to create a decision tree regarding expected response times. It is regrettable that this tree no longer fully takes the business context into account, although it does retain one environmental factor: whether or not the affected asset is publicly exposed.

This guideline is useful in that it provides a realistic idea of response times and the actions to be taken based on the situation on the ground:

There is a wide range of expectations regarding patch application, ranging from very short timeframes (3 days with a compromise analysis) to “nice-to-have” items that are patched on an as-needed basis during a system update.

It’s up to you to determine your own prioritization policy based on your regulatory framework, your business risk analysis, and your teams’ capabilities. Here are two approaches:

• Use the SSVC if you already have a certain level of maturity in your vulnerability management processes, and apply it organization-wide, making sure to identify stakeholders—especially when making “Act” or “Wait” decisions;
• Use the BOD 26-04 framework with timeframes that fit your specific context if you’re looking for a quick and simple decision-making tool.

Conclusion

Given recent developments, it is important to understand that it is impossible to apply all existing patches. We must therefore prioritize to identify the vulnerabilities that need to be addressed and focus our efforts on those. With the current volume of releases, automating this task is no longer an option. 

Defense-in-depth mechanisms (segmentation, three-tier architecture, backups, etc.) are becoming increasingly relevant in light of new threats, particularly those posed by LLMs such as Mythos. They help mitigate vulnerabilities that have not yet been—or cannot be—patched.

Once these measures are in place, it becomes possible to prioritize by accepting the presence of vulnerabilities that can be managed. This reduces the pressure on technical teams while maintaining a reasonable level of security. It also enables greater responsiveness, especially when business teams need to be involved.

Yet even today, too many organizations use the base CVSS score to prioritize their actions for mitigating vulnerability-related risks. However, it was not designed for this purpose, and vulnerabilities with high scores make up the majority of the total number of vulnerabilities listed.

This inevitably leads to a sense of overwhelm, even though the number of vulnerabilities that truly matter accounts for only 1 to 5% of the total.

As we’ve seen in this article, this is where tools like SSVC come in handy for quickly assessing the priority of a vulnerability by evaluating a few relatively simple metrics. Furthermore, three-quarters of these metrics are already provided by CISA directly within the CVE system itself.

Regaining control over vulnerabilities is therefore first and foremost a matter of operational pragmatism and relies on the ability to make quick and effective decisions based on priority—and thus on the resources to be allocated to each vulnerability. This requires having the right processes and tools in place. And in this context, dialogue with business teams and risk teams is essential.