Risk-based vulnerability prioritization: how asset context complements the CVSS score

2025 was a record year for the number of published vulnerabilities. Over 48,000 vulnerabilities were recorded, which averages out to 130 per day. (cve.icu) The trend is not slowing down: in the first half of 2026, 36,000 vulnerabilities were published — nearly 50% more than in the same period of the previous year. According to the FIRST forecast, around 66,000 new vulnerabilities are expected to be disclosed by the end of the year. (first.org)

This growth takes its toll on the security teams responsible for vulnerability management. The imbalance between the number of items requiring assessment and the capacity to remediate them keeps deepening. It is noticeable even in institutions created specifically to catalog threats, such as the American NVD (National Vulnerability Database). According to their announcement of April 15, 2026, they are changing their prioritization mechanism. They will first enrich vulnerabilities from the KEV catalog (CISA’s Known Exploited Vulnerabilities — cisa.gov) that affect federal and critical software (as defined in nist.gov). The remaining vulnerabilities will still enter the NVD database, but will be marked as low priority, with no immediate analysis or enrichment of their descriptions planned.

This situation clearly illustrates that the traditional approach based on the CVSS (Common Vulnerability Scoring System) score is insufficient under current conditions. The NVD example confirms that a new approach to vulnerability management is required, because today’s challenge is no longer “how to patch every gap” but “what should be fixed first to reduce risk most effectively.” Such a solution is implemented in SecureVisio — below we show how the same vulnerability can receive different priorities depending on the importance of the asset on which it occurs.

What CVSS measures — and what it doesn’t

CVSS — the Common Vulnerability Scoring System — is an international, open standard for assessing vulnerabilities in systems and software security. It defines how difficult a given flaw is to exploit and how severe the consequences of a successful compromise would be. The CVSS standard exists in several versions, e.g. v2.0 (legacy), v3.x, and v4.0. The latter is the newest and has been in use since 2023. Databases such as CVE and NVD, as well as vulnerability scanning and management software, typically operate on several versions in parallel, which is why the same vulnerability often carries two or even three scores corresponding to the different versions of the standard.

These scores consist of three metric groups, which are the same for every version, although the metrics they contain differ. Below is a description of v3.1, as it is the most commonly encountered — v2 is already obsolete, and v4 is only now being adopted.

CVSS v3.1 divides the score into three metric groups:

• Base Metrics — static characteristics of the vulnerability, independent of time and environment. They are mandatory, as they produce the “raw” CVSS score.
• Temporal Metrics — these change over the lifetime of the vulnerability and reflect the current state of knowledge and response to the CVE. They are optional and can lower the Base Score.
• Environmental Metrics — these adjust the score to a specific organization/infrastructure. They are optional and allow the Base Score to be overridden and business weight to be added.

One can see here an attempt to address the problem of risk arising from the characteristics of a specific system. In practice, however, almost only the Base Score is in circulation: vulnerabilities published in databases such as NVD include this metric, while the others usually remain empty. The next version of the standard, 4.0, improves the precision of the technical assessment itself, but does not change the fact that it is a measure of severity, not of risk in a specific environment. A full description of the individual versions is available at first.org.

The key point is that the Base Score is universal — it is the same for all organizations and independent of where a specific vulnerability occurs. It says nothing about real consequences in an actual environment. It describes the impact solely on the vulnerable component itself, from a technical perspective, ignoring the organizational context. NVD itself points this out, stating explicitly that “CVSS is not a measure of risk” (nvd.nist.gov).

Equating severity understood in this way with risk leads to flawed decisions. Risk is the combined product of severity, likelihood of exploitation, and the value of the asset the flaw exposes — and the base CVSS score describes only the first of these elements. This creates concrete limitations:

