Open research questions in Security and Verification in Computing

What the literature leaves open

• We measured the interval between open-weight publication and the first community-declared safety-stripped derivative across 215 releases and 98,709 declared descendants. Conditional on being stripped, the median release waits 14.1 days; unconditionally, half of eligible releases are stripped within 65–81 days and about 40% are never visibly stripped inside our window. The interval is contracting — −27 days per year, Kaplan–Meier medians of 128 against 23.5 days across eras, half-year cohort medians falling from 81 to 5 days — and the contraction survives controls for ecosystem size, family composition, and observation window. Incidence and download share did not rise, so what changed is speed rather than appetite. Two decompositions narrow the finding considerably. The trend is carried by a single technique label, and removing it leaves the trend non-significant; and first-stripping events are concentrated in a few dozen accounts, with one responsible for 40% of them. The measurement is therefore better described as the diffusion curve of refusal- direction ablation among a small set of prolific operators than as a general property of the open-weight community. Three studies follow directly. Behavioural validation: evaluate refusal behaviour on a stratified sample of the 1,002 labelled repositories to establish what fraction of the label means what it says — this is the single largest uncertainty in the paper, and our metadata is a ready sampling frame. Actor-level study: model first-stripping as a function of operator capacity rather than release properties, which our concentration finding suggests is the better-specified model. Prospective replication: re-run the collection at a later snapshot; the analysis date is pinned so that the comparison is well defined, and a genuine out-of-sample test of the acceleration is available simply by waiting. Reproducibility statement. All data comes from the unauthenticated public Hugging Face API and is cached; the analysis date is pinned to 2026-07-24; permutation and bootstrap seeds are fixed; and every statistic in this paper is emitted to a machine-readable report. See Appendix I.

  Guardrail Half-Life After Open-Weight Release: Measuring the Lag from AI Model Publication to Safety-Stripped Derivative · 2026 · DOI

• Since current approaches (perplexity filtering, re- tokenization) prove inadequate for this nuanced safety challenge, future work could focus on developing lightweight LLMs capable of cipher comprehension and intent detection, potentially through knowledge distillation from main LLM to transfer decryption capabili- ties to smaller, specialized safety filters.

  Should LLM Safety be More Than Refusing Harmful Instructions? · 2026 · DOI

• In practice, due to the absence of large-scale runtime MCP servers, such understanding largely relies on security scanners applied to a small number of cases, yet the reliability of these assessments remains unclear.

  Rethinking MCP Security: A Large-Scale Study of Runtime MCP Servers and Security Scanner Reliability · 2026

• This paper demonstrates that combining Secure Boot and Measured Boot significantly improves the security capabilities of the RPi platform by establishing a continuous CoT from early boot stages to the operating system. While certain limitations remain due to hardware and proprietary components of the platform, the proposed approach enables verifiable integrity and supports security mechanisms such as Remote Attestation. The presented approach is particularly suitable for industrial use cases, where higher setup complexity is acceptable in exchange for increased trustworthiness. Future work includes evaluating UEFI on U-Boot to improve flexibility and extending the CoT into user space using Linux IMA.

  Trustworthy Secure and Measured Boot on a Raspberry Pi 4 · 2026 · DOI

• cloud-dependent architectures affect the speed and accuracy of implementing protective actions. Particular emphasis is placed on the execution of security policies as a controlled and reproducible process integrated into the the automated computing environment, ensuring application of protective measures.

  Autonomous Threat Remediation in Localized AI Environments: A Review of Security-as-Code Execution Models · 2026 · DOI

• In this study, we first address the foundational challenge of SBOM accuracy. Through a large-scale evaluation of 2,414 open-source projects, we demonstrated that utilizing lock files as the primary input enables popular SBOM generators like Syft and Trivy to produce consistent, complete, and reliable SBOMs. This establishes a crucial first step for any practical SBOM-based SSC pipeline. However, our study reveals that even these accurate SBOMs are not a silver bullet for vulnerability management. Our manual eval- uation of downstream scanners uncovered a more profound flaw in the current ecosystem: an overwhelming 92.0% false positive rate in our sampled dataset. This finding demonstrates that the current generation of SBOM-based scanners is fundamentally inadequate for practical use, burying developers in unactionable alerts and undermining the trustworthiness of the entire process. This limitation arises from the coarse granularity of information typically provided by SBOMs, which operate at the package level. A package may include a large number of functions, and the presence of a single vulnerable function can result in the entire package—and by extension, the software—being flagged as vulnerable, even if the function is never invoked. For practitioners, this overgeneralization directly leads to wasted resources on manual triage and encourages ignoring security alerts, which ultimately degrades the security posture. Our work not only identifies this critical challenge but also vali- dates a clear path forward. Our large-scale, multi-language study provides the first comprehensive, empirical evidence that reacha- bility analysis is a fundamental requirement across the board. Our function call analysis serves as a generalizable proof-of-concept, demonstrating that reachability analysis can successfully prune a majority of these false positives. Our future work will build upon our validated approach by exploring more advanced static or dy- namic analyses to handle complex cases. Solving this issue is para- mount to unlocking the full potential of SBOMs and finally deliver- ing on their promise of precise and actionable security insights for practitioners.

  A Reality Check on SBOM-based Vulnerability Management: An Empirical Study and A Path Forward · 2026 · DOI

