Beyond CVSS to VRS: A New Vulnerability Prioritization Model for the AI Era

The Era of APIs and Vulnerabilities: Security Operations Beyond Zero Trust ③ A VRS combining weaponization likelihood, attack graphs, and GNNs is needed Proactively preventing threats by blocking attack paths is essential

이용 위드네트웍스 프로덕트 총괄 상무 이사

[DataNet] As AI accelerates the discovery and exploitation of vulnerabilities, traditional CVSS-centered vulnerability management is no longer sufficient to effectively address real-world attack risks. Priorities must now be determined not by the severity of a vulnerability, but by its actual likelihood of weaponization and its position within an attack path. This requires a VRS (Vulnerability Risk Score)-based approach that combines KEV, EPSS, publicly available exploit information, and attack graphs.<Editor>

<Series>

1. Security After Zero Trust: We Are Already Inside

2. The Invisible Attack Surface: The Era of APIs and Shadow APIs

3. Vulnerabilities Must Be Predicted and Eliminated: Continuous Vulnerability Management and a New Security Model (This Issue)

The previous two articles identified two major structural changes. First, Zero Trust as implemented in real-world environments is no longer sufficient as a defense model; attacks increasingly occur after authentication by exploiting vulnerabilities. Second, the assets of modern systems are being redefined around APIs, while the proliferation of shadow APIs continues to create attack surfaces that organizations are unaware of.

One question now remains: In an environment that is changing and expanding this rapidly, which vulnerabilities should we eliminate first? The answer is far more difficult than it may seem.

Numerous Attacks Exploit Medium-Severity CVSS Vulnerabilities

Recent reports indicate that security-focused AI models have autonomously discovered vulnerabilities that had gone undetected for decades. AI has now reached the point where it can identify attack surfaces that humans have overlooked. For example, the National Institute of Standards and Technology (NIST) has reduced its comprehensive management of the National Vulnerability Database (NVD), leaving approximately 29,000 vulnerabilities unclassified. This is effectively an acknowledgment that trying to keep up with every vulnerability individually is no longer a viable approach.

Most organizations prioritize vulnerabilities based on simple severity classifications such as Common Vulnerability Scoring System (CVSS) scores. However, CVSS represents the theoretical risk posed by a vulnerability and does not reflect how quickly it is likely to be exploited in a real-world attack. Two vulnerabilities with the same CVSS score may have completely different outcomes: one may lead to widespread attacks within days, while the other may remain unexploited for years.

An analysis of the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog illustrates this reality numerically. Many vulnerabilities listed in the KEV catalog were rated only “Medium” under CVSS. Conversely, a significant number of vulnerabilities rated “Critical” by CVSS have never been observed being used in actual attacks. This means that score-based prioritization can structurally point organizations in the wrong direction.

Various Approaches to Measuring Weaponization Likelihood

The vulnerabilities that require the most attention are not simply those that “look dangerous,” but those that are actually likely to be converted into attacks. In other words, the core of vulnerability management should shift from assessing severity to predicting weaponization likelihood. To do this, organizations must first measure the weaponization status of vulnerabilities precisely.

Some of the most widely used signals currently available include:

• CISA KEV: A catalog of vulnerabilities confirmed to have been exploited in real-world attacks. The strongest evidence of weaponization.

• Exploit Prediction Scoring System (EPSS): Uses machine learning to provide a probability of exploitation occurring within the next 30 days.

• Metasploit Framework (MSF) / Exploit Database (EDB) presence: Indicates whether automated exploit code that attackers can actually use is available.

• Public PoC availability: Whether proof-of-concept (PoC) code has been publicly released, such as on GitHub.

• Nuclei template availability: Whether a template for detecting the vulnerability has been registered in Nuclei, an automated vulnerability scanning tool.

• 
  