• The metrics describing the environment remain empty. Although the standard provides for them, filling them in manually for thousands of entries is far too labor-intensive, so it is rarely done. As a result, the score loses the only element that would tie it to the organization’s context.
• At today’s scale, the score alone barely differentiates vulnerabilities. In 2025, critical scores were assigned to 8% of published vulnerabilities, and high scores to as many as 31% (nvd.nist.gov). With 48,000 flaws, that means well over ten thousand vulnerabilities classified as urgent. No team can treat that many vulnerabilities as priorities, so this information is not useful for deciding the order of work.
• The score is static — it is assigned once and usually never changes, even if a new, publicly and widely available exploit appears for a given vulnerability. Information about whether a flaw is actually being exploited is not part of the Base Score.

NIS2, the NIS2UmsuCG and vulnerability assessment

Taking the consequences for a specific organization into account when assessing vulnerabilities is not merely good practice. For many entities it is a legal obligation arising from the NIS2 Directive and, in Germany, from the NIS2 Implementation Act — the NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), which transposes NIS2 into German law primarily through a fundamental amendment of the BSI Act (BSIG). The regulations do not prescribe a specific method of vulnerability prioritization, nor do they prohibit CVSS, but they do require risk management and the application of measures proportionate to the threat. The principle of proportionality is key here. Under § 30 BSIG, the selection of measures must correspond to the entity’s degree of risk exposure, its size, and the likelihood and severity of potential consequences, including their economic and societal impact. In this light, sorting vulnerabilities solely by their technical CVSS severity, detached from the consequences for the organization, can hardly be considered sufficient to demonstrate a risk-based approach. Prioritization that takes asset context and consequences into account is the natural way to implement — and document — this proportionality.

It is worth adding that the regulator’s expectation aligns with a broader industry direction described as risk-based vulnerability management (RBVM). This is not the approach of a single vendor but a market standard with a common denominator: technical severity is the starting point, while the order of remediation is determined by the likelihood of exploitation and the asset’s importance to the organization. Individual tools implement this in different ways, and SecureVisio is one such implementation — one in which the entire context is created within a single platform.

Threat context vs. asset context

The real vulnerability priority — the one needed for effective vulnerability management and for meeting regulatory requirements — depends on two independent questions:

The first comes from the outside world: which vulnerabilities exist and how severe they are by nature, regardless of the environment. This is answered by vulnerability databases with CVSS scores and by scanners that detect flaws in components. This is a purely technical layer. It does not determine what a given flaw exposes in a specific environment.

The second concerns the specific organization: what happens if the vulnerability is exploited on this particular asset — which processes are affected. This is knowledge on the border between the business and technical worlds: what operating system runs on the asset, how it is protected, what data it processes, which business processes it supports. No external tool and no external organization can supply this data, because it is specific to each organization. And it is precisely this data that is decisive when determining the real weight of a vulnerability.

A simple example illustrates this. A critical RCE vulnerability — the ability to execute code remotely — with a CVSS score of 9.8 on a production server in the DMZ that supports a key payment process and handles customers’ personal data: this is a potential incident with serious business and legal consequences. Now take the same flaw on a test server located in an isolated network segment, with no external access and no Internet connectivity, working on test data. Here the situation is far less serious — the risk is limited. The CVSS score for both cases is identical; the difference only becomes visible once the context of these assets is added. This is exactly the approach implemented in SecureVisio.

CVSS and asset context in practice

For a vulnerability prioritization algorithm to be able to tell a test server apart from a production system, it needs structured knowledge about assets. Combining a CMDB asset database with business impact analysis (BIA) and risk analysis can deliver this information. This is the architecture the SecureVisio platform is built on, where vulnerability management is integrated with the remaining modules, operating as a single tool available from a shared console.

SecureVisio consolidates asset data through a bidirectional integration between the CMDB and vulnerability management modules. Each asset can carry information about its owner, criticality level, and the associated business processes it supports, and the system automatically matches the technical information from a vulnerability scan to specific assets. The CMDB acts here as a logical map of the infrastructure, showing the connections between assets. Another layer is added by the BIA, which identifies the consequences — what the organization loses if the security of a given asset is breached. The risk analysis module uses this information to assess the likelihood of specific attacks against specific assets and to present their impact.

