Notifications
Clear all
Topic starter
09/07/2026 9:33 am
TL;DR: Static analysis and fuzzing alone miss too much at repository scale, so the system combines reachability-filtered units, adversarial verification, and sandboxed dynamic validation to reduce attack surface by up to 97% while finding previously unknown vulnerabilities, according to Knostic’s OpenAnt research. The result is a stronger model for secure code review, but one that also exposes how cost, context, and verification now shape LLM-assisted vulnerability discovery.
NHIMG editorial — based on content published by Knostic: OpenAnt and LLM vulnerability discovery at repository scale
By the numbers:
- Decomposing codebases into reachability-filtered analysis units reduces the attack surface by up to 97%.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams reduce false positives in LLM-assisted vulnerability discovery?
A: Use a validation pipeline that ranks findings by reachability, tests exploitability under realistic attacker constraints, and confirms behaviour in a sandbox before escalating.
Q: Why do large codebases make AI-assisted security review harder?
A: Large repositories create context loss.
Q: What do teams get wrong about static analysis for LLM security?
A: They often treat static analysis output as a risk verdict rather than a hypothesis.
Practitioner guidance
- Prioritise reachable attack paths first Filter vulnerability findings by code reachability before assigning triage work, so reviewers spend time on paths an attacker can actually hit.
- Add exploitability verification to code review Require a second-stage check that tests whether a candidate issue can be driven to impact under bounded attacker constraints.
- Isolate dynamic testing in disposable sandboxes Run exploit generation and runtime validation in sandboxed containers that are destroyed after use, so proof-of-concept work cannot leak into development or production environments.
What's in the full article
Knostic's full arXiv paper covers the operational detail this post intentionally leaves for the source:
- The multi-stage pipeline design, including how reachability filtering reduces the analysis set before LLM reasoning begins
- The evaluation methodology across OpenSSL, WordPress, and Flowise, including what the system found in each codebase
- The sandboxed exploit-generation workflow, with enough detail to understand how validation environments are created and discarded
- The paper's performance and false-positive comparisons, which are the implementation details teams need before adapting the approach
👉 Read Knostic's paper on OpenAnt and LLM vulnerability discovery →
LLM vulnerability discovery at repo scale: what teams need to know?
Explore further
09/07/2026 9:34 am
OpenAnt reflects the growing need for verification-first security in AI-assisted code review. LLM reasoning can improve vulnerability discovery, but it does not remove the need to prove exploitability in context. The article shows that scale, cost, and context management are the real constraints, not model intelligence alone. For practitioners, the lesson is to design review pipelines around validated risk, not model confidence.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to AI LLM hijack breach.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How can organisations govern AI tools that review or modify code?
A: Treat the tools as part of the software supply chain and the identity plane. Review what they can access, which repositories they can reach, and what credentials they use to operate. If an AI coding assistant or connected extension can touch secrets, build pipelines, or privileged services, it needs scoped access, explicit oversight, and separate validation boundaries.
👉 Read our full editorial: OpenAnt shows why LLM vulnerability discovery needs runtime verification
