Vulnerability Mitigation System

• Vulnerability Mitigation Systems are security frameworks that reduce exposure to known threats by continuously collecting evidence and tuning defense mechanisms.
• They employ diverse methods such as optimization, Bayesian inference, reinforcement learning, and LLM-driven agents to balance performance, false positives, and maintenance costs.
• Architectural variants range from runtime reactive systems to design-time reasoning tools, integrating data normalization, ontology mapping, and human oversight for effective mitigation.

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 (Katz et al., 2018). In other formulations, the same term is applied to semi-automated CPE/CVE-based software checking (Sanguino et al., 2017), ontology- and ML-based hardware vulnerability mapping with root-cause analysis and GPT-assisted mitigation (Lin et al., 2023), deep reinforcement learning for sequential vulnerability prioritization (Hore et al., 2022), context-aware retrieval based on unified CPE modeling (Jiang et al., 20 May 2025), LLM-based autonomous penetration testing (Abdulzada, 14 Jul 2025), multi-agent adaptive software vulnerability management (Arifin et al., 3 May 2026), recurring-vulnerability detection and repair (Zheng et al., 25 Jan 2026), and formally grounded design-time reasoning over components, vulnerabilities, and controls (Shaked et al., 8 Jul 2025). 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 (Katz et al., 2018). IVA, by contrast, is built around inventory collection, candidate CPE generation and ranking, a mandatory user-assignment step, and two-pass CVE matching (Sanguino et al., 2017). 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 (Lin et al., 2023).

Later work further broadens the architectural range. Deep VULMAN formalizes weekly mitigation as an infinite-horizon MDP followed by integer-programming-based selection (Hore et al., 2022). VulCPE standardizes raw CPE strings into a unified CPE schema and performs graph-based applicability filtering over configuration dependencies (Jiang et al., 20 May 2025). AgenticVM decomposes vulnerability management into Detection, Assessment, Prediction, Integration, Prioritisation, and Recommendation agents, coordinated by LangGraph and fed by scanner outputs and external databases (Arifin et al., 3 May 2026). 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 (Katz et al., 2018). 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 $G$0. The optimization is

$G$1

subject to

$G$2

The second phase resolves overlap at the per-signature level through Bayesian inference. For each signature $G$3, a Bernoulli random variable $G$4 represents whether the mitigation is sampled, with a Beta prior $G$5. For each observed batch $G$6, coverage is defined by

$G$7

Expectation–Propagation then yields approximate posteriors $G$8, and the inferred $G$9 becomes the continuous sampling rate $\alpha_j$0. Operationally, $\alpha_j$1 means always enforce, $\alpha_j$2 means sample a fraction of matching packets or files, and $\alpha_j$3 means fully disabled (Katz et al., 2018).

Cost is modeled with performance overhead $\alpha_j$4, maintenance cost $\alpha_j$5, and explicit false-positive and false-negative objectives. The false-positive rate is defined as

$\alpha_j$6

and the false-negative rate as

$\alpha_j$7

These are combined into

$\alpha_j$8

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 $\alpha_j$9 (Katz et al., 2018). Timeliness is central to the design: ILP on $(day\ t, signature\ j, hit\text{–}yes/no)$0 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 (Sanguino et al., 2017). 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 (Sanguino et al., 2017).

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 (Lin et al., 2023). Vulnerability-to-weakness mapping uses cosine similarity

$(day\ t, signature\ j, hit\text{–}yes/no)$1

between vulnerability descriptions $(day\ t, signature\ j, hit\text{–}yes/no)$2 and CWE descriptions $(day\ t, signature\ j, hit\text{–}yes/no)$3, 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 (Lin et al., 2023). 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

$b_i$6

