IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
1
HAVE: Host Active Verification Engine for Closing the Contextual Reality Gap in Security Digital Twins
arXiv:2606.06968v1 [cs.CR] 5 Jun 2026
Vincenzo Sammartino, Marco Pasquini Dipartimento di Informatica, Università di Pisa, Pisa, Italia E-mail: [email protected], [email protected]
✦
Abstract—Security Digital Twins (SDTs) provide continuously updated virtual replicas of infrastructure for threat simulation, yet they rely on theoretical CVSS scores to assign lateral-movement probabilities—creating the Contextual Reality Gap: risk is overestimated where unacknowledged mitigations neutralize exploits, and drastically underestimated where logic flaws bypass all memory-safety defenses. We present the Host Active Verification Engine (HAVE), an SDT extension that deploys a safety-constrained host agent to measure the empirical probability of compromise p̂ via maximum-likelihood estimation over snapshotisolated Bernoulli trials. A Wilson interval-width confidence weight αw propagates p̂ into Monte Carlo simulations via a Bayesian blending rule formally related to the Beta-Binomial posterior. Evaluation across four vulnerability classes, three security tiers, and two production binaries shows HAVE reduces Preach by 38.2% in false-positive scenarios and increases it by 132.4% in false-negative scenarios, with a net +124.1% correction; post-HAVE estimates vary by only 1.12× across calibration exponents κ, versus 4.6× for CVSS-only baselines.
SDT extension that measures host-specific exploitability empirically via snapshot-isolated Bernoulli trials. Key contributions: •
•
•
• •
Index Terms—Security Digital Twin, Active Verification, Exploitability Analysis, Risk Assessment, OT Safety, Monte Carlo Simulation, Memory Mitigations, Bayesian Update, Breach-and-Attack Simulation.
1
•
Contextual Reality Gap formalization: first formal definition and quantification of CVSS-vs-empirical divergence. Hub-and-Spoke architecture: cgroups v2 CPU cap, path allow-list confinement, and mTLS agent authentication. Two-phase methodology: granular static Defense Profile plus MLE-based dynamic p̂ and TTC estimation. Wilson confidence weighting: αw propagates p̂ via a Bayesian blend formally related to Beta-Binomial. Production binary validation: CVE-2021-3156 and CVE-2021-42013 confirm generalizability. Monte Carlo validation: five-node dual-path attack graph confirms non-linear propagation and κrobustness.
I NTRODUCTION
Context and Motivation. The convergence of IT and OT into Cyber-Physical Systems has fundamentally altered the threat landscape. Security operators require a continuous, high-fidelity infrastructure risk model [1], [2]. The Security Digital Twin (SDT) paradigm addresses this by maintaining a simulation-capable replica through passive network telemetry [3]–[5]. The passive approach avoids destabilizing legacy PLC hardware [6], but introduces a critical limitation: risk quantification relies on CVSS scores [7], [8]. The Contextual Reality Gap. CVSS provides a contextfree severity estimate: the same 9.8-rated stack overflow is empirically near-inert on a PIE+ASLR+Canary binary but trivially exploitable without those mitigations. Conversely, a command-injection flaw rated 7.2 remains unconditionally exploitable irrespective of memory-safety defenses [9], [10]. Without empirical host-level verification, the SDT simultaneously overestimates mitigated vulnerabilities and underestimates logic flaws. Proposed Solution and Contributions. We introduce the Host Active Verification Engine (HAVE), a feedback-driven
2
BACKGROUND
2.1
Security Digital Twins
An SDT is a continuously updated, graph-based representation G = (N , E), where each node ni ∈ N represents a host asset and each directed edge (ni , nj ) ∈ E represents a potential attack step, weighted by the probability pij that an adversary at ni can successfully compromise nj [11]– [13]. The SDT continuously ingests telemetry to update the graph. Simulation engines then traverse G to compute lateral-movement paths, reachability probabilities, and critical attack vectors. The accuracy of these simulations is directly bounded by the accuracy of the edge weights pij , which motivates the empirical measurement approach of HAVE [14], [15]. 2.2
Limitations of CVSS-Based Risk Scoring
CVSS v3.1 [7] quantifies vulnerability severity across three metric groups: Base, Temporal, and Environmental. The Base score reflects the intrinsic properties of a vulnerability.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
Temporal metrics account for exploit code maturity. Environmental metrics allow per-deployment customization through Modified Impact Metrics, and if correctly populated they partially account for host-specific mitigations. However, maintaining accurate per-host Environmental profiles incurs significant operational overhead, and in practice this sub-score is rarely populated [7], [16]. Two structural limitations make CVSS inadequate as a sole risk source for an SDT. First, the Base score is contextfree: it measures the worst-case scenario severity without accounting for host-specific mitigations. Second, CVSS does not distinguish between vulnerability classes that interact differently with mitigation mechanisms. A memorycorruption flaw and a command-injection flaw may share a similar CVSS score but have entirely different exploitability profiles depending on the presence of memory-safety features [17]. The Exploit Prediction Scoring System (EPSS) [18] partially addresses exploitability prediction using external threat intelligence signals, but it remains a population-level statistical model that does not reflect the specific configuration of an individual host. HAVE addresses this gap directly by automating the measurement of host-specific exploitability, yielding data equivalent to a fully populated Environmental Score without the manual profiling burden. 2.3
Host-Level Security Primitives
Modern Linux systems layer four complementary defenses against memory-corruption attacks [9]. ASLR randomizes stack, heap, and library base addresses at load time; its effectiveness requires PIE compilation, since a non-PIE binary loads its code segment at a fixed address regardless of kernel ASLR policy [19]. PIE and Full RELRO enable code-segment randomization and make the Global Offset Table read-only after dynamic linking, respectively. Stack Canaries [20] detect stack-frame corruption before returnaddress overwrite but offer no protection against heapsegment operations. NX/DEP prevents direct shellcode injection; attackers circumvent it via Return-Oriented Programming [21]. The interaction between these primitives — not their individual presence — determines actual exploitability, as formally captured by Ref f in Section 6.1.
3
R ELATED W ORK
3.1
Digital Twin Frameworks for Cyber-Resilience
Fuller et al. [4] provide a comprehensive survey of digital twin enabling technologies and identify security simulation as a primary application domain. Eckhart and Ekelhart [11] demonstrate a specification-based state-replication approach for CPS, establishing the principle that a twin should mirror runtime behavior rather than static configurations. Dietz and Pernul [12] integrate SDT simulations with Security Operations Centers, showing how automated attack playbooks can feed twin state updates. The NotLine framework [3], which HAVE extends, builds highfidelity network-layer twins through passive traffic analysis, avoiding destabilizing probes while maintaining topological accuracy. Baiardi et al. [22] augment the NotLine topology with Graph Neural Network-based risk inference; however, their approach still ultimately relies on CVSS-derived prior
2
weights, a limitation directly addressed by HAVE’s empirical measurements. 3.2 Network-Level Vulnerability Assessment Active network scanners such as Nmap [23] and OpenVAS [24] detect vulnerabilities by probing exposed services and comparing banners against CVE signatures. These tools operate externally and cannot directly observe the host’s internal security configuration. Banner-based fingerprinting is known to produce significant false-positive rates when service versions are not precisely identifiable [25]. More critically, external scanning is architecturally incompatible with OT environments: sending unexpected traffic to a programmable logic controller can trigger safety faults. HAVE avoids this by deploying an internal agent that never generates external network probes. 3.3 Host-Based Auditing and Configuration Management Agent-based auditing tools such as OSSEC and Wazuh maintain real-time inventories of installed packages and system configurations, alerting on deviations from a security baseline. While valuable, these tools perform static inventory rather than dynamic exploitability testing. They report the presence of a vulnerable library but cannot determine whether the vulnerable code path is reachable or whether existing mitigations render the vulnerability practically inert. HAVE’s static phase is conceptually analogous to hostbased auditing but is explicitly designed as the precursor to a dynamic phase that provides the missing exploitability verdict [17]. 3.4 Automated Exploit Generation Avgerinos et al. [26], [27] pioneered Automated Exploit Generation (AEG), demonstrating that symbolic execution can automatically generate working exploits for programs with known vulnerability classes. Shoshitaishvili et al. [28] provide a comprehensive taxonomy of binary analysis techniques applicable to exploitation. The critical distinction between AEG and HAVE lies in their objective: AEG discovers new exploitable conditions, whereas HAVE uses a curated library of pre-validated exploits to measure the efficacy of defenses against known vulnerability classes. This focus on “mitigation verification” makes HAVE applicable in production risk assessment contexts where the vulnerability is already known and the unknown quantity is its practical exploitability given the target host’s configuration. 3.5 Risk Quantification in Attack Graphs Attack graph formalisms [29], [30] model multi-step attack paths as directed graphs. Bayesian attack graphs [31], [32] extend this formalism by associating conditional probabilities with each attack step. McQueen et al. [33] introduce the Mean Time-to-Compromise metric as a complementary measure of attacker effort. Homer et al. [34] demonstrate methods for aggregating per-step vulnerability metrics into infrastructure-wide security scores. HAVE directly addresses the data-quality problem identified across this body of work: it replaces CVSS-derived, context-free edge weights with empirically measured, host-specific exploitability probabilities.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
3.6
Active Testing Safety in OT Environments
The risks of active security testing in CPS environments are well documented [1], [6], [35]. Muench et al. [6] demonstrate that software corruption in embedded systems does not manifest in observable crashes with the same reliability as in desktop systems. Corteggiani et al. [35] propose an emulation-based approach for security testing of embedded firmware. Our work is aligned with this philosophy: by mandating VM-based sandboxing in OT contexts and enforcing hard CPU caps via cgroups [36], HAVE ensures that active verification cannot propagate instability to production hardware. 3.7
Breach-and-Attack Simulation Platforms
Commercial Breach-and-Attack Simulation (BAS) platforms — including SafeBreach, AttackIQ, and XM Cyber — represent the closest class of prior work to HAVE’s operational objective of automated, agent-based exploit execution for security measurement. These platforms deploy agents that execute pre-defined attack scenarios against live infrastructure to measure whether security controls block or permit specific Tactics, Techniques, and Procedures (TTPs) as catalogued by MITRE ATT&CK [37]. HAVE is architecturally distinguished from this class of platforms along three fundamental dimensions. First, BAS platforms operate at the campaign and TTP level: they report pass/fail outcomes for discrete attack scenarios but do not produce statistically calibrated probability estimates over N I.I.D. trials that can be propagated as edge weights into a probabilistic attack graph. The Wilson confidence interval and the αw blending rule (Section 6.3) are methodologically absent from BAS platforms. Second, BAS platforms are not designed for integration with SDT risk models: their outputs are security control assessment reports, not parameterized edge-weight updates for Monte Carlo simulation engines. The feedback loop from HAVE’s empirical p̂ to the SDT’s Preach (n∗ ) is the architectural contribution absent in the BAS class. Third, BAS platforms do not address the OT safety constraints that are central to HAVE’s design: none of the platforms surveyed in the literature expose formal resource-governance interfaces (cgroups CPU capping), directory-based authorization allow-lists, or snapshot-isolation guarantees that prevent active testing from destabilizing production PLC firmware. In summary, BAS platforms and HAVE address complementary but non-overlapping portions of the security assessment problem: BAS provides breadth (TTP coverage across the kill chain), while HAVE provides depth (statistically rigorous, per-vulnerability, per-host exploitability quantification for SDT integration).
4
S YSTEM AND T HREAT M ODEL
4.1
System Model
We consider an enterprise or industrial infrastructure modeled as a graph G = (N , E) continuously maintained by an SDT. The node set N = NIT ∪ NOT includes both standard IT assets (servers, workstations, routers) and OT assets (PLCs, HMIs, SCADA servers). Each node ni has an associated security configuration σi comprising the kernel
3
ASLR state and the binary-level feature vector vbin as defined in Section 6.1. The passive monitoring layer continuously populates G by observing network telemetry. The HAVE Controller, embedded in the SDT’s analytics layer, augments this topological data with empirical exploitability data derived from host-level verification campaigns.
4.2
Adversary Model
We model a threat actor consistent with the MITRE ATT&CK framework [37]: Capability. The adversary has initial access to at least one compromised node n0 ∈ N and seeks to perform lateral movement to reach high-value targets. The adversary possesses a library of known exploits for public CVEs but does not have access to zero-day vulnerabilities. The adversary is resource-rational: given multiple potential attack paths, the adversary will select the path of minimum expected effort, quantified by Time-to-Compromise. Constraints. The adversary cannot modify the SDT’s model or inject false telemetry (the mTLS authentication model prevents spoofing, as detailed in Section 5). The adversary is not assumed to have physical access to the hardware. Zero-Day Scope. HAVE’s measurements cover the known-CVE attack surface constituting the primary threat against most deployments. Operators in critical infrastructure contexts should supplement HAVE with threatintelligence feeds providing early warning of emerging zero-day campaigns.
4.3
HAVE Safety Model
The introduction of active code execution into a production infrastructure carries inherent risks that must be addressed by the verification framework itself. We define three safety requirements: SR-1 (Resource Boundedness). The verification process must consume a bounded fraction of the target host’s CPU resources, preventing any Denial-of-Service (DoS) condition. SR-2 (Scope Confinement). The verification agent must only execute payloads against explicitly authorized targets, preventing repurposing as a lateral-movement tool. SR-3 (State Integrity). The verification process must not leave residual artifacts or system corruption on the target host after each trial. These requirements are formalized and enforced by the three safety mechanisms detailed in Section 5.
5
HAVE A RCHITECTURE
The Host Active Verification Engine is engineered as a feedback-driven extension of the SDT ecosystem. Rather than operating as a standalone scanner, HAVE is a tightly integrated component that receives triggers from the passive monitoring layer and returns empirical measurements that directly update the twin’s risk model.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
5.4 The Verification Agent: A Safety-Constrained Daemon
SECURITY TWIN CORE
HAVE Controller Orchestration & Scheduling
Task mTLS / X.509 Mutual Auth
4
p̂, TTC Telemetry
Allow-list
Verification Agent
cgroups v2
Auth. Module
Privileged Daemon
CPU Cap θmax
Snapshot S0
The Verification Agent is a lightweight privileged daemon. In IT contexts it may run directly on the host OS; in OT contexts, it is mandated to execute within a high-fidelity VM sandbox mirroring the production environment, ensuring that even a catastrophic verification failure cannot destabilize the physical hardware. The agent enforces three immutable safety constraints that directly satisfy requirements SR-1 through SR-3.
Restore-per-Trial
5.4.1 Resource Governance: CPU Capping (SR-1)
Exploit trial
Static Analysis
Target Binary Analysis Subject
Dynamic Testing
ISOLATED SANDBOX / VM
Fig. 1. HAVE System Architecture (Hub-and-Spoke). The Controller (navy) dispatches verification tasks over an mTLS channel. The Agent (amber) enforces an allow-list and a cgroups v2 CPU cap before interacting with the target binary. Each trial is preceded by a hypervisor snapshot restore (green) to guarantee I.I.D. trial conditions. Empirical telemetry (p̂, TTC) flows back to update the SDT’s risk model.
5.1
Design Principles
The architecture is governed by three principles derived from the safety model of Section 4: (i) Safety by Design, ensuring every code path within the agent is constrained by the three safety requirements; (ii) Minimal Footprint, deploying the lightest possible privileged process on the target host; (iii) Event-Driven Activation, triggering verification campaigns only in response to meaningful state changes detected by the passive layer (e.g., a new CVE published for a running service, or a configuration drift detected via telemetry), thereby minimizing unnecessary overhead. 5.2
Hub-and-Spoke Topology
The system is organized in a Hub-and-Spoke topology (Fig. 1). The Orchestration Controller (the Hub) resides within the SDT’s analytics layer. The Verification Agents (the Spokes) are deployed on or near the target assets. All communication traverses a mutually authenticated TLS channel. 5.3
The Orchestration Controller
The Controller translates high-level risk queries into discrete, atomic verification tasks. It maintains a dynamic registry of all active Verification Agents and manages campaign scheduling. The Controller operates in event-driven mode: verification campaigns are triggered by (i) detection of a new vulnerable service via passive telemetry, (ii) publication of a CVE affecting a catalogued asset, or (iii) an explicit operator request. This design avoids continuous, background exploitation attempts that would consume resources unnecessarily. Upon receiving results from an Agent, the Controller applies the Bayesian update rule (Section 6.3) to refine the edge weight pij in G , and propagates the updated simulation to the SDT’s risk dashboard. The Controller also maintains an audit log of all verification campaigns for compliance and forensic purposes.
The resource governance constraint is implemented via Linux cgroups v2 [36], which operates through the Completely Fair Scheduler (CFS) over discrete periods. Let ∆tCF S denote the CFS quota period (default 100 ms). For (k) each scheduler period k ∈ Z≥0 , let Texec denote the agent’s CPU execution time within that period. The discrete-time resource governance constraint is: (k)
∀k ∈ Z≥0 :
Texec ≤ θmax , ∆tCF S
(1)
where θmax ∈ (0, 1] is the maximum allowable CPU utilization fraction defined in the local configuration manifest. This constraint is enforced by writ ing θmax · ∆tCF S · 106 to the agent’s cgroup v2 leaf node at /sys/fs/cgroup/have.slice/cpu.max (e.g., for θmax = 0.25 and ∆tCF S = 100 ms: value “25000 100000”). The kernel scheduler throttles the agent process for the remainder of any period in which Eq. (1) is violated. A typical OT deployment sets θmax = 0.15, reserving 85% of CPU capacity for critical control logic. 5.4.2 Authorization Confinement: Path Allow-list (SR-2) Let Dallow = {d1 , d2 , . . . , dn } be the set of directory paths explicitly authorized in the agent’s root-of-trust configuration. Given a verification request targeting a binary at path ptarget , the agent applies a validation function: ( ACCEPT if ∃ di ∈ Dallow : ptarget ⊆ di V (ptarget ) = REJECT otherwise. (2) Prior to this check, ptarget is sanitized by resolving symbolic links and stripping directory-traversal sequences (../). Requests targeting system paths outside Dallow are summarily rejected and logged as security violations. This design mitigates the confused deputy attack, where a compromised Controller attempts to coerce the Agent into executing payloads on arbitrary system binaries [38]. 5.4.3 Cryptographic Identity: Mutual TLS (Security) The command-and-control channel between Controller C and Agent A is secured via mutually authenticated TLS (mTLS). Both entities must present valid X.509 certificates signed by an internal Certificate Authority CAint :
Verify(CertC , CAint ) ∧ Verify(CertA , CAint ) ⇒ Session(C, A). (3) This bidirectional authentication ensures that (i) the Agent accepts commands only from a verifiable Controller, and (ii)
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
the Controller ingests data only from verifiable Agents, preventing pollution of the SDT’s risk model with spoofed telemetry. 5.5
Security Twin Integration Loop
Upon completion of a verification campaign, the Controller updates the risk model as follows. Let eij ∈ E be the attack step from ni to nj whose weight was previously set to (0) pij derived from the CVSS score. The Bayesian blending rule (Eq. (12)) governs the weight assigned to the empirical estimate relative to the CVSS prior as a function of the Wilson confidence interval width. The updated graph G ′ is then provided to the Monte Carlo simulation engine.
6
A NALYSIS M ETHODOLOGY
The methodological core of HAVE is predicated on the assertion that risk is a dynamic function of the execution environment, not a static property of the vulnerable code. HAVE implements a two-phase pipeline that sequentially evaluates the theoretical defense posture (Phase I: Static Analysis) and the empirical resistance (Phase II: Dynamic Analysis). 6.1
Phase I: Granular Static Analysis
The objective of Phase I is to construct a high-resolution Defense Profile Πi for the target binary, providing both a theoretical risk ceiling and the input parameters that configure the subsequent dynamic phase. Kernel Configuration. The Agent reads the kernel ASLR policy from /proc/sys/kernel/randomize_va_space, obtaining αkern ∈ {0, 1, 2}. Binary-Level Feature Extraction. Using the checksec [39] functionality of pwntools [40], the Agent parses the target binary’s ELF headers to extract the binary feature vector:
vbin = ⟨βpie , γcan , δnx , ϵrelro ⟩,
(4)
5
6.2
Phase II: Empirical Dynamic Analysis
Phase II subjects the target binary to a statistically rigorous sequence of controlled exploit trials. I.I.D. Trial Design. Dynamic exploitation is inherently destabilizing. A failed exploit may leave the process in an undefined state. To ensure that each trial is drawn from the same distribution, we model the verification sequence as a set of I.I.D. Bernoulli trials T = {t1 , t2 , . . . , tN } and enforce independence via a Restore-per-Trial protocol. Let S0 be the ReadyState snapshot of the VM, captured immediately after the target binary is loaded and ready for exploitation. The execution flow for each trial ti is: Execute(ti ) ← Restore(S0 ) ◦ RunExploit(payload). (7) This guarantees that system entropy, memory layout, and file descriptors are reset to an identical baseline before every trial, satisfying SR-3. Metric Derivation. Each trial ti yields a binary outcome xi ∈ {0, 1}, where xi = 1 denotes successful compromise (verified by matching an expected exit code, e.g., spawning a controlled shell). Upon completion of N trials, the Empirical Probability of Compromise p̂ is computed via Maximum Likelihood Estimation for a Binomial model. Let P S= N i=1 xi : S p̂ = . (8) N A 95% Wilson score confidence interval [p̂L , p̂U ] accompanies p̂: q p̂) z2 z2 p̂ + 2N ∓ z p̂(1− + 4N 2 N p̂L,U = , (9) z2 1+ N where z = 1.96 for a 95% confidence level. Additionally, the Time-to-Compromise is computed over successful trials K = {i | xi = 1}: 1 X τi , (10) TTC = |K| i∈K where τi is the wall-clock execution latency of trial ti . Following McQueen et al. [33], TTC serves as a proxy for attacker effort.
where βpie , γcan , δnx ∈ {0, 1} indicate PIE, Stack Canary, and Non-Executable memory status, respectively, and 6.3 Risk Model Integration: Monte Carlo Simulation ϵrelro ∈ {0, Partial, Full} indicates the RELRO level. The The SDT’s simulation engine models lateral movement via Agent additionally scans the binary’s symbol table for Monte Carlo traversal of G . In each simulation run, each _FORTIFY_SOURCE instrumentation. edge eij is sampled as a Bernoulli trial with success probaEffective Randomization. A critical methodological bility pij . After M simulation runs (typically M = 10,000), point is that kernel ASLR and binary PIE are not indethe fraction of runs in which the adversary reaches a target pendent: their interaction determines the actual degree of node n∗ estimates the end-to-end compromise probabiladdress-space randomization. We define the Effective Ranity Preach (n∗ ). domization: ( High if αkern ≥ 1 ∧ βpie = 1 6.3.1 CVSS-to-Probability Mapping and Calibration ExpoRef f = f (αkern , βpie ) = nent Low otherwise. (5) Prior to HAVE integration, edge weights are initialized from A kernel ASLR setting of 2 with a non-PIE binary (βpie = 0) CVSS scores via the monotone power mapping: CVSS κ yields Ref f = Low, since the code segment loads at a deij (0) pij = , (11) terministic address. This interaction is precisely the nuance 10 that CVSS and static inventory tools fail to capture. where κ > 0 is a calibration exponent governing the concavThe complete Defense Profile is: ity of the mapping. We adopt κ = 1 as the baseline param (0) Πi = αkern , vbin , Ref f , FORTIFY . (6) eterization, yielding a linear mapping pij = CVSSij /10.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
This choice is consistent with prior work [32] and has a natural interpretation: the CVSS score normalized to [0, 1] serves directly as the prior probability of exploitation. We note that κ < 1 compresses mid-range scores toward 1 (i.e., more pessimistic prior), while κ > 1 expands them toward 0 (more optimistic prior). A sensitivity analysis over κ ∈ {0.5, 1.0, 1.5, 2.0} is presented in Section 9.7, demonstrating that post-HAVE risk estimates are robust to this parameterization choice, while the CVSS-only baseline varies substantially. 6.3.2 Bayesian Blending Rule HAVE replaces the CVSS prior with the empirical posterior: (0)
pij ← αw · p̂ + (1 − αw ) · pij ,
(12)
where αw ∈ [0, 1] is a confidence weight defined as a monotone-decreasing function of the Wilson interval width: αw = 1 − p̂U − p̂L . (13) As N → ∞, the Wilson width vanishes and αw → 1, so the posterior converges to the empirical estimate; for small N , αw defaults toward the CVSS prior. 6.3.3 Formal Relationship to the Beta-Binomial Posterior The Bayesian-canonical treatment assigns a Beta prior pij ∼ (0) (0) Beta(α0 , β0 ) with α0 = pij · n0 and β0 = (1 − pij ) · n0 , yielding a posterior mean of the same convex-combination BB form as Eq. (12) with weight αw = N/(n0 + N ). The BB critical distinction is that αw depends only on N for fixed n0 , whereas the Wilson-width weight αw is statedependent: it depends jointly on N and p̂. This is epistemically superior for risk assessment: when HAVE observes extreme outcomes (p̂ ∈ {0, 1}), the Wilson interval is narrow even at moderate N , correctly assigning high confidence to the empirical estimate, while a uniform 50/50 outcome at the same N produces a wide interval and appropriately discounts the prior. In all experiments reported here N ≥ 30, bounding the maximum Wilson width to 0.364 and ensuring αw ≥ 0.636 throughout.
7
I MPLEMENTATION
7.1
Agent Implementation
The Verification Agent is implemented as a Python daemon communicating with the Controller over gRPC with mutual TLS. The exploit execution module uses pwntools [40] as the primary binary interaction framework. The static analysis module invokes checksec [39] programmatically via subprocess and parses the JSON output into a structured Defense Profile Πi . Hypervisor snapshot management is implemented via the libvirt API, supporting QEMU/KVM and VMware ESXi backends. The cgroups v2 CPU quota is written to /sys/fs/cgroup/have.slice/cpu.max at agent initialization. 7.2
Exploit Library and Self-Test Harness
The dynamic testing module is supplied by a curated exploit library implementing benign payloads for each supported vulnerability class. A benign payload demonstrates a successful compromise (e.g., achieving arbitrary code execution
6
and writing a controlled flag value to a predetermined memory address) without performing any destructive, persistent, or network-propagating action. The library currently comprises 12 exploit modules (3 per vulnerability class, one per security tier), totaling approximately 2,400 lines of Python. Each module is parameterized by the Defense Profile Πi , selecting among exploitation strategies at runtime based on Ref f and vbin . Each module includes a self-test harness that validates correct exploit behavior on a purpose-built reference environment before any production deployment. The self-test procedure proceeds as follows: (i) the module is executed against a reference VM (Ubuntu 22.04, same kernel version and security tier as the target configuration) whose groundtruth exploitability is known a priori from the vulnerability class design; (ii) the harness verifies that the benign payload writes the expected 8-byte flag to a predetermined address in the BSS segment; (iii) the harness confirms that the target process terminates cleanly (exit code 0) and that no residual file-system artifacts are created; and (iv) for stochastic exploits, the harness additionally validates that the observed success rate over a reference run of Nref = 30 trials falls within the expected range for the tier (e.g., p̂ = 0.00 for a fully-protected High-tier binary, or p̂ > 0.90 for a Lowtier binary). Self-test failures block module deployment and raise an alert via the Controller audit log. Library versioning follows semantic versioning: new vulnerability classes increment the MINOR version; new exploitation techniques increment PATCH. An important scope boundary is the following: the exploit library measures the exploitability of a vulnerability class using specific, implemented exploit techniques rather than the exploitability of the vulnerability class in the abstract. The measured p̂ is therefore bounded above by the quality and completeness of the library’s exploit implementation for the specific tier. For example, the format-string Hightier estimate of p̂ = 0.33 reflects the efficacy of the specific address-leakage strategy implemented, not a universal ceiling on all possible format-string exploits. Operators should treat p̂ as a lower bound on exploitability under the modeled adversary capability level, consistent with the threat model of Section 4. 7.3
Testbed Configuration
All experiments were conducted on an Ubuntu 22.04 LTS host (kernel 5.15, x86-64) with 8 CPU cores and 16 GB RAM, running the Verification Agent inside a QEMU/KVM virtual machine allocated 2 vCPUs and 2 GB RAM. The CPU cap was set to θmax = 0.25 during verification campaigns. A ReadyState snapshot S0 was created for each vulnerability tier immediately after binary loading, and restored via libvirt API before every trial. The mean snapshot restore latency was 98 ± 12 ms. It is important to contextualize this latency correctly. The 98 ms restore latency affects the duration of the overall verification campaign (i.e., the calendar time required to complete N trials for a given vulnerability), not the PLC control loop. Since verification campaigns are triggered by CVE publication events (which occur at most on the order of days) and are executed against VM replicas rather than the
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
physical hardware, the latency has no operational impact on real-time PLC control. Standard PLC scan cycles of 1– 100 ms apply to the physical controller; the VM replica’s timing fidelity is relevant only to the interpretation of TTC values, which we explicitly qualify as relative ordering metrics (Section 10.3). 7.4
Computational Overhead Characterization
To confirm enforcement correctness, CPU utilization was measured via perf stat at 1 Hz across all campaigns. Mean utilization ranged from 5.3% (Logic Flaw) to 16.5% (Format String, High tier); the highest instantaneous value observed was 23.4%, providing a 6.6-point margin below the θmax = 0.25 cap. Memory footprint remained below 170 MB (dominated by pwntools process space); read IOPS were below 60, driven by snapshot-restore operations. 7.5
Production Binary Validation
To validate that the mitigation-effectiveness patterns identified in the synthetic corpus generalize to real-world software, we conducted additional experiments on two production binaries with registered CVE identifiers. These were selected to match the two most operationally significant findings: the complete neutralization of memory-corruption exploits by full PIE+ASLR (heap class), and the unconditional exploitability of logic flaws across all security tiers [41]. CVE-2021-3156 (sudo “Baron Samedit”). CVE-2021-3156 is a heap-based buffer overflow in the sudoedit command of sudo ≤ 1.9.5p1, disclosed in January 2021 with a public proof-of-concept exploit. The flaw arises from improper handling of a trailing backslash in command-line argument parsing, leading to a heap buffer overflow that can be leveraged to achieve privilege escalation to root. We installed sudo 1.8.31 from the Ubuntu 20.04 LTS package repositories (CVSS Base Score: 7.8). Experiments were conducted at two protection levels aligned with our tier definitions: •
•
Low-equivalent (sudo compiled without PIE; ASLR disabled via randomize_va_space=0): The public proof-of-concept exploit succeeded with p̂ = 1.00 (N = 50, Wilson CI [0.929, 1.000], TTC = 22.1 ± 3.4 ms). The higher TTC relative to the synthetic heap Low-tier (15.8 ms) reflects process-fork overhead inherent to the sudo architecture. High-equivalent (Ubuntu 20.04 default: PIE-enabled sudo binary; ASLR = 2): The exploit failed with p̂ = 0.00 (N = 100, Wilson upper bound 0.037). The exploit relies on predictable heap-chunk offsets derived from a non-randomized heap base address; full PIE randomizes these offsets, invalidating the hardcoded chunk distances.
These results are quantitatively consistent with the synthetic heap UAF findings (Low: p̂ = 1.00; High: p̂ = 0.00), confirming that the vulnerability class-level mitigationeffectiveness pattern — specifically, the architectural transparency of stack canaries to heap-segment exploits and the efficacy of PIE-based address randomization — generalizes from the controlled synthetic corpus to a production binary with a registered CVE.
7
CVE-2021-42013 (Apache httpd Path Traversal + RCE). CVE-2021-42013 is a path traversal and remote code execution vulnerability in Apache httpd 2.4.49 and 2.4.50, enabling command injection via crafted HTTP requests against mod_cgi-enabled servers. The CVSS Base Score is 9.8. We deployed Apache 2.4.49 on the testbed VM with mod_cgi enabled; the binary was compiled under each of the three tier configurations of Table 2. In all three tiers, p̂ = 1.00 (N = 30, Wilson CI [0.884, 1.000], TTC = 5.1 ± 0.4 ms). The TTC is slightly higher than the synthetic command-injection result (3.2 ms) due to the HTTP request/response overhead inherent to a networklayer exploit. The marginal increase in TTC is negligible relative to the inter-tier constancy, confirming the core finding: command injection exploitability is orthogonal to all memory-safety mitigations, regardless of whether the target is a purpose-built synthetic program or a production HTTP server. Table 1 summarizes the production binary results in comparison with the corresponding synthetic findings. The consistency across both vulnerability classes and both production binaries provides empirical substantiation for the generalizability of the Contextual Reality Gap patterns reported in Section 9. TABLE 1 Production Binary Validation: HAVE Results for Production CVEs vs. Synthetic Corpus Target
Tier
p̂
95% CI
TTC (ms)
CVE-2021-3156 (sudo, Heap)
Low-eq.
1.00
CVE-2021-3156 (sudo, Heap)
High-eq.
0.00
CVE-2021-42013 (Apache)
Low
1.00
CVE-2021-42013 (Apache)
Med
1.00
CVE-2021-42013 (Apache)
High
1.00
[0.929, 1.000] [0.000, 0.037] [0.884, 1.000] [0.884, 1.000] [0.884, 1.000]
22.1 ± 3.4 — 5.1 ± 0.4 5.1 ± 0.4 5.1 ± 0.5
Synth. Heap
Low
1.00
Synth. Heap
High
0.00
Synth. Logic
All
1.00
[0.929, 1.000] [0.000, 0.037] [0.884, 1.000]
15.8 ± 2.4 — 3.2 ± 0.3
TTC differences reflect process-launch overhead; p̂ statistically indistinguishable.
8
E XPERIMENTAL E VALUATION
8.1
Vulnerability Corpus and Ecological Validity
We developed four custom C programs, each isolating a canonical vulnerability class. hotel_manager contains a stack-based buffer overflow in its input-parsing routine. block_notes contains a format-string vulnerability from unchecked printf usage, exposing both an arbitrary-write primitive (%n) and an arbitrary-read primitive (%p) [42]. mem_allocation_misuse contains a heap Use-AfterFree flaw architecturally unaffected by stack-frame protections [43]. logging_system contains a command-injection flaw from unsanitized input passed to system(), orthogonal to all memory-protection mechanisms. The synthetic corpus is a controlled measurement instrument that eliminates confounding variables present in real binaries (partial patches, inlining optimizations, library dependencies); the mitigation-effectiveness patterns generalize to production software as substantiated in Section 7.5.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
Each program maps to representative NVD entries instantiating the same class: hotel_manager to CVE-20157547 and CVE-2021-3156; block_notes to CVE-2012-0809; mem_allocation_misuse to CVE-2022-2602 and CVE2023-0461; logging_system to CVE-2021-42013 and CVE2023-25157. Author-estimated CVSS scores (Fig. 2) were assigned following the NVD scoring methodology by two CVSS v3.1-certified researchers; inter-rater agreement yielded Cohen’s weighted κw = 0.87 (95% CI [0.79, 0.95]). Disagreements were resolved by consensus using the NVD online calculator; a ±0.3 CVSS sensitivity band is marked in Fig. 2. 8.2
8
TABLE 3 HAVE Empirical Results: p̂ and TTC by Vulnerability Class and Security Tier (N trials per combination) Vuln.
Stack Overflow
Format String
Heap (UAF)
Security Tiers
Each program was compiled in three distinct security tiers summarized in Table 2. The tiers model a realistic progression of hardening from unprotected legacy binaries to fully hardened production deployments.
Logic Flaw
Tier
N
p̂
95% CI
TTC (ms)
Low
100
1.00
Medium
100
0.20
High
100
0.00
[0.963, 1.000] [0.133, 0.289] [0.000, 0.037]
12.4 ± 1.1 52.7 ± 8.3 —
Low
100
1.00
Medium
100
0.67
High
100
0.33
[0.963, 1.000] [0.573, 0.754] [0.246, 0.427]
9.1 ± 0.8 28.5 ± 4.6 71.2 ± 12.1
Low
50
1.00
Medium
50
1.00
High
100
0.00
[0.929, 1.000] [0.929, 1.000] [0.000, 0.037]
15.8 ± 2.4 16.1 ± 2.7 —
Low
30
1.00
Medium
30
1.00
High†
100
1.00
[0.884, 1.000] [0.884, 1.000] [0.963, 1.000]
3.2 ± 0.3 3.3 ± 0.4 3.2 ± 0.3
CI: Wilson score interval. TTC: mean ± std. dev. over successful trials.
TABLE 2 Security Tier Compilation Matrix
8.3
† N = 100 to certify p̂ = 1.00 at p̂
Tier
NX
Canary
PIE
RELRO
ASLR
Low (L)
✗
✗
✗
None
Off
Medium (M)
✓
✓
✗
Partial
On
High (H)
✓
✓
✓
Full
On
Protocol Parameters and Statistical Power Analysis
The choice of N follows a prospective power analysis targeting a Wilson confidence interval half-width of ε ≤ 0.10 for non-deterministic outcomes. The worst case (p = 0.5) requires N ≥ 96.04, rounded to N = 100. This value was applied uniformly to all stack-overflow and formatstring combinations where ASLR-dependent stochasticity makes the outcome genuinely variable. For heap UAF at Low and Medium tiers — where outcomes are deterministic by design — N = 50 suffices, yielding a Wilson lower bound of 0.929 for p̂ = 1.00. For logic-flaw combinations, which are fully deterministic across all tiers (p̂ = 1.00 unconditionally), N = 30 is retained, with a Wilson lower bound of 0.884. 8.4
Baseline Comparison: HAVE versus OpenVAS
OpenVAS reported the High-tier stack-overflow binary as Critical (CVSS 9.8), corresponding to p = 0.85 in the SDT — a 100% false-positive relative to HAVE’s measured p̂ = 0.00 (Wilson UB 0.037). For the command-injection binary, OpenVAS assigned identical Critical severity, providing no basis for distinguishing unconditional from conditional exploitability.
9
R ESULTS AND A NALYSIS
Table 3 summarizes the core quantitative findings. Fig. 2 illustrates the resulting Contextual Reality Gap. CVSS Base Scores on the x-axis are author-estimated following the NVD scoring methodology (inter-rater κw = 0.87; see Section 8.1) and are not retrieved from the NVD because the synthetic programs do not correspond to registered CVEs.
9.1
L = 0.963 (§8.3).
Stack Overflow: The Wall of Randomization
At Low tier, the exploit succeeds with p̂ = 1.00 and TTC 12.4 ms. The Medium tier reduces p̂ to 0.20 via partial canary brute-forcing on the fixed code-segment address of the non-PIE binary; the 300% TTC increase to 52.7 ms reflects this overhead. At High tier, PIE and Full RELRO yield p̂ = 0.00 over N = 100 trials; the Wilson upper bound of 0.037 constitutes a probabilistic certificate, not a deterministic guarantee. 9.2 Format String: Bypassing Mitigations via Information Leakage The format-string class reveals intrinsic resilience against address randomization. A format-string bug provides an arbitrary-read primitive (%p) that leaks a runtime base address from the stack, dynamically computing offsets and bypassing PIE entirely. Consequently, the High tier retains p̂ = 0.33 (CI [0.246, 0.427]), with randomization increasing exploit complexity (TTC: 9.1 → 71.2 ms) but not constituting a deterministic barrier. 9.3
Heap Corruption: The Failure of Partial Protections
The UAF class provides the most instructive finding on mitigation specificity. Low-to-Medium transition yields no change in exploitability (p̂ = 1.00 at both tiers; statistically indistinguishable TTC), since stack canaries are architecturally transparent to heap-segment operations [9]. Only Full PIE at High tier eliminates the exploit (p̂ = 0.00). A security dashboard reporting green checksec status for a Medium-tier binary provides dangerously false assurance against this vulnerability class. 9.4
Logic Flaws: The Universal Blind Spot
Command injection yields p̂ = 1.00 across all three tiers with constant TTC ≈ 3.2 ms; the N = 100 High-tier run tightens the Wilson lower bound to 0.963. Memory-safety mechanisms are entirely orthogonal to this attack vector.
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
9 Path A
Logic Zone
Empirical Exploitability p̂
Hp L
Fmt L
n1
Stk L
1.0 Logic (all)
Internet
0.8
0.85
0.88
n3
0.6
0.72
0.45
n∗4
0.75
n2
P
Mitig. Zone Fmt H
0.2
5
SCADA
CRG
l de mo ive ass
0.4
Int. App.
n0
Fmt M
0.0
Stk H
6 7 8 9 10 CVSS Base Score (author-est.; κw =0.87) Passive model
±0.3 CVSS band
High protection
Medium protection
Fig. 2. Quantifying the Contextual Reality Gap (CRG). Empirical p̂ vs. theoretical CVSS score (author-estimated; κw = 0.87, §8.1). Shaded band: ±0.3 scoring uncertainty. Mitig. Zone: hardened high-CVSS vulns rendered practically inert. Logic Zone: p̂ = 1.0 irrespective of mitigations. The double-headed arrow marks the CRG span.
Mitigation Effectiveness Matrix
Table 4 confirms that no single mitigation provides broad coverage: the security of a host is a property of the intersection of its mitigations and the specific class of vulnerability present. TABLE 4 Mitigation Effectiveness by Vulnerability Class ASLR only
Path B
Stk M
Low / no protection
9.5
DMZ Web
NX
Canary
PIE+RELRO
Stack Overflow
Partial
Strong
Partial
Full
Format String
Partial
None
Bypassed
Partial
Heap (UAF)
Partial
None
Partial
Full
Logic Flaw
None
None
None
None
9.6 End-to-End Monte Carlo Validation on a Dual-Path Attack Graph 9.6.1 Topology and Pre-HAVE Configuration To demonstrate the non-linear propagation properties of the Bayesian update across a structurally complex attack graph, we evaluate Preach (n4 ) on the five-node attack graph GM C (Fig. 3) representing a canonical OT infiltration scenario: node n0 is the adversary’s initial internet-facing foothold. n1 is the DMZ web application server hosting a stackoverflow vulnerability at the High security tier (CVSS 8.5, (0) p01 = 0.85). n2 is a secondary internet-facing server subject to command injection with no environmental scoring ap(0) plied (CVSS 7.2, p02 = 0.72). n3 is the internal application convergence node, reachable from n1 via a format-string (0) (0) CVE or from n2 via a heap-UAF CVE (p13 = 0.88, p23 = 0.75; CVSSs 8.8 and 7.5, respectively). Finally, n4 = n∗ is the SCADA HMI target, reachable exclusively through n3 and subject to a partially environmental-scored command(0) injection CVE (p34 = 0.45). The graph exhibits two structurally distinct parallel paths from n0 to the convergence node n3 : Path A (n0 →
Secondary
Fig. 3. Five-Node Dual-Path Attack Graph GM C . n0 : attacker foothold; n1 : DMZ web server (Stack Overflow, High); n2 : secondary server (Command Injection, none); n3 : internal convergence node (OR, reachable via Path A or Path B); n∗4 = n∗ : SCADA HMI target. Edge labels show pre-HAVE CVSS-derived weights.
n1 → n3 , involving a memory-corruption exploit chain) and Path B (n0 → n2 → n3 , involving a logic-flaw exploit followed by a heap corruption exploit). The target n4 is reachable only through n3 (an OR convergence node: compromise of n3 via either path is sufficient). This topology is specifically designed to expose the non-linear interaction between false-positive and false-negative corrections across an infrastructure with competing attack paths: the nonlinear Preach update across the parallel structure cannot be obtained analytically as a product of edge probabilities and provides a genuine use case for the Monte Carlo simulation engine. The pre-HAVE baseline Preach (n4 ) is computed via Monte Carlo simulation (M = 10,000 runs): (0) (0) (0) (0) P (n3 reached)(0) = 1 − 1 − p01 p13 1 − p02 p23 = 1 − (1 − 0.85×0.88)(1 − 0.72×0.75) = 0.884, (14) (0)
Preach (n4 ) = 0.884 × 0.45 = 0.398. 9.6.2
(15)
HAVE-Derived Edge Weights
The HAVE measurements (Section 9) yield the following updated edge weights via Eq. (12): (HAVE)
= 0.963 × 0.00 + 0.037 × 0.85 = 0.031 [αw =0.963, N =100, p̂=0.00]
(HAVE)
= 0.884 × 1.00 + 0.116 × 0.72 = 0.968 [αw =0.884, N =30, p̂=1.00]
(HAVE)
= 0.819 × 0.33 + 0.181 × 0.88 = 0.429 [αw =0.819, N =100, p̂=0.33]
(HAVE)
= 0.929 × 1.00 + 0.071 × 0.75 = 0.982 [αw =0.929, N =50, p̂=1.00]
(HAVE)
= 0.884 × 1.00 + 0.116 × 0.45 = 0.936 [αw =0.884, N =30, p̂=1.00]
p01 p02 p13 p23 p34
9.6.3
Monte Carlo Scenarios and Results
Table 5 reports three update scenarios evaluated over M = 10,000 simulation runs. Scenarios A and B isolate the effect of updating a single path’s edges while holding the complementary path at its pre-HAVE values, thereby exposing the individual contributions of the false-positive correction
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
(Path A) and the false-negative correction (Path B) independently. Scenario C performs the operationally realistic simultaneous update of all five edges. Scenario A (Path A corrected; Path B unchanged). Updating only p01 and p13 suppresses Path A (the memory(0) (0) corruption chain) from a contribution of p01 p13 = 0.748 to (HAVE) (HAVE) p01 p13 = 0.013: (A) Preach (n4 ) = 1−(1−0.013)(1−0.540)
× 0.45 = 0.246 (−38.2%).
(16)
This result demonstrates that HAVE correctly suppresses the false-positive attack path; however, the continued preHAVE assessment of Path B masks the true risk elevation along that path. Scenario B (Path B corrected; Path A unchanged). Updating p02 , p23 , and p34 elevates Path B (the logic-flaw/heap (0) (0) (HAVE) (HAVE) chain) from p02 p23 = 0.540 to p02 p23 = 0.951: (B) Preach (n4 ) = 1−(1−0.748)(1−0.951)
× 0.936 = 0.925 (+132.4%).
(17)
This result quantifies the severity of false-negative underestimation: the CVSS-only model, which partially credited memory-safety mitigations for the n2 → n3 hop and applied environmental scoring to p34 , underestimated the true Path B risk by a factor of 3.8. Scenario C (Full simultaneous HAVE update). Updating all five edges simultaneously: (C) Preach (n4 ) = 1−(1−0.031×0.429) (1−0.968×0.982) ×0.936
= 0.891 (+124.1%).
(18)
10
9.7
Sensitivity Analysis: Robustness to κ
Table 6 presents the sensitivity of pre- and post-HAVE Preach (n4 ) to the CVSS-to-probability calibration exponent κ ∈ {0.5, 1.0, 1.5, 2.0} under Eq. (11). The post-HAVE values are computed via Eq. (12) for the full simultaneous update (Scenario C of Table 5). Two observations are central. First, the pre-HAVE Preach varies by a factor of 4.6 across the tested range (0.140 at κ = 2.0 vs. 0.647 at κ = 0.5), confirming the reviewer’s concern that the CVSS-only baseline is highly sensitive to prior parameterization. Second, and crucially, the post-HAVE Preach varies by only a factor of 1.12 over the same range (0.831 at κ = 2.0 vs. 0.935 at κ = 0.5), since the empirically measured p̂ values enter with weight αw ≥ 0.819 and the prior only influences the small complementary term (0) (1 − αw )pij . This demonstrates that HAVE’s empirical corrections are robust to prior parameterization: regardless of the analyst’s choice of κ, the post-HAVE risk estimate converges to a stable value grounded in the measured exploitability data. The qualitative conclusion (CVSS-only risk is substantially underestimated for this infrastructure due to Path B false negatives) is invariant across the entire tested range. TABLE 6 Sensitivity Analysis: Pre- and Post-HAVE Preach (n4 ) as a Function of CVSS Calibration Exponent κ κ
Pre-HAVE Preach
Post-HAVE Preach
Abs. Correction
Rel. Correction
0.5
0.647
0.935
1.0
0.398
0.891
1.5
0.238
0.857
2.0
0.140
0.831
+0.288 +0.493 +0.619 +0.691
+44.5% +124.1% +260.1% +493.6%
Range
4.62×
1.12×
—
—
Range: ratio of maximum to minimum Preach value across the four κ values.
The net result is a 124.1% increase in estimated risk, despite the simultaneous suppression of Path A. This finding is operationally significant: a security operator relying on the CVSS-only model would judge this infrastructure at approximately 40% risk (0.398), whereas the true risk after HAVE correction is approximately 89% (0.891). The false-negative effect (logic flaws and heap corruption along Path B) dominates the false-positive correction (hardened memory corruption along Path A) due to the high base CVSS scores on Path B edges creating a structural underestimation amplified across parallel path combination. The Monte Carlo engine is essential for computing this nonlinear interaction: the product form applicable to a linear chain is inapplicable to the dual-path OR topology. TABLE 5 Monte Carlo Validation on GM C (M = 10,000; Fig. 3) Scenario
Edges Updated
Preach
vs. Baseline
Pre-HAVE
None
0.398
—
—
A: Path A
p01 , p13 p02 , p23 , p34 All 5 edges
0.246
−38.2% +132.4% +124.1%
FP correction
B: Path B C: Full HAVE
0.925 0.891
A/B isolate FP/FN corrections independently; C is the full update.
Effect
FN correction Net
Post-HAVE Preach values computed under Scenario C (full simultaneous update, Table 5).
10
D ISCUSSION
10.1
Impact on the SDT’s Risk Model
The results of Section 9 demonstrate that HAVE systematically recalibrates edge weights in the SDT’s attack graph in ways that CVSS-only priors cannot approximate. The Monte Carlo validation on GM C (Table 5) shows that a security operator relying exclusively on CVSS-derived edge weights would substantially misjudge the risk profile of this infrastructure. The false-negative correction (+132.4% from Scenario B) exposes the severe underestimation that arises when environmental scoring credits memory-safety mitigations that are architecturally irrelevant to the exploited attack class. The κ-sensitivity analysis demonstrates that this finding is independent of the specific linear prior mapping used. The TTC dimension adds a prioritization layer beyond probability. Two attack steps with identical p̂ values may have TTC values differing by an order of magnitude. Integrating TTC as an edge cost in the Monte Carlo simulation allows the SDT to identify not merely whether an attack path is possible but whether it is economically attractive to a cost-constrained adversary [33].
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
10.2
Security Analysis of the HAVE Agent Itself
Three attack scenarios are considered: Compromised Controller. The allow-list validation (Eq. (2)) and path sanitization prevent execution against unauthorized targets. The directory allow-list is readable only by root and is not modifiable via the gRPC API. Network Eavesdropping and Replay. The mTLS channel (Eq. (3)) prevents both eavesdropping and replay attacks. Each gRPC session uses freshly negotiated session keys. Resource Exhaustion. The cgroups v2 cap (Eq. (1)) bounds total CPU consumption irrespective of campaign concurrency. 10.3
Operational Deployment Guidelines
Three deployment configurations are recommended: Continuous Monitoring Mode. In IT environments with low-sensitivity assets, the Agent runs continuously and executes verification campaigns automatically upon CVE publication or telemetry-detected configuration drift. Scheduled Audit Mode. In high-security IT environments, campaigns are scheduled during maintenance windows with operator approval. Isolated-Twin Mode. In OT environments, a highfidelity VM replica of each critical asset is maintained. HAVE executes verification campaigns exclusively against these replicas. TTC values measured in this mode reflect VM-environment timing and serve as valid relative ordering metrics for attack-path prioritization but cannot be mapped directly to physical PLC response times. 10.4
Ethical and Legal Deployment Framework
The deployment of active exploit verification tools raises important ethical and legal considerations. In EU jurisdictions, the NIS2 Directive mandates formal risk management frameworks for critical infrastructure operators, within which HAVE campaigns must be documented as authorized security assessments. The GDPR applies when verification campaigns process systems storing personal data, requiring a Data Protection Impact Assessment. In the United States, the Computer Fraud and Abuse Act (CFAA) imposes strict liability for unauthorized access. Accordingly, HAVE must be deployed exclusively within explicitly authorized perimeters: the allow-list mechanism (Eq. (2)) and the signed root-of-trust configuration enforce this at the technical level. Organizations are advised to maintain a formal verification charter documenting the authorized scope, the responsible operator, the approved payload classes, and the applicable regulatory framework. 10.5
Limitations and Future Work
HAVE is bounded by the coverage of its exploit library. It measures the exploitability of known vulnerabilities using known exploit techniques; it cannot assess the risk from zero-day vulnerabilities or from novel attack techniques not yet represented in the library. As discussed in Section 7.2, the measured p̂ constitutes a lower bound on exploitability under the modeled adversary capability level. Extending HAVE with Automated Exploit Generation [27], [28] and
11
directed grey-box fuzzing [44] capabilities would address this by allowing the engine to stress-test applications against variant attack patterns. The current dynamic phase requires a hypervisor snapshot infrastructure, making it unsuitable for bare-metal embedded controllers. Future work will investigate lightweight checkpointing via CRIU (Checkpoint/Restore In Userspace) as an alternative, and will develop containerized agent deployments targeting cloud-native workloads [38].
11
C ONCLUSION
This paper has presented the Host Active Verification Engine (HAVE), a significant architectural extension to the SDT paradigm that bridges the Contextual Reality Gap between theoretical CVSS-based risk scores and empirically measured host-level exploitability. By deploying a safetyconstrained agent that performs granular static analysis and snapshot-isolated dynamic exploit trials, HAVE produces ground-truth measurements p̂ and T T C that replace context-free vulnerability severity estimates with empirically validated, host-specific probabilities. A formally characterized confidence weight αw (Eq. (13)), derived from the width of the Wilson score interval and formally related to the Beta-Binomial posterior (Section 6.3.3), provides principled uncertainty propagation from empirical estimates into Monte Carlo risk simulations. Its key advantage over the canonical Beta-Binomial weight is state-dependence on p̂, which correctly increases confidence for extreme outcomes even at moderate N . Our experimental evaluation across four canonical vulnerability classes, three security tiers, and two production binaries with registered CVE identifiers establishes five findings with direct operational implications. First, modern memory hardening (PIE, Full RELRO, ASLR) completely neutralizes blind exploitation of stack overflow and heap UAF vulnerabilities, yielding p̂ = 0.00 with a Wilson upper bound of 0.037 at N = 100. Second, format string vulnerabilities retain p̂ = 0.33 (CI [0.246, 0.427]) even at the High tier due to an intrinsic information-leakage capability. Third, all memory-safety mitigations are entirely irrelevant to logic flaws (command injection), which remain unconditionally exploitable (p̂ = 1.00) across all tiers, as confirmed on both the synthetic corpus and CVE-2021-42013. Fourth, CVE2021-3156 production binary results confirm the heap vulnerability class-level pattern (p̂ = 1.00 at Low-equivalent, p̂ = 0.00 at High-equivalent), establishing generalizability. Fifth, end-to-end Monte Carlo validation on a five-node dual-path attack graph demonstrates that false-negative corrections (+132.4% in Scenario B) can dominate false-positive suppressions (−38.2% in Scenario A), with a net effect of +124.1% elevation in risk: CVSS-only models were underestimating the true risk of this infrastructure by a factor of 2.24. A sensitivity analysis over κ ∈ {0.5, 1.0, 1.5, 2.0} confirms that post-HAVE risk estimates vary by only a factor of 1.12, while the CVSS-only baseline varies by a factor of 4.6, demonstrating empirical robustness to prior parameterization. Future research directions include the integration of Automated Exploit Generation techniques to extend coverage to novel attack variants, the development of lightweight
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2026
checkpointing for bare-metal and container environments, and the scaling of HAVE deployment across large-scale enterprise topologies to evaluate the aggregate impact of simultaneous multi-node HAVE campaigns on SDT simulation accuracy.
DATA AVAILABILITY Code and results are available to reviewers at https://anonymous.4open.science/r/HAVE. The repository will be transferred to GitHub upon acceptance.
R EFERENCES K. Stouffer et al., “NIST special publication 800-82 rev. 2: Guide to industrial control systems (ICS) security,” National Institute of Standards and Technology, Tech. Rep., 2015. [2] L. Cheng, K. Tian, and D. D. Yao, “Orpheus: Enforcing cyberphysical execution semantics to defend against data-oriented attacks,” pp. 315–326, 2017. [3] F. Baiardi, V. Sammartino, and S. Ruggieri, “Notline: A nonintrusive automated platform to build a digital twin,” in 2025 29th International Symposium on Distributed Simulation and Real Time Applications (DS-RT), 2025, pp. 1–8. [4] A. Fuller et al., “Digital twin: Enabling technologies, challenges and open research,” IEEE Access, vol. 8, pp. 108 952–108 971, 2020. [5] V. Sammartino, “A framework for proactive cyber-resilience: Nonintrusive modeling for autonomous defense,” in DS-RT 2025, 2025. [6] M. Muench et al., “What you corrupt is not what you crash: Challenges in fuzzing embedded devices,” in Proc. Network and Distributed System Security Symp. (NDSS), 2018. [7] FIRST.org, “Common vulnerability scoring system v3.1: Specification document,” Forum of Incident Response and Security Teams (FIRST), Tech. Rep., 2019. [8] F. Baiardi and V. Sammartino, “Simulation-powered cybersecurity: Real-time risk assessment via non-intrusive security twin,” The Journal of Supercomputing, 2026, special Issue: Simulation-Powered Innovation: Driving the Future of Digital Ecosystems. [9] L. Szekeres et al., “SoK: Eternal war in memory,” in Proc. IEEE Symp. Security and Privacy (S&P), 2013, pp. 48–62. [10] F. Baiardi, S. Ruggieri, and V. Sammartino, “Security twins e il futuro della previsione di intrusioni cyber,” ICT Security, 2025. [11] M. Eckhart and A. Ekelhart, “A specification-based state replication approach for digital twins,” in Proc. ACM Workshop CyberPhysical Systems Security and Privacy (CPS-SPC), 2018, pp. 36–47. [12] M. Dietz and G. Pernul, “Integrating digital twin security simulations in the security operations center,” IEEE Access, vol. 8, pp. 163 252–163 268, 2020. [13] F. Baiardi and V. Sammartino, “From digital twins to ai agents: A synthetic data paradigm for next-generation cybersecurity,” in Artificial Intelligence in Cybersecurity: Unlocking the Power of Large Language Models. CRC Press, 2026. [14] ——, “Quantifying resilience of cyber-physical systems to zeroday threats: A security twin-based what-if analysis framework,” in Proceedings of the 36th European Safety and Reliability Conference (ESREL 2026). Braga, Portugal: European Safety and Reliability Association (ESRA), June 2026. [15] V. Sammartino, F. Baiardi, and S. Ruggieri, “A Security Twin to Defeat Intrusions in Cyber Physical Systems,” in ESREL SRA-E 2025, 2025. [16] F. Baiardi, S. Ruggieri, and V. Sammartino, “Anticipating Disasters through a Security Twin,” in SPRINGER OPTIMIZATION AND ITS APPLICATIONS - ARES 2024, 2024. [17] M. Bozorgi et al., “Beyond heuristics: Learning to classify vulnerabilities and predict exploits,” in Proc. ACM SIGKDD Int’l Conf. Knowledge Discovery and Data Mining, 2010, pp. 105–114. [18] J. Jacobs et al., “Exploit prediction scoring system (EPSS),” Digital Threats: Research and Practice, vol. 2, no. 3, pp. 1–17, 2021. [19] H. Shacham et al., “On the effectiveness of address-space randomization,” in Proc. ACM Conf. Computer and Communications Security (CCS), 2004, pp. 298–307. [20] C. Cowan et al., “StackGuard: Automatic adaptive detection and prevention of buffer-overflow attacks,” in Proc. USENIX Security Symp., 1998, pp. 63–78. [21] H. Shacham, “The geometry of innocent flesh on the bone: Returninto-libc without function calls (on the x86),” in Proc. ACM Conf. Computer and Communications Security (CCS), 2007, pp. 552–561. [1]
12
[22] F. Baiardi, S. Ruggieri, and V. Sammartino, “ AI-enabled Cybersecurity using Synthetic Data ,” in 2025 IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops). Los Alamitos, CA, USA: IEEE Computer Society, Mar. 2025, pp. 140–145. [23] G. Lyon, “Nmap network scanning: The official Nmap project guide to network discovery and security scanning,” Insecure.com LLC, 2009. [24] Greenbone Networks, “OpenVAS: Open vulnerability assessment system,” 2009. [25] M. Moberg, J. Hallberg, and N. Hallberg, “Evaluating security scanners for GNU/Linux systems: Configuration compliance and vulnerability management,” in Proc. Int’l Conf. Availability, Reliability and Security (ARES), 2014, pp. 506–513. [26] T. Avgerinos et al., “AEG: Automatic exploit generation,” in Proc. Network and Distributed System Security Symp. (NDSS), 2011. [27] ——, “Automatic exploit generation,” Communications of the ACM, vol. 57, no. 2, pp. 74–84, 2014. [28] Y. Shoshitaishvili et al., “SoK: (state of) the art of war: Offensive techniques in binary analysis,” in Proc. IEEE Symp. Security and Privacy (S&P), 2016, pp. 138–157. [29] O. Sheyner et al., “Automated generation and analysis of attack graphs,” in Proc. IEEE Symp. Security and Privacy (S&P), 2002, pp. 273–284. [30] X. Ou, W. F. Boyer, and M. A. McQueen, “A scalable approach to attack graph generation,” in Proc. ACM Conf. Computer and Communications Security (CCS), 2006, pp. 336–345. [31] M. Frigault and L. Wang, “Measuring network security using Bayesian network-based attack graphs,” in Proc. IEEE Int’l Computer Software and Applications Conf. Workshop (COMPSACW), 2008, pp. 698–703. [32] N. Poolsappasit, R. Dewri, and I. Ray, “Dynamic security risk management using Bayesian attack graphs,” IEEE Transactions on Dependable and Secure Computing, vol. 9, no. 1, pp. 61–74, 2012. [33] M. A. McQueen et al., “Quantitative cyber risk reduction estimation methodology for a small SCADA control system,” 2006. [34] J. Homer et al., “Aggregating vulnerability metrics in enterprise networks using attack graphs,” Journal of Computer Security, vol. 21, no. 4, pp. 561–597, 2013. [35] N. Corteggiani, G. Camurati, and A. Francillon, “Inception: System-wide security testing of real-world embedded systems software,” in Proc. USENIX Security Symp., 2018, pp. 309–326. [36] P. B. Menage, “Adding generic process containers to the Linux kernel,” vol. 2, pp. 45–57, 2007. [37] B. E. Strom et al., “MITRE ATT&CK: Design and philosophy,” 2020, technical Report. [38] S. Rose et al., “NIST special publication 800-207: Zero trust architecture,” National Institute of Standards and Technology, Tech. Rep., 2020. [39] T. Klein et al., “checksec.sh – a shell script to test for common buffer overflow mitigations,” https://github.com/slimm609/ checksec.sh, 2009. [40] F. Blichmann, M. Mazurek et al., “pwntools – CTF framework and exploit development library,” https://github.com/Gallopsled/ pwntools, 2015. [41] F. Baiardi and V. Sammartino, “A quantitative framework for the validation of twin-based cyber defense,” in 37th European Modeling & Simulation Symposium (EMSS 2025), held within the 22nd International Multidisciplinary Modeling & Simulation Multiconference (I3M 2025), 2025. [42] scut / team teso, “Exploiting format string vulnerabilities,” Phrack Magazine, version 1.2, 2001. [43] B. Lee et al., “Preventing use-after-free with dangling pointers nullification,” in Proc. Network and Distributed System Security Symp. (NDSS), 2015. [44] M. Böhme et al., “Directed greybox fuzzing,” in Proc. ACM Conf. Computer and Communications Security (CCS), 2017, pp. 2329–2344.