• In this work, we introduced RunPBA, a hardware-based runtime attestation system. It leverages the Arm PACBTI extension, an innovative technology found in certain proces- sors within the Arm Cortex-M lineup. RunPBA achieves low overhead using off-the-shelf processors and is designed as an extension of the Trusted Firmware-M project, with the goal of facilitating easy integration into real-world systems. RunPBA is able to mitigate the TOCTOU problem present in many attestation schemes by enforcing the intended execu- tion flow. In addition to detecting runtime faults, RunPBA also offers the capability to trace them. We developed a prototype of the RunPBA solution, and our comprehensive evaluation shows that it introduces a minimal performance overhead, specifically 1% on CoreMark Pro and 4.7% on BEEBS. All code and tools used in this study are available at: https://github.com/MrSuicideParrot/runpba. Furthermore, we envision potential avenues for future improvement. One promising direction is enhancing the compiler to better analyze source code and identify functions where PACBTI instructions may not contribute significantly to security, thereby optimizing runtime performance. Such improvements could benefit not only RunPBA but also any other solutions that leverage the PACBTI extension. We acknowledge the need to investigate new attack vectors, such as FOP (Fault of Protection) attacks, which were outside the scope of this work but represent a critical area for future research in the context of runtime attestation systems. Finally, the potential of PACBTI to prevent data-flow attacks should be researched. Cirne et al.: Preprint submitted to Elsevier Page 14 of 16 RunPBA - Runtime attestation for microcontrollers with PACBTI Declaration of Generative AI and AI-assisted technologies in the writing process During the preparation of this work, the authors used ChatGPT4 to revise the text throughout the paper, correcting typos and grammatical errors. After using this service, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication.

  RunPBA - Runtime attestation for microcontrollers with PACBTI · 2026 · DOI

• Our work demonstrates the feasibility of host-independent authen- tication for LLM-based agents, but important gaps remain before the stronger property of host-independent autonomy can be realized. Authentication ensures that outputs match a declared configura- tion, yet a malicious host can still bias which outputs are revealed, delay disclosure, or steer behavior through covert timing and side channels. Closing this gap is a central objective for future work. Several further limitations also point to concrete research direc- tions. First, our current architecture assumes a honest-but-curious notary; compromise of its signing key would undermine both cor- rectness, and reliance on a single entity creates centralization risks. Future designs should explore threshold-MPC or hybrid MPC-in- TEE deployments to distribute trust. Second, our scheme lacks freshness guarantees: replaying old proofs or selectively present- ing stale outputs remains possible. Incorporating cryptographic timestamps or randomness beacons (e.g., Drand) would strengthen Grigor et al. liveness and replay protection. Third, our formalism and imple- mentation focus on a single reasoning core with sequential tool invocations, whereas emerging agents rely on parallel, clustered, or hierarchical structures. Extending compositional proofs to these richer execution models is an open challenge. Finally, practical deployment is constrained by the absence of standardized proof formats and tooling for verifiable bundles, which limits interoper- ability and adoption in sector-specific settings such as finance or governance. In summary, VET establishes the first practical step toward host- independent autonomy, but future systems must reduce residual host influence, distribute trust in the notary, enforce freshness, and support more flexible agent architectures. Addressing these chal- lenges will advance verifiable agents from authenticated outputs toward full autonomy in adversarial environments.

  VET Your Agent: Towards Host-Independent Autonomy via Verifiable Execution Traces · 2026 · DOI