and standardizes raw CPE names using canonical dictionaries and a string-similarity function $(day\ t, signature\ j, hit\text{–}yes/no)$4, with $(day\ t, signature\ j, hit\text{–}yes/no)$5 and threshold $(day\ t, signature\ j, hit\text{–}yes/no)$6 (Jiang et al., 20 May 2025). The framework builds directed graphs $(day\ t, signature\ j, hit\text{–}yes/no)$7 and $(day\ t, signature\ j, hit\text{–}yes/no)$8 over uCPE entries and logical combinations such as $(day\ t, signature\ j, hit\text{–}yes/no)$9 and $G\in\{0,1\}^N$0, then performs subgraph matching to filter false positives under AND/OR applicability constraints. The reported retrieval performance is $G\in\{0,1\}^N$1 and $G\in\{0,1\}^N$2, exceeding the cited cve-search and OpenCVE baselines (Jiang et al., 20 May 2025).

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 (Janovsky et al., 2023). A reference graph $G\in\{0,1\}^N$3 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 (Janovsky et al., 2023). 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 $G\in\{0,1\}^N$4, where the state includes a padded matrix $G\in\{0,1\}^N$5 of normalized vulnerability attributes and the remaining staff-hour budget $G\in\{0,1\}^N$6, and the action is a continuous scalar $G\in\{0,1\}^N$7 denoting how many staff-hours to spend in that week (Hore et al., 2022). Reward combines the average attribute score of patched vulnerabilities and a penalty on consumed staff-hours:

$G\in\{0,1\}^N$8

The agent uses PPO with a Gaussian policy $G\in\{0,1\}^N$9, two hidden layers of 68 neurons with tanh, and a clipped objective. After the RL stage outputs the budget $R\in\{0,1\}^{N\times M}$0, an integer program selects the subset $R\in\{0,1\}^{N\times M}$1 subject to $R\in\{0,1\}^{N\times M}$2, maximizing average normalized attribute score (Hore et al., 2022). 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 (Hore et al., 2022).

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 $R\in\{0,1\}^{N\times M}$3, max_depth=1, and threshold $R\in\{0,1\}^{N\times M}$4 to declare an attack when $R\in\{0,1\}^{N\times M}$5 (David et al., 2021). On detection, the mitigation actuator delays scale-down by setting

$R\in\{0,1\}^{N\times M}$6

and can enforce a Pod-count floor $R\in\{0,1\}^{N\times M}$7 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 $R\in\{0,1\}^{N\times M}$8 (David et al., 2021). 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 $R\in\{0,1\}^{N\times M}$9 under budget $\alpha_j\in[0,1]$0, after which the attacker chooses the feasible highest-probability attack path. The bilevel objective is

$\alpha_j\in[0,1]$1

The output is a Pareto frontier of non-dominated $\alpha_j\in[0,1]$2 pairs (Speicher et al., 2017). 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 (Speicher et al., 2017). 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 (Abdulzada, 14 Jul 2025). 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 $\alpha_j\in[0,1]$3 swept from 0.2 to 2.0, $\alpha_j\in[0,1]$4, 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 (Abdulzada, 14 Jul 2025). 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 (Arifin et al., 3 May 2026). 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% (Arifin et al., 3 May 2026). Prioritisation uses a default threshold $\alpha_j\in[0,1]$5, and the system reports up to 98% alert reduction, exemplified by reducing 3,983 findings to 82 items in Train-Ticket (Arifin et al., 3 May 2026). 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 (Zheng et al., 25 Jan 2026). 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 (Zheng et al., 25 Jan 2026).

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 (Wu et al., 7 Jan 2025). 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 (Wu et al., 7 Jan 2025). 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 $\alpha_j\in[0,1]$6, component types $\alpha_j\in[0,1]$7, vulnerabilities $\alpha_j\in[0,1]$8, controls $\alpha_j\in[0,1]$9, and security rules $b_i$0 (Shaked et al., 8 Jul 2025). Candidate vulnerabilities for a component are

$b_i$1

direct mitigation is expressed by $b_i$2, indirect mitigation is captured recursively through an acyclic abstraction mapping $b_i$3, and global safety is stated as

$b_i$4

The implementation is integrated into the TRADES Tool as a reasoner over imported designs, vulnerability catalogs, and security rules (Shaked et al., 8 Jul 2025). 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 (Trivedi et al., 2022). 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 (Trivedi et al., 2022). The enforcement invariant is explicit:

$b_i$5

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 (Trivedi et al., 2022). 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 (Katz et al., 2018), applying strict applicability filters (Jiang et al., 20 May 2025), or pruning scanner outputs into compact queues (Arifin et al., 3 May 2026). 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 (Sanguino et al., 2017). 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 (Abdulzada, 14 Jul 2025). 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.