These signals reflect different stages of an attack and different attacker profiles. KEV captures vulnerabilities that have already been used in attacks at the nation-state or organized-group level. MSF and EDB indicate the level of automation available to ordinary attackers, while EPSS provides an early indication of the potential risk of newly disclosed vulnerabilities that have not yet been confirmed as exploited. Combining these signals makes it possible to construct a quantitative “Weaponization Score” representing how close a vulnerability is to being ready for exploitation.

How Structure Explains Risk

Weaponization signals for individual vulnerabilities are still not enough. Vulnerabilities do not exist in isolation; the structure of the ecosystem in which they exist also affects their risk. Vulnerabilities repeatedly found across a particular vendor’s product line can provide attackers with familiar attack paths and tend to be weaponized more quickly. The structural characteristics of specific vulnerability types (CWEs), as well as the relationships between vulnerabilities—such as which vulnerabilities connect to others within an attack chain—are equally important.

When relationships between CVEs are structured as a graph, the position of each vulnerability within its ecosystem becomes visible. Vulnerabilities with high connectivity or centrality—those positioned at the intersection of many other vulnerabilities—are more likely to become footholds within an attack chain.

Statistically connecting this structural information with weaponization scores reveals an important factor: the risk explained by collective characteristics such as vendor, product, vulnerability type, and year, as well as structural position, can be separated from the “excess risk” that these factors cannot explain.

If a vulnerability in a similar product from the same vendor is weaponized unusually quickly, that excess risk is a signal requiring immediate attention. It represents an anomaly that may be difficult to predict from historical patterns or experience but stands out in real-world attacks.

Pre-emptive Prediction of New CVEs: Inductive Learning

Excess-risk signals are standardized and converted into continuous labels between 0 and 1, which then serve as the learning targets for a Graph Neural Network (GNN). Operating on an attack graph connecting multiple vulnerabilities and assets, the GNN estimates and predicts paths and hub nodes that are more likely to lead to actual compromise. Unlike traditional rule-based approaches, it learns from historical weaponization data and structural information together, using representation learning to identify high-risk paths and nodes.

The features learned by the model consist exclusively of signals derived from the vulnerabilities themselves, such as CVSS scores and vulnerability descriptions. Weaponization status and structural position are reflected only in the labels and are not included as features. This is a deliberate design principle intended to prevent the model from being contaminated by future data.

Through this design, the model learns patterns observed in historically weaponized vulnerabilities and can inductively predict the risk of newly disclosed CVEs for which no weaponization signals are yet available, while taking the context of the attack graph into account. The GNN output is standardized on a 0–100 scale and presented as an operational risk score that security teams can understand intuitively.

From Periodic Assessment to Continuous Vulnerability Management

Let us interpret this model from an operational perspective. Traditional vulnerability management generally involves conducting assessments at scheduled intervals, cataloging discovered vulnerabilities, and patching them in order of severity. This approach has three major limitations: it fails to capture vulnerabilities that emerge between assessment cycles, its priorities do not necessarily align with actual attack likelihood, and its response speed cannot keep pace with the speed of attacks.

Applying a weaponization-likelihood-based model changes the operating model itself. As soon as a vulnerability is discovered, its weaponization score is calculated, structural excess risk is identified, and its final priority is determined automatically. When new exploit code is released, KEV and EPSS signals are updated, and the changes are immediately reflected in the weaponization score and final risk rating. Conversely, when a patch is applied or external exposure is blocked, the risk score immediately decreases. This is not a one-time analysis but a dynamic pipeline that is continuously updated whenever new information becomes available. Ultimately, the vulnerability management lifecycle is restructured into a continuous loop: “discovery → weaponization scoring → structural analysis → GNN prediction → remediation → reassessment.”

GNNs go beyond simple scoring to become triggers for network-level response. Operating on attack graphs connecting multiple vulnerabilities and assets, GNNs predict paths and hub nodes that are highly likely to lead to actual compromise. When this information is combined with Zero Trust and SDN-based policy engines, workloads located along high-risk paths can be automatically segmented and isolated at the network level, creating a structure that blocks the progression of an attack itself.

