OpenAnt: Closed-Loop Vulnerability Discovery

• OpenAnt is an open-source closed-loop vulnerability discovery system that integrates static analysis with LLM semantic reasoning to efficiently identify and validate vulnerabilities in large codebases.
• It employs a multi-stage pipeline that narrows candidate functions via reachability filtering, adversarial verification, and dynamic exploit validation, significantly reducing false positives and infrastructure costs.
• The system dynamically confirms exploits in containerized environments using LLM-guided adversarial tests, achieving a 75.8% exploit reproducibility rate on real-world projects.

OpenAnt is an open-source, closed-loop vulnerability discovery system that integrates classical static program analysis with LLM-based semantic reasoning and automated exploit generation. Its design addresses the challenge of automated vulnerability discovery in large codebases, where traditional static analysis produces high false-positive rates, while dynamic approaches such as fuzzing impose high infrastructure costs and often miss semantically complex vulnerabilities. OpenAnt’s architecture operates as a multi-stage pipeline, systematically narrowing the analysis surface and escalating verification rigor, culminating in concrete exploit validation within dynamic, ephemeral environments. The system has been demonstrated to identify previously unknown vulnerabilities in major open-source projects while maintaining a manageable analysis cost and significantly reducing false positives (Korda et al., 17 Jun 2026).

1. Multi-Stage Pipeline Architecture

OpenAnt organizes vulnerability discovery as a six-stage funnel, in which candidate code units are systematically filtered and increasingly scrutinized:

1. Code Parsing: Source code is parsed into language-specific ASTs to extract all functions $F = \{ f_1, …, f_n \}$.
2. Unit Generation & Reachability Filtering: Only functions reachable from external entry points (e.g., HTTP handlers, CLI parsers) are retained, forming the set $R \subset F$ defined by call graph transitive closure.
3. Exposure Classification (LLM): An LLM determines whether each analysis unit is exposed to untrusted input or attacker control.
4. Vulnerability Detection (LLM): The LLM conducts semantic reasoning to flag units likely to contain security risks.
5. Adversarial Verification (LLM): The LLM simulates a constrained attacker model, attempts multiple exploitation strategies, and checks feasibility and impact.
6. Dynamic Verification: Exploit environments are generated and executed in isolated containers to confirm or refute exploitability.

Each stage reduces the candidate set size; for example, a typical project analysis might narrow from ∼64,000 functions to ∼2,300 reachable analysis units and, ultimately, fewer than 200 dynamically confirmed vulnerabilities. Verification rigor increases from initial static filtering to full exploit validation using ephemeral Docker containers (Korda et al., 17 Jun 2026).

2. Code Decomposition and Surface Reduction

The code decomposition methodology leverages static analysis and reachability filtering. Define $F$ as the set of all functions, with a subset $E \subseteq F$ of external entry points. The reachability set is

$$R = \{ f \in F \mid \exists e \in E : e \to^* f \},$$

where $\to^*$ denotes transitive closure over the call graph. For each $f \in R$, a self-contained analysis unit $U(f) = (f, D_k(f), \text{meta}(f))$ is constructed:

• $D_k(f)$: all callees of $f$, plus further callees up to depth $R \subset F$0 (default $R \subset F$1),
• $R \subset F$2: entry point metadata.

The reduction metric is quantified as $R \subset F$3. Across eight evaluated projects (64,132 functions), reachability filtering achieved a 96.4% cut, reducing the analysis set size to 2,281 units. In OpenSSL, for example: $R \subset F$4, $R \subset F$5, so reduction $R \subset F$6 97.4% (Korda et al., 17 Jun 2026).

3. LLM-Guided Adversarial Verification

Following semantic vulnerability detection, each flagged analysis unit undergoes adversarial verification driven by the LLM. The attacker model is defined by:

• Browser-only interaction,
• No server-side or administrative privileges,
• No server file modification.

For each candidate, the LLM attempts multiple exploitation strategies (e.g., direct injection, parameter tampering, SSRF), checking for feasibility and actual impact. Formally, for strategy set $R \subset F$7, feasibility is

$R \subset F$8