• trend and show exploitation, pivoting, and goal-reaching strategies in simulated or emulated environments [1-8]. Moreno et al. critically review that this reinforcement learning and recommender systems are already being used to support autonomy in penetration testing, although remain important regarding generalization, environment realism, and reward design. Wang et al. argue for a unified modeling framework for automated penetration testing, noting that the current diversity of simulators and abstractions still hinders reproducibility and meaningful comparison. Chen et al., in their survey on penetration-path planning, show that the problem is inherently combinatorial and therefore compatible with heuristics, metaheuristics, and hybrid search strategies. Together, these studies suggest that complex security environments require mechanisms able local to combine global exploration with adaptation [1-4]. graphs, relations, The framework proposed here is positioned exactly at that intersection. It is white-box because it assumes authorized defensive access to the environment’s identity and internal blueprint: ZTNA policies, privilege historical trust authentication telemetry, continuous-verification logs, and workload dependencies. This assumption should be stated explicitly to avoid ambiguity. The goal is not to emulate a fully blind attacker, but to evaluate how a sufficiently informed adversary could exploit permission combinations, authentication pathways, and operational exceptions in order to move laterally. In Zero-Trust is environments, methodologically coherent because risk often arises not from one catastrophic vulnerability, but from the aggregation of minor policy deviations, excessive privileges, or residual connectivity across segments [12-14]. stance this 11,12–14]. Each evolutionary individual 𝜋 encodes a candidate lateral-movement path 𝑎1 𝜋 = (𝑣0 → 𝑎2 𝑣1 → 𝑎𝑘 ⋯ → 𝑣𝑘), where 𝑣𝑖 are assets or identities and 𝑎𝑖 are transitions via credentials or services [4,15]. The multi-objective fitness is defined as 𝑓(𝜋) = 𝑤1𝑃success(𝜋) + 𝑤2𝑆stealth(𝜋) + 𝑤3𝐸evasion(𝜋), with components estimated from logs and policy preconditions [9–11,16]. Reinforcement learning then locally refines promising paths [5–8]. Operationally, each individual in the population may encode a candidate chain of transitions involving assets, identities, credentials, tokens, policies, and services. Selection preserves better-performing sequences according to the fitness function; mutation introduces non-trivial alternatives; and recombination enables new compositions between promising subpaths.

  Evolutionary Computation-Enhanced White-Box Penetration Testing for Lateral-Movement Prevention in Zero-Trust Architectures · 2026 · DOI

• The current intent-driven architecture operates within a predefined intent scope; the paper identifies integration of adaptive inference models as a future path but does not specify what machine learning model architectures (transformer-based NLU, recurrent networks, etc.) will replace the rigid parsing and routing layers or how incremental intent addition will be validated without operational disruption.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• The real-time visual health dashboard is proposed to display service conditions, intent confidence levels, and recovery decisions, but the paper does not specify which metrics should be visualized, the update frequency required for real-time responsiveness, or how the dashboard will remain secure when displaying system state information accessible to multiple users with different privilege levels.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• Secure rollback mechanisms and comprehensive audit trails are proposed as safeguards for high-risk administrative tasks, but the paper does not specify the rollback granularity (per-command, per-transaction, filesystem snapshot-based), what audit trail format will enable verifiable execution history, or how rollback consistency will be maintained when autonomous healing daemon operations and explicit user commands interleave.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• Distribution-agnostic abstraction for package management and service control is identified as necessary for portability across Linux ecosystems, but the paper does not specify which package managers (apt, dnf, pacman, zypper) and service frameworks (systemd, OpenRC, runit) must be supported or how abstraction will handle manager-specific lock conditions and dependency resolution differences.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• The configurable policy framework for user-defined recovery strategies is mentioned as future work but lacks specification of the policy definition language syntax, how policy conflicts between competing recovery strategies will be resolved, or how staged response models will be formally validated to prevent unsafe cascading recovery decisions.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• Log-based predictive failure analysis is identified as a future direction, but the paper does not specify which historical system telemetry features (CPU patterns, memory allocation, I/O latency, etc.) should be analyzed, what machine learning algorithms should classify fault-precursor behaviors, or how prediction accuracy will be validated across different Linux distributions.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• The confidence-based gating mechanism uses predefined semantic certainty thresholds, but the paper does not specify how these thresholds are calibrated, what threshold values were empirically tested, or how threshold sensitivity affects both false-positive intent execution and false-negative legitimate command rejection in the intent router.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• The voice interaction layer currently operates only in English; the paper explicitly identifies multilingual support as a future requirement without specifying which languages should be prioritized or how acoustic models for non-English phonemes will be integrated into the VoXLinux semantic execution pipeline.

  VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · 2026 · DOI