For example, if a particular API server is identified as a key hub node in the attack graph and its weaponization score for a KEV-listed vulnerability exceeds a defined threshold, the policy engine can move the server into a microsegmentation-based isolation zone and block communication with external and adjacent services while maintaining only the minimum management channels required. This goes beyond simply blocking the server: it immediately prevents lateral movement by the attacker without taking the entire service offline, enabling a more precise defense.

Vulnerability management priorities should not be determined by “how many vulnerabilities exist,” but by where each vulnerability is in its lifecycle and how exposed it is externally. How long an externally exposed vulnerability remains unaddressed should become a key measure of an organization’s actual risk. To manage this properly, organizations must first identify which vulnerabilities are externally exposed, then track who took what action, whether remediation was actually completed, and whether evidence of the action remains. Only then can the effectiveness of risk reduction be objectively evaluated across the entire lifecycle.

Practical Priorities: What Must Be Blocked Right Now?

Even when this pipeline is operational, practical constraints remain because not every organization starts from the same point.

Organizations with access to security-focused AI models should prioritize vulnerabilities directly identified by those models. These vulnerabilities are considered highly likely to be exploited in real-world attacks. Next should come vulnerabilities detected on actual systems using Nuclei, OpenVAS, or in-house scanners. In other words, vulnerabilities identified by AI models and scanners in real-world environments form the primary “golden list,” while VRS (Vulnerability Risk Score) then combines KEV, EPSS, exploit-code signals, and structural information to refine the priority. If AI models and scanners quickly identify “which vulnerabilities are a problem,” VRS provides a data-driven answer to “which of them must be blocked right now?”

For organizations that have limited access to security-focused AI models, a practical starting point is to use vulnerabilities detected by Nuclei, OpenVAS, or in-house scanners as the top-priority list, then re-rank them by combining KEV, EPSS, exploit-code signals, and structural information.

Policy Shifts and Operational Metrics

Let us now expand the discussion to policy and decision-making. In many organizations, security is still viewed primarily as a cost and operated mainly to satisfy compliance requirements. Vulnerabilities, however, are not merely technical defects; they represent business risks that can be exploited immediately. Vulnerability management should therefore be redefined from “periodic assessment” to a “continuous operational system.” Asset management should be expanded to include APIs, while prioritization should shift from static metrics such as CVSS to dynamic indicators that reflect actual attack potential, including KEV, EPSS, and MSF.

Organization-level operational metrics must also change. Mean time to remediate (MTTR) for high-risk vulnerabilities, the immediate response rate for KEV-listed vulnerabilities, and the percentage of detection and prioritization processes that are automated reflect more than security maturity—they provide a measure of an organization’s actual level of risk. These metrics should be directly linked to executive decision-making and used to determine security investment priorities.

With NIST reducing its comprehensive NVD management model, Korea can no longer rely solely on external databases. A transition to an independent workflow centered on vulnerabilities that are actually being exploited, such as those listed in KEV, is urgently needed. Recent discussions around national critical infrastructure asset inventories, SBOM adoption, AI-powered SOCs, and plans for a National AI Security Center are moving in the same direction. At the national level as well, infrastructure must be built by combining continuous vulnerability management, attack-path-based analysis, and AI-driven response capabilities.

Vulnerabilities will not disappear. Attacks, meanwhile, are becoming faster. In this environment, the only variable that can be controlled is the speed at which vulnerabilities are eliminated. What determines that speed is no longer human intuition, but a continuous pipeline built around weaponization measurement, structural risk analysis, and graph-based prediction. The attack graph, GNN, and Zero Trust/SDN integration model proposed here offers one way to make the transition from “finding and blocking vulnerabilities one by one” to “blocking the attack path itself” a reality at both the quantitative and operational levels.

---

원문 보기

데이터넷