Only units with $R \subset F$9 proceed to dynamic verification. In experimental evaluation, adversarial verification eliminated 49.5% of false positives, reducing 376 flagged units to 190 confirmed candidates (Korda et al., 17 Jun 2026).

4. Dynamic Verification and Exploit Confirmation

Final confirmation is achieved via dynamic verification. For each unit surviving adversarial filtering, the LLM emits a full exploit environment:

• Dockerfile (base image, dependencies),
• Test script to exercise the vulnerability,
• Requirements file (pip, npm, etc.),
• Optionally, a docker-compose setup.

Containers are sandboxed with 512 MB RAM, 1 CPU, read-only filesystem, no privilege escalation, and a 120s timeout. The container emits a single JSON result: $F$0. On "ERROR," the process is repeated up to three times with error feedback to the LLM. All artifacts and container images are discarded after execution.

The observed dynamic confirmation rate is

$F$1

Thus, 75.8% of units reaching this stage resulted in confirmed, reproducible exploits (Korda et al., 17 Jun 2026).

5. Evaluation: Metrics, Targets, and Cost

OpenAnt was evaluated on eight real-world projects (languages: C, PHP, Python, TypeScript, JavaScript, Go, Ruby) rather than on synthetic or “memoized” benchmarks. Key metrics include:

• Scalability: Reduction funnel (e.g., $F$2 exposed $F$3 flagged),
• Detection Capability: 190 unique, confirmed vulnerabilities across over 30 CWE classes,
• False Positive Mitigation: From 376 flagged to 190 confirmed (elimination rate ≈ 49.5%),
• Exploit Reproducibility: 144/190 dynamically confirmed (75.8%).

API usage cost totaled \$F$423,700. No formal hypothesis testing was conducted, as the evaluation focused on real-world discovery rather than benchmark accuracy (Korda et al., 17 Jun 2026).

6. Implementation: Static Analysis, LLM Usage, and Resource Constraints

Static analysis backends:

• Python, Go: native AST libraries,
• JavaScript/TypeScript: ts-morph,
• C/C++/Ruby/PHP: tree-sitter grammars,
• Unified intermediate representation for call-graph extraction.

LLM usage:

• Stages 3 and 6: Claude Sonnet 4 (temperature=0),
• Stages 4 and 5: Claude Opus 4 (temperature=0),
• Detection prompt: language-agnostic template ("What does this code do? Where does the input originate? What security risk may arise?"),
• Adversarial prompt: explicit attacker constraints plus requirement to attempt multiple exploitation approaches.

Scalability is primarily maintained by reachability filtering, which prunes over 95% of functions before invoking any LLM call. Stage 6 resource use is bounded per container, and LLM API usage is the largest contributor to cost. The OpenAnt pipeline performs no system-level caching; each analysis unit is processed independently from scratch (Korda et al., 17 Jun 2026).

7. Trade-offs, Limitations, and Prospects for Extension

OpenAnt’s strengths arise from its closed-loop architecture—progressing from semantic detection, through adversarial reasoning, to dynamic confirmation. However, explicit limitations include:

• Dependence on the reasoning capabilities and limitations of current LLM architectures,
• Inability to analyze certain vulnerability classes (race conditions, protocol-level bugs),
• Cost and context-window constraints: large or deeply nested units may exceed LLM handling or incur extremely high costs,
• Dynamic verification may be inconclusive for highly complex or distributed environments,
• Absence of formal guarantees: lack of dynamic confirmation does not prove absence of exploitable vulnerability.

Potential avenues for extension include integrating symbolic or static-taint analyses, deploying hierarchical or multi-granularity decompositions for large contexts, domain-specific LLM fine-tuning, caching/incremental analysis strategies, and advanced instrumentation for dynamic tests (coverage, fault injection) (Korda et al., 17 Jun 2026).

OpenAnt demonstrates that the combination of aggressive static pruning, LLM-driven semantic reasoning, adversarial attack simulation, and on-the-fly exploit generation can yield a scalable pipeline for discovering and validating real-world vulnerabilities with demonstrable exploitability evidence.