How should security teams use LLMs to find vulnerabilities in large codebases?

Use LLMs as a focused review accelerator, not as an autonomous scanner. Start with a narrow component, ask for one high-impact issue, and have an experienced human validate exploitability. The goal is to increase expert throughput on code that controls authentication, secrets, and privilege checks, while keeping false positives and triage noise under control.

Why This Matters for Security Teams

Using LLMs to review large codebases can materially improve vulnerability discovery, but only when the model is treated as an analyst aid rather than an authority. The risk is not just missed bugs. It is also false confidence, where an output sounds precise but cannot be tied to a real execution path, data flow, or exploit condition. That is why current guidance from the NIST AI Risk Management Framework matters here: it pushes teams to govern model use, validate outputs, and keep human accountability intact.

For code review, the highest-value targets are authentication logic, secrets handling, authorization checks, deserialisation, input validation, and any path that can influence privilege boundaries. LLMs are especially useful for narrowing a codebase to suspicious regions, spotting inconsistent patterns, and surfacing insecure variants of known flaws. They are less reliable when asked to pronounce a file safe or unsafe in one pass. Security teams often get into trouble when they let the model search too broadly, because breadth increases noise faster than it increases signal.

In practice, many teams discover the limits of LLM-assisted review only after a high-severity flaw has already been missed in a low-visibility code path.

How It Works in Practice

The most effective workflow is staged. First, constrain the scope to a component, service, or function family with clear security impact. Second, ask the model for one class of issue at a time, such as broken access control, secret leakage, or injection risk. Third, require the model to cite exact lines, describe the trust boundary, and explain the exploit path in plain language. Fourth, have a human reviewer validate whether the finding is reachable, whether preconditions are realistic, and whether compensating controls already exist.

This is also where prompt discipline matters. A broad prompt like “find vulnerabilities” usually produces shallow pattern matching. A narrower prompt like “inspect this authentication flow for privilege escalation or session fixation, and explain the concrete attack path” tends to produce more actionable output. Teams can further improve quality by feeding the model architecture context, known secure coding patterns, and examples of approved error handling. The NIST AI 600-1 Generative AI Profile is useful here because it emphasises measuring output quality, managing context, and constraining misuse in production settings.

• Use LLMs to prioritise review, not to replace static analysis or testing.
• Ask for one vulnerability class per pass to reduce hallucinated generalisations.
• Force line-level citations and explicit exploit conditions.
• Validate with source code, tests, traces, or a proof-of-concept where appropriate.
• Track recurring false positives to refine prompts and review checklists.

For teams building agentic review workflows, the OWASP Agentic AI Top 10 is relevant because it highlights tool abuse, prompt injection, and over-automation risks that can affect code analysis pipelines. These controls tend to break down when the codebase is monolithic, poorly modularised, or missing reliable test coverage because the model cannot distinguish intended behaviour from dead code or legacy edge cases.

Common Variations and Edge Cases

Tighter review scope often increases analyst time per module, requiring organisations to balance deeper validation against the need to cover more code. That tradeoff is usually worth it for authentication, payment, and secrets-heavy services, but it becomes less efficient in highly generated code or extremely repetitive boilerplate.

There is no universal standard for this yet, but current guidance suggests reserving LLMs for places where human attention is scarce and exploit impact is high. In large repositories, the model may be best used to cluster similar files, identify security-sensitive call chains, and propose review hypotheses rather than final verdicts. The MITRE ATLAS adversarial AI threat matrix is useful for understanding how attackers can manipulate AI-enabled workflows, while the CSA MAESTRO agentic AI threat modeling framework helps teams think about autonomy, tool access, and misuse paths in review agents.

Edge cases matter. Proprietary frameworks, heavy metaprogramming, and dynamically generated code can reduce model accuracy because the true execution path is hidden from static context. Likewise, repositories with brittle tests may look secure in review while still failing under real inputs. For AI-assisted findings, the strongest practice is to document whether the issue is confirmed, plausible, or speculative, then route only confirmed or high-confidence items into remediation. The NIST AI Risk Management Framework remains the best anchor for governance, because it keeps review quality, accountability, and residual risk visible when the model is used as a force multiplier rather than a decider.

Related resources from NHI Mgmt Group

• How should security teams use LLMs for identity analytics without losing control?
• How should security teams govern access when LLMs use MCP servers?
• How should security teams use LLMs in vulnerability research without overtrusting them?
• How should security teams use LLMs in SOC automation without losing control?