In practice, asset context covers attributes that the system matches against specific vulnerabilities, including:

• asset location and exposure, e.g. presence in the DMZ,
• IP addressing,
• asset classification, e.g. whether it is a workstation, a test or production server, or a database,
• asset criticality,
• associated business processes,
• authorized communication, e.g. information that as part of one of the business processes the asset is exposed to the Internet.

The CVSS score and the data from the vulnerability report are layered on top of this context, allowing technical information to be combined with organizational knowledge. Thanks to the coherence of the platform, the relationship works both ways: vulnerability information enriches the data in the CMDB, and contextual data modifies priorities in the vulnerability management module. Risk analysis also works in both directions — its results influence vulnerability priorities, and vulnerability data enriches the analysis itself. The SIEM, SOAR, and UEBA modules can likewise participate in building the context and putting it to use.

The result of this approach is that an abstract severity score is turned into information with operational meaning — for example: this vulnerability affects a system handling customer billing that lacks an additional protective layer. A description like this makes it possible to realistically set the order of remediation work.

The prioritization formula in SecureVisio

The mechanism that converts context into priority in SecureVisio is simple: the severity score returned in the vulnerability scanner report is multiplied by an internal priority and modified by built-in vulnerability prioritization rules. The result is a score reflecting the real significance of a given vulnerability for the specific organization. It can be written as a formula:

scanner severity × internal priority × built-in prioritization rules = real priority

Each of these three factors is responsible for different elements of the assessment and contributes a different kind of context to the whole.

Scanner severity is the Base Score described extensively in this article. The system does not discard this score, because it carries essential technical information about the vulnerability itself and serves as the starting point for further calculations.

Internal priority adds asset and business context; it comes from the CMDB, the BIA, and the risk analysis. It answers the questions a scanner cannot verify: how critical the asset is, how critical the business processes running on it are, which systems depend on it. It is these factors that most strongly differentiate seemingly identical vulnerabilities.

Built-in prioritization rules are conditions that check the asset information gathered across the system’s various modules. Not all of them work in the same direction: some rules raise the priority, others lower it, depending on the condition embedded in a given rule. It is at this stage that asset reachability and the realistic possibility of exploiting the flaw enter the assessment — something the Base Score alone cannot see. Priority is raised by conditions such as: the asset being exposed to the Internet or placed in the DMZ, the absence of a compensating mechanism (e.g. a WAF in front of the service), or indicators of compromise (IoC) associated with the asset. Priority is lowered by the opposite conditions, e.g.: full isolation of the asset, effective compensating controls, or low criticality of the data being processed. As a result, the same vulnerability receives a different priority not only based on the asset’s value, but also based on how realistically reachable it is for an attacker.

The rule set is not closed. SecureVisio allows organizations to create their own prioritization rules and modify the default ones. This makes it possible to mirror a given organization’s vulnerability and risk management policy. The correlation engine combines all these factors in real time into a single verdict, relieving analysts of the need to manually review numerous parameters for each of hundreds or even thousands of vulnerabilities. The result is a vulnerability list ordered by significance to the organization, rather than by technical severity detached from the environment.

Example: the same vulnerability on two assets

The formula is best demonstrated on a single vulnerability occurring on two different assets. The values below are illustrative — the exact scoring scale depends on the organization’s configuration — but the mechanics remain unchanged.

The critical vulnerability CVE-2026-33824 (msrc.microsoft.com), scored 9.8, allows remote code execution on a vulnerable machine. A vulnerability scanner has detected it on two servers.

Server A:

PRD-DB-01 is a production database exposed externally in the DMZ, processing personal data. All this information is available in SecureVisio, as shown in the screenshot below.

Figure 1. Asset context for PRD-DB-01 available in SecureVisio

Server B:

TST-DB-01 is a test database, accessible only within the local network, with no Internet access, no production data, and no connections to production systems. All this information is available in SecureVisio, as shown in the screenshot below.

Figure 2. Asset context for TST-DB-01 available in SecureVisio

