---
title: Vulnerability Mitigation System
url: https://www.emergentmind.com/topics/vulnerability-mitigation-system-vms
type: topic
---

# Vulnerability Mitigation System

Searching arXiv for relevant VMS papers and closely related vulnerability-management frameworks.
Vulnerability Mitigation System (VMS) denotes a class of security systems concerned with reducing exposure to known or observed vulnerabilities, but the term is used in the literature with several distinct emphases. In one formulation, a VMS is a tunable runtime framework that continuously measures which attacks are actually observed and re-tunes defenses so as to minimize performance, maintenance, and false-positive cost subject to hard security bounds [1802.08915]. In other formulations, the same term is applied to semi-automated CPE/CVE-based software checking [1705.05347], ontology- and ML-based hardware vulnerability mapping with root-cause analysis and GPT-assisted mitigation [2312.13530], deep reinforcement learning for sequential vulnerability prioritization [2208.02369], context-aware retrieval based on unified CPE modeling [2505.13895], LLM-based autonomous penetration testing [2507.21113], multi-agent adaptive software vulnerability management [2605.01739], recurring-vulnerability detection and repair [2601.17762], and formally grounded design-time reasoning over components, vulnerabilities, and controls [2507.05794]. The resulting research area is therefore not a single architecture but a family of closed-loop or semi-closed-loop systems for evidence collection, normalization, prioritization, enforcement, and validation.

## 1. Scope and architectural variants

Across the literature, VMS architectures differ chiefly in what they treat as the primary object of mitigation: deployed signatures, installed software identifiers, hardware weakness classes, vulnerability queues, penetration workflows, code histories, or design-time component models. The common structural pattern is a pipeline from evidence ingestion to a decision module and then to some enforcement, presentation, or reporting layer.

| System | Core input | Primary output |
|---|---|---|
| Reactive VMS | signature hits, matrices \(R\) and \(G\) | per-signature sampling rates \(\alpha_j\) |
| IVA | inventory strings, CPE dictionary, CVE feeds | user-confirmed CPEs and grouped CVE hits |
| HW-V2W-Map | NVD/CVE, CWE DB, ontology updates | CWE mappings, root causes, mitigation suggestions |
| Deep VULMAN | weekly vulnerability pool and budget | resource allocation and selected vulnerabilities |
| VulCPE | NVD, CVEdetails, uCPE graphs | context-aware vulnerability retrieval |
| AgenticVM | scanner outputs, NVD, EUVD, CISA KEV | prioritised queue and remediation recommendations |

The original reactive VMS is explicitly organized into an Evidence Collector, a Decision Engine, and an Enforcement Module. Evidence is represented as a tuple \((day\ t, signature\ j, hit\text{–}yes/no)\), accumulated into a ground-truth vector \(G\in\{0,1\}^N\) and a response matrix \(R\in\{0,1\}^{N\times M}\), and periodically converted into enforcement decisions \(\alpha_j\in[0,1]\) for each mitigation [1802.08915]. IVA, by contrast, is built around inventory collection, candidate CPE generation and ranking, a mandatory user-assignment step, and two-pass CVE matching [1705.05347]. HW-V2W-Map uses an ingestion pipeline, NLP and topic modeling, an Ontology-Driven Storytelling Framework, hardware vulnerability-to-weakness mapping, root-cause analysis, GPT-assisted mitigation suggestions, and an interactive GUI [2312.13530].

Later work further broadens the architectural range. Deep VULMAN formalizes weekly mitigation as an infinite-horizon MDP followed by integer-programming-based selection [2208.02369]. VulCPE standardizes raw CPE strings into a unified CPE schema and performs graph-based applicability filtering over configuration dependencies [2505.13895]. AgenticVM decomposes vulnerability management into Detection, Assessment, Prediction, Integration, Prioritisation, and Recommendation agents, coordinated by LangGraph and fed by scanner outputs and external databases [2605.01739]. This suggests that VMS has become an umbrella term for systems that couple vulnerability intelligence with a decision procedure and an operational output, even when the operational output is triage, patch selection, or repair guidance rather than direct mitigation enforcement.

## 2. Reactive runtime control of deployed mitigations

The 2018 reactive VMS treats mitigation deployment itself as an optimization variable. Its central claim is that mitigations are rarely retired or disabled even when their usefulness declines, so performance overheads, maintenance costs, and false-positive rates accumulate over time [1802.08915]. The proposed remedy is to measure real-world exploitation and tune defenses accordingly, including partial sampling or complete disabling when evidence of exploitation is absent.