• Data leakage propagation mechanisms in multi-agent systems under partial isolation conditions require empirical characterization; the paper notes that multi-agent leakage demonstrates propagation even under partial isolation, but specific attack vectors, propagation rates, and isolation thresholds remain unmeasured across different architectural configurations.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Regulatory frameworks, evaluation standards, and standardized benchmarks specifically tailored for agentic AI privacy and data leakage are absent; existing GDPR and CCPA interpretations do not address autonomous controller identification, dynamic memory retention conflicts with data minimization, or multi-agent task delegation complexities.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• The trade-off between explainability and privacy in agentic AI systems has not been formally characterized; revealing multi-agent reasoning processes and emergent behaviors required for GDPR Article 22 compliance may inadvertently disclose private information, but mechanisms to balance these competing requirements remain unspecified.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Privacy-aware tool interfaces and policy-aware execution layers for tool-augmented reasoning in agentic AI remain in early developmental stages; methods to enforce privacy protection over third-party services and maintain transparency and control over external tool invocations are underdeveloped.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Differential privacy enforcement in agentic AI systems presents unresolved challenges in managing sequential composition across multi-step reasoning iterations, dynamic memory updates, external API calls, and multi-agent output sharing; current approaches designed for static training data are computationally and architecturally infeasible for continuous autonomous environments.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Agent-specific privacy benchmarks and evaluation measures for agentic AI are lacking; current evaluations rely on ad hoc studies or LLM-centric measures that do not account for the unique privacy risks introduced by persistent memory, autonomous tool invocation, and multi-agent orchestration in agentic systems.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Memory architectures for agentic AI systems require design that balances long-term utility against stringent privacy restrictions through mechanisms such as contextual isolation, verifiable erasure, and selective forgetting, but no validated architectures currently exist that achieve this balance in autonomous agent deployments.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

• Formal privacy models specifically designed for autonomous agents are absent from the literature. Current privacy definitions and guarantees derived from static LLM settings fail to capture the temporal, persistent, and self-directed behavior of agentic systems, necessitating development of agent-aware threat models and privacy metrics that account for multi-agent coordination, tool interactions, and memory persistence.

  The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · 2026 · DOI

Most-cited papers in Security and Verification in Computing

• Making components contract aware · Computer · 1999 · 298 citations
• Spectre attacks · Communications of the ACM · 2020 · 240 citations
• A survey on the (in)security of trusted execution environments · Computers & Security · 2023 · 112 citations
• Survivable zero trust for cloud computing environments · Computers & Security · 2021 · 50 citations
• Tool-Entropy Collapse: A Cross-Architecture Signature of Agent WANDERING Failure · Open MIND · 2026 · 24 citations
• SAFE-Matter™ Runtime Admissibility and Trust Governance Specification Deterministic Runtime State Governance, Trust Computation, and Execution Authority for Life-Critical Systems · Zenodo (CERN European Organization for Nuclear Research) · 2026 · 16 citations
• The Vulnerability-Adaptive Protection Paradigm · Communications of the ACM · 2024 · 7 citations
• SAFE-Matter™ Reference Runtime Architecture A Deployable Architecture for Admissibility, Evidence Processing, Trust Computation, and Deterministic Enforcement · Zenodo (CERN European Organization for Nuclear Research) · 2026 · 6 citations
• It Is Time to Standardize Principles and Practices for Software Memory Safety · Communications of the ACM · 2025 · 6 citations
• FreightBox Zero: Three-Layer Agent Safety Stack — Hard Gate, Five Locks, and Kernel Receipts for AI-Operated NVOCCs (v3) · Zenodo (CERN European Organization for Nuclear Research) · 2026 · 2 citations

Most recent work

• Tool-Entropy Collapse: A Cross-Architecture Signature of Agent WANDERING Failure · Open MIND · 2026
• SAFE-Matter™ Runtime Admissibility and Trust Governance Specification Deterministic Runtime State Governance, Trust Computation, and Execution Authority for Life-Critical Systems · Zenodo (CERN European Organization for Nuclear Research) · 2026
• SAFE-Matter™ Reference Runtime Architecture A Deployable Architecture for Admissibility, Evidence Processing, Trust Computation, and Deterministic Enforcement · Zenodo (CERN European Organization for Nuclear Research) · 2026
• FreightBox Zero: Three-Layer Agent Safety Stack — Hard Gate, Five Locks, and Kernel Receipts for AI-Operated NVOCCs (v3) · Zenodo (CERN European Organization for Nuclear Research) · 2026
• Model Context Protocol Threat Modeling and Analysis of Vulnerabilities to Prompt Injection with Tool Poisoning · Journal of Cybersecurity and Privacy · 2026
• ParaTaintGX: Detecting Memory Corruption Vulnerabilities in SGX Applications via Parameter-Taint Model · Mathematics · 2026
• VoXlinux: A Voice-Driven Linux Operating System for Secure and Hands-Free Operation · International Journal for Research in Applied Science and Engineering Technology · 2026
• The dark side of autonomous intelligence: a survey on data leakage and privacy failures in agentic AI · Frontiers in Computer Science · 2026
• SyzCrash: Crash-Context-Guided Directed Fuzzing for Exploitability Risk Assessment of Linux Kernel Bugs · International Journal of Software Engineering and Knowledge Engineering · 2026
• NEF-DHR: A Non-Equivalent Functional Dynamic Heterogeneous Redundancy Architecture for Endogenous Safety and Security · Entropy · 2026

Related topics in Computer Science