Both cases carry a critical Base Score, yet the priority that accounts for organizational context differentiates these vulnerabilities significantly. This is visible in the screenshot below. On the production server the vulnerability is marked as critical (red), while on the test server it is only medium (yellow) — so the vulnerability team knows, immediately upon detection, which one to address first. If they had stuck with the standard approach based on CVSS alone, that decision would not be so simple. At a scale measured in hundreds or thousands of vulnerabilities, this difference translates directly into the effectiveness of the entire process. The vulnerability on the test server, with its medium priority, will land in the middle of the overall vulnerability list, so handling it will not overshadow flaws that are more critical in the organization’s context.

Figure 3. Vulnerability priorities in SecureVisio

The condition for effectiveness: asset data quality

Context-based prioritization depends on the data that feeds it. If the CMDB is incomplete or outdated, and the risk and business impact analyses have not been performed, the end result will not differ significantly from CVSS. The value of this approach grows with the quality of asset information.

Implementing this vulnerability assessment model does not require a one-off revolution. It consists in moving the decision from the level of a single technical score to the level of the entire process. In practice, it comes down to a few areas:

• Asset inventory and classification. Assets should be assigned owners, criticality levels, and the business processes they support. It is worth starting with the ones most crucial to the organization.
• Linking the inventory with scan results. Ensuring a free flow of information between scanner reports and the CMDB. A bidirectional integration between the CMDB and the vulnerability management module means every flaw is immediately assigned to an asset along with its context.
• Tuning the prioritization rules. Translating the team’s expert knowledge into a repeatable mechanism. The default rules are a good starting point, but it is the rules reflecting the organization’s specifics — concerning DMZ exposure, required WAF presence, or data classes — that best capture its real risk.
• Closing the remediation loop. A priority without an assigned owner and without remediation time tracking remains just a score. Routing the highest-priority vulnerabilities to specific people and monitoring progress is what makes better prioritization translate into a real reduction of risk.

The more of these elements operate within a single platform, on a shared asset model, the lower the cost of maintaining the whole and the smaller the risk of the context going stale between separate tools. The architecture of the SecureVisio platform makes it possible to implement all of these areas in one shared place. Additionally, coupling this with the SIEM/UEBA module (also part of SecureVisio) enables extensive automation. The CMDB context can be built on the basis of logs collected by the SIEM; dedicated correlation rules can detect things such as: the asset type, running services, the role performed (e.g. DNS, domain controller), the location of users connecting to services, the security controls in place, and so on. Simplifying and accelerating the inventory process is not the only benefit of this approach. Building context on real data — in this case environmental logs — significantly increases the credibility of that information. Consider the following situation. Six months ago, a host firewall was deployed on a server; this information entered the inventory and is still used in risk assessments today. However, a month ago maintenance work was carried out on this asset, and because the firewall was blocking required traffic, it was disabled. After the work, nobody turned it back on. The vulnerability assessment is being performed on real but outdated context — whereas when information about security controls is drawn directly from the system (logs), SecureVisio will detect that the host firewall is no longer active, and it will no longer lower the priorities of the detected vulnerabilities.

Summary

CVSS remains a valuable measure of technical severity, but it does not answer the question every team faces when looking at a list of thousands of flaws: what to fix first. The Base Score is universal — identical for a production database in the DMZ and for a test machine — so it does not differentiate vulnerabilities according to their significance for the organization.

Only asset context does that: knowledge of what a given flaw exposes, which process it supports, and how it is protected. SecureVisio converts this into a priority by multiplying the scanner severity by the internal priority (from the CMDB, BIA, and risk analysis) and correcting it with built-in rules. As a result, the same CVE-2026-33824 receives a priority that depends on where it occurs, and the remediation list reflects business risk rather than a technical ranking detached from the environment.

The whole works only as well as the asset data is current. That is why it is worth starting with the most important systems and, wherever possible, building context from real data (SIEM/UEBA logs), which keeps it aligned with the actual state of the environment.