The system’s first decision phase is an integer-linear program over batches of samples sharing identical signature-overlap patterns. Each batch \(b_i\) has a binary decision variable \(v_i\in\{0,1\}\), false-positive and true-positive counts \(FP_i,TP_i\), and performance cost \(c_i\). The optimization is

$$
\min_{v_i\in\{0,1\}} \sum_i c_i v_i
$$

subject to

$$
\sum_i TP_i v_i \ge X_p,\qquad
\sum_i FP_i v_i \le Y_p,\qquad
\sum_i c_i v_i \le Z.
$$

The second phase resolves overlap at the per-signature level through Bayesian inference. For each signature \(j\), a Bernoulli random variable \(C_j\) represents whether the mitigation is sampled, with a Beta prior \(C_j\sim \mathrm{Beta}(\alpha_{0,j},\beta_{0,j})\). For each observed batch \(k\), coverage is defined by

$$
P(\text{batch}_k\mid \{C_j\})=\mathbf{1}\Bigl[\bigvee_{j\in \mathrm{sig}(k)} C_j\Bigr].
$$

Expectation–Propagation then yields approximate posteriors \(P(C_j=1\mid \text{evidence})\), and the inferred \(P(C_j=1)\) becomes the continuous sampling rate \(\alpha_j\). Operationally, \(\alpha_j=1\) means always enforce, \(0<\alpha_j<1\) means sample a fraction of matching packets or files, and \(\alpha_j=0\) means fully disabled [1802.08915].

Cost is modeled with performance overhead \(c_j\), maintenance cost \(m_j\), and explicit false-positive and false-negative objectives. The false-positive rate is defined as

$$
FP(\alpha)=\frac{1}{N_{\text{benign}}}\sum_{i:G_i=0}\Bigl[1-\prod_j(1-R_{i,j}\alpha_j)\Bigr],
$$

and the false-negative rate as

$$
FN(\alpha)=\frac{1}{N_{\text{malicious}}}\sum_{i:G_i=1}\prod_j(1-R_{i,j}\alpha_j).
$$

These are combined into

$$
\mathrm{Expense}(\alpha)=C_{\text{scan}}(\alpha)+C_{FP}FP(\alpha)+C_{FN}FN(\alpha),\qquad C_{FN}=\beta C_{FP}.
$$

The evaluation replays 9.2 million Snort signature hits over 9 years for approximately 3,000 signatures. The reported effect is removal of approximately 9.2 million alerts, or approximately 20%, while shedding approximately 12% of true positives; the false-negative rate is explicitly described as a tunable knob via \(\beta\) [1802.08915]. Timeliness is central to the design: ILP on \(M\sim 3{,}000\) signatures runs in less than 1 s, Bayesian inference runs in under 2.5 min on 98% of days in the nine-year simulation, and the paper argues that this guarantees sub-hour re-tuning, typically sub-10 min in practice. The principal controversy is therefore not whether mitigation can be optimized, but how much moderate false-negative risk is acceptable in exchange for lower false positives and lower operating cost.

## 3. Data, ontology, and configuration-aware vulnerability knowledge

A large part of VMS research addresses the quality of vulnerability knowledge before any prioritization or remediation occurs. Benthin Sanguino and Uetz show that VMSs relying on the Common Platform Enumeration dictionary and the Common Vulnerabilities and Exposures feeds inherit lack of synchronization, typos, omissions, and divergent naming conventions, and that fully automated CPE assignment is wrong in roughly 16% of cases in their twelve-application evaluation [1705.05347]. Their Inventory Vulnerability Analysis workflow therefore generates and ranks candidate CPE identifiers, requires a user to select or edit the best match, and then performs CVE lookup by both CVE-CPE entries and CVE summaries. The necessity of user interaction is demonstrated by examples such as SeaMonkey 2.35, which initially matched 475 CVEs, only one of which truly applied [1705.05347].

HW-V2W-Map generalizes the knowledge layer by building an ontology from NVD and CWE data and continuously updating it with an NLP pipeline. Its Ontology-Driven Storytelling Framework includes core classes Vulnerability, ExploitTarget, AttackImpact, and CWE, with object properties Exploits, hasAttackImpact, and TargetsCWE. The base ontology built from NVD for 2010–2023 contains 252 classes, 518 individuals, and 1,460 axioms, stored as RDF triples in OwlReady2 [2312.13530]. Vulnerability-to-weakness mapping uses cosine similarity

$$
S_{ij}=\cos(\mathbf v_i,\mathbf w_j)
$$

between vulnerability descriptions \(v_i\) and CWE descriptions \(w_j\), plus features such as PMI-based n-gram association scores and named entities. A Decision Tree classifier is reported as the best-accuracy model on held-out data, achieving 98.29% accuracy, 90.90% recall, and 88.0% precision on 1,200 IoT/hardware CVEs with ground-truth CWE labels [2312.13530]. Root-cause analysis then traverses ontology triples from vulnerabilities through exploit targets to attack impacts and common CWE ancestors.

VulCPE addresses a closely related problem from the standpoint of configuration semantics rather than ontology semantics. It defines a unified CPE entry as

```text
uCPE_entry = ( id, vendor, product, version, type )
```

and standardizes raw CPE names using canonical dictionaries and a string-similarity function \(S(n,\mathcal D)=\arg\max_{n'\in\mathcal D}\mathrm{sim}(n,n')\), with \(\mathrm{sim}(n,n')=1-\mathrm{Levenshtein}(n,n')/\max(|n|,|n'|)\) and threshold \(\tau\approx0.8\) [2505.13895]. The framework builds directed graphs \(G_{\text{sys}}\) and \(G_{\text{vul}}\) over uCPE entries and logical combinations such as \((u_i\wedge u_j)\) and \((u_k\vee u_l)\), then performs subgraph matching to filter false positives under AND/OR applicability constraints. The reported retrieval performance is \(P_{\text{avg}}=0.766\) and \(C_{\text{avg}}=0.926\), exceeding the cited cve-search and OpenCVE baselines [2505.13895].

sec-certs shows that knowledge extraction can also be directed at certification ecosystems rather than software inventories. It crawls the Common Criteria portal weekly, processes 1,631 active and 3,725 archived certificates, converts PDFs with `pdftotext --raw`, recovers more than 97% of malformed cases using Tesseract OCR, extracts 472 regular expressions grouped into 33 categories, and maps certificates to CVEs using fuzzy title-to-CPE similarity with vendor and version alignment [2311.17603]. A reference graph \(G=(V,E)\) is then constructed from certificate identifiers. The vulnerability-mapping threshold is tuned to approximately 85% to yield approximately 90% precision, and the case studies show that graph expansion can increase affected-product enumeration from tens to well over a hundred certificates for high-profile vulnerabilities [2311.17603]. A plausible implication is that modern VMS designs increasingly depend on structured representations that can compensate for incompleteness and inconsistency in the underlying public repositories.

## 4. Optimization and control for prioritization and mitigation

When vulnerabilities cannot all be mitigated immediately, several VMS formulations cast prioritization as a constrained optimization or sequential decision problem. Deep VULMAN models weekly vulnerability mitigation as an infinite-horizon MDP \(\{S,A,P,r,\gamma\}\), where the state includes a padded matrix \(s_t^v\in\mathbb R^{N\times M}\) of normalized vulnerability attributes and the remaining staff-hour budget \(b_t\), and the action is a continuous scalar \(a_t\in[0,b_t]\) denoting how many staff-hours to spend in that week [2208.02369]. Reward combines the average attribute score of patched vulnerabilities and a penalty on consumed staff-hours:

$$
r_t=w_1 r_t^1+w_2 r_t^2,\qquad w_1+w_2=1.
$$

The agent uses PPO with a Gaussian policy \(\pi_\theta(a\mid s)=\mathcal N(a;\mu_\theta(s),\sigma_\theta^2)\), two hidden layers of 68 neurons with `tanh`, and a clipped objective. After the RL stage outputs the budget \(a_t\), an integer program selects the subset \(Z_t\) subject to \(\sum_j S_j z_j\le a_t\), maximizing average normalized attribute score [2208.02369]. On real CSOC scan logs containing 98,842 vulnerability instances over two years, Deep VULMAN patches 35% more high-value assets than VPSS, 28% more than VULCON, remediates 40% more low-protection machines, and 50% more IDS-flagged hosts [2208.02369].

A different control problem appears in the mitigation of Kubernetes YoYo attacks. The proposed system monitors CPU utilization per Pod, numbers of Pods and Nodes, response time, and request rate, computes statistics over a sliding window of at least three attack cycles, and uses XGBoost with \(n\_estimators=10\), `max_depth=1`, and threshold \(\theta=0.5\) to declare an attack when \(f(x)>\theta\) [2105.00542]. On detection, the mitigation actuator delays scale-down by setting

$$
I^n_{down,\mathrm{mit}}=I^n_{down}+T,\qquad
I^p_{down,\mathrm{mit}}=I^p_{down}+T,
$$

and can enforce a Pod-count floor \(P(t)=\max(P(t),P_{\mathrm{prev}})\) during the mitigation window. The reported result is 95% test accuracy, recall 1.0, precision 0.89, F1 0.94, economic-damage reduction from approximately 5 to approximately 2.5, and performance-damage reduction from approximately 1.15 to approximately 1.02 under \(k=20\) [2105.00542]. Although the paper studies auto-scaling rather than CVE triage, it uses the same VMS pattern of measurement, classification, decision, and policy actuation.

At network scale, mitigation analysis can be posed as a Stackelberg planning problem. Speicher et al. model the defender as choosing a subset of fixes \(x_f\in\{0,1\}\) under budget \(B\), after which the attacker chooses the feasible highest-probability attack path. The bilevel objective is

$$
\min_{x\in\{0,1\}^{|F|}}
\left\{
\max_{\pi\ \text{feasible in}\ s_N(x)} p(\pi)
\right\}
\quad\text{s.t.}\quad
\sum_{f\in F} c_F(f)x_f\le B.
$$

The output is a Pareto frontier of non-dominated \((C_F,p^*)\) pairs [1705.05088]. The evaluation reports coverage above 50% for up to 800 hosts with approximately 5 fixes per host, and above 50% up to 4 fixes per host as fixes per host grow [1705.05088]. Taken together, these systems show that VMS research often treats mitigation as a resource-allocation problem with explicit objective functions, whether the controlled variables are signatures, staff-hours, firewall changes, or autoscaling policies.

## 5. Agentic, LLM-assisted, and code-centric VMS architectures

Recent work uses LLMs not merely for classification but as active agents within vulnerability workflows. The 2025 VMS for autonomous penetration testing is organized as an iterative two-module agent—Planner and Summarizer—running inside a hardened Kali Linux container [2507.21113]. At each iteration, the Planner consumes the goal, recent command outputs, and action history to produce the next shell command; the Execution stage runs it; and the Summarizer compresses stdout/stderr into a bounded semantic state. The Planner uses temperature- and nucleus-sampling, with \(T\) swept from 0.2 to 2.0, \(p=0.9\), and up to 20 planning iterations per challenge. On two new CTF suites totaling 200 challenges, GPT-4o solves 41 of 120 PicoCTF tasks and 32 of 80 OverTheWire tasks, corresponding to 34.2% and 40.0% success, respectively [2507.21113]. The paper also emphasizes risk: high temperatures can produce unsafe or looping commands, the agent could be repurposed for malicious attacks, and safe execution therefore relies on containerization, strict firewall rules, a hard step limit, and audit logs.

AgenticVM applies agent decomposition to operational vulnerability management. Scanner outputs from Trivy, Snyk, and Grype, together with external databases such as NVD, EUVD, and CISA KEV, are routed through a Detection Agent, Assessment Agent, Prediction Agent, Integration Agent, Prioritisation Agent, and Recommendation Agent [2605.01739]. The Prediction Agent uses BERT-small with eight classification heads for CVSS v3.1 base metrics, trained on 169,883 deduplicated CVE records with an 80/10/10 split; the reported overall accuracy is 89.3% and F1 is 89.1% [2605.01739]. Prioritisation uses a default threshold \(\theta=7.0\), and the system reports up to 98% alert reduction, exemplified by reducing 3,983 findings to 82 items in Train-Ticket [2605.01739]. The architecture also formalizes a governance principle already implicit in earlier semi-automated systems: low-confidence predictions are flagged to human review, and destructive actions require human approval.

MAVM extends the agentic pattern into recurring-vulnerability detection and repair. It integrates five components—Vulnerability Knowledge Base, Detection Agent, Confirmation Agents, Repair Agents, and Validation Agent—into a pipeline that starts with disclosed vulnerabilities and target repositories and ends with confirmed vulnerabilities, locations, and generated patches [2601.17762]. The VKB stores CVE IDs, CWE categories, pre- and post-patch functions, patch diffs, and GPT-4o-generated analysis reports, including structured Analysis Points. Context retrieval uses tools built on `ripgrep` and Tree-sitter such as `find_function_defs`, `find_struct_defs`, `call_chain`, and `text_search`. On a dataset of 78 patch-porting cases covering 114 function-level migrations, MAVM successfully detects and repairs 51 real vulnerabilities and improves repair accuracy by 31.9%–45.2% over baselines [2601.17762].

CommitShield addresses an adjacent code-centric problem: tracking vulnerability introduction and fix in version control systems. It combines GitHub REST API metadata, Tree-sitter for AST-level function extraction, Joern for call-graph and CPG context, and Deep-Seek-V2.5 for description enrichment and commit classification [2501.03626]. In vulnerability fix detection on CommitVulFix, CommitShield achieves precision 0.81, recall 0.96, and F1 0.88, compared with 0.75 F1 for an LLM-only baseline, 0.32 for VulFixMiner, and 0.29 for VulCurator. In vulnerability introduction detection on the cleaned V-SZZ dataset, it reports precision 0.74, recall 0.82, and F1 0.78 [2501.03626]. These systems collectively indicate that the locus of mitigation is shifting upstream: a VMS may now generate commands, rank scanner findings, repair recurring flaws, or identify the commits that introduced exploitable code.

## 6. Design-time reasoning, isolation, and recurrent trade-offs

Not all VMS research is operational or data-pipeline oriented. “Automated Reasoning for Vulnerability Management by Design” formulates vulnerability management as finite first-order reasoning over components \(C\), component types \(T\), vulnerabilities \(V\), controls \(S\), and security rules \(R\) [2507.05794]. Candidate vulnerabilities for a component are

$$
\mathrm{CVULNS}(c)=\bigcup_{t\in\mathrm{TYPES}(c)}\mathrm{VULNS}(t),
$$

direct mitigation is expressed by \(\mathrm{MitigatedV}(v,c)\), indirect mitigation is captured recursively through an acyclic abstraction mapping \(\mathrm{AVULNS}\), and global safety is stated as

$$
\forall c\in C.\;\neg\,\mathrm{Vulnerable}(c).
$$

The implementation is integrated into the TRADES Tool as a reasoner over imported designs, vulnerability catalogs, and security rules [2507.05794]. Its strength is unambiguous semantics and architectural “shift left”; its limitation, explicitly stated in the paper, is that the model is Boolean and does not rank or score residual risk.

A different notion of mitigation appears in qOS, which protects end-user systems from vulnerable or malicious applications by transparently redirecting execution into a Quarantine VM [2211.02266]. qOS consists of a host-side qSecurityMonitor kernel module, a guest-side qAgent kernel module, and an `ivshmem` communication channel. Unsafe applications are executed in the qVM, files written by unsafe applications are tagged `user.qos_state=unverified`, and any host attempt to open an unverified file is denied with `EPERM` [2211.02266]. The enforcement invariant is explicit:

\[
\forall f\in F_{\text{unverified}},\ \forall p\in HostProcs:\ \mathrm{open}(p,f)=\mathrm{denied}.
\]

Empirically, the prototype on Linux+KVM reports full enforcement for host-side opens of unverified files, application-launch latencies under 100 ms, and lower CPU and memory overhead than VM-plus-NFS baselines in several workloads [2211.02266]. Here mitigation is not prioritization or patch selection, but confinement and safe access.

The literature therefore converges on several recurrent trade-offs. First, reduction of false positives often comes at the cost of some false negatives, whether by disabling signatures [1802.08915], applying strict applicability filters [2505.13895], or pruning scanner outputs into compact queues [2605.01739]. Second, fully automated normalization and matching remain error-prone, which explains the continued presence of user confirmation in IVA and human-in-the-loop governance in agentic systems [1705.05347]. Third, LLM-based components widen the action space of VMSs but simultaneously enlarge the safety problem, prompting containerization, confidence gating, schema validation, audit logging, and approval gates [2507.21113]. Finally, the term VMS now spans design-time, runtime, data-engineering, and repair-time interventions. A plausible implication is that future VMS research will be evaluated less by whether it uses a particular model class and more by how rigorously it closes the loop between vulnerability evidence, decision logic, operational constraints, and post-decision validation.

Source: https://www.emergentmind.com/topics/vulnerability-mitigation-system-vms