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

How to use LLMs without turning them into an autonomous scanner

LLMs work best as a directed review assistant when the target is a large codebase. Security teams get the most value by giving the model a narrow slice of code, a clear review objective, and a bounded output format. That keeps the model focused on finding plausible weaknesses in high-value paths rather than generating a broad, noisy inventory of everything that might be wrong.

Start with code that influences authentication, secret handling, and privilege checks, because those areas tend to create the largest downstream blast radius when they fail. A focused prompt is more effective than asking for a full audit of an entire repository, especially when the codebase spans multiple services, shared libraries, and build-time or runtime trust boundaries. For a broader operating model around AI-assisted security review, NIST AI 600-1 GenAI Profile is useful for grounding review workflows in governance, testing, and risk management.

Keep the interaction iterative. Ask for one high-impact issue, then force the model to explain the exact code path, preconditions, and why the issue would matter in practice. If the first pass produces a weak result, refine the scope rather than widening it. That approach makes the LLM behave more like a triage accelerator than a replacement for human code review.

What LLMs are good at finding in large codebases

LLMs are strongest when they help reviewers spot patterns that are easy to miss in sprawling code, such as inconsistent authorization checks, unsafe assumptions about input trust, secret material moving through logs or configs, and code paths that look secure in one layer but fail at a lower layer. They can also help surface review candidates from repetitive code, generated code, wrapper functions, and policy enforcement logic where the same bug may be copied many times.

They are less reliable when the question requires deep runtime context, environment-specific configuration, or proof that a suspected weakness is truly exploitable. That is why the best use case is issue discovery, not final verdict. If the code under review sits inside API authentication, object-level access control, or function-level privilege boundaries, the most relevant references are often the control points where an implementation can fail silently. NIST AI 600-1 GenAI Profile also aligns with the need to test the model before trusting it in a security workflow.

Security teams should treat the output as a hypothesis set. A good LLM finding is specific enough that a human can test it quickly, reproduce the condition, or rule it out with evidence from the code and surrounding architecture. A vague answer that names generic flaws without a code path is usually noise, not signal.

How to keep false positives and triage noise under control

The main failure mode is over-broad prompting. If you ask the model to “find vulnerabilities” across a large repository, it will often return many generic warnings, many of which will be unhelpful. Better prompts ask for one issue class at a time, one module at a time, and one confidence threshold at a time. That discipline produces fewer claims, but each claim is easier to validate and operationalise.

Use a human review gate for exploitability. The model can highlight suspicious logic, but an experienced reviewer should confirm whether the flaw is reachable, whether an attacker can influence inputs, whether any compensating control exists, and whether the issue actually changes security posture. For teams building a repeatable workflow, NIST AI Risk Management Framework provides a governance lens for validating AI-assisted analysis before it is trusted operationally.

Noise control also depends on limiting the model’s room to speculate. Ask it to cite the exact function, branch, or call chain it relied on, and reject findings that cannot be tied back to concrete code. In large codebases, the best signal often comes from small, well-scoped prompts that examine one dangerous assumption at a time rather than trying to infer a full security posture from the repository as a whole.

Practitioner Guidance

What to prioritise: Put LLM review effort on code that governs authentication, secrets, session handling, and privilege checks first. Those paths are where a small logic error is most likely to become a material security issue.

What to verify: Require every promising finding to include the exact code path, the attacker-controlled input or state, and the reason the issue is reachable. If those three pieces are missing, treat the output as a lead, not a vulnerability.

Decision rule: Use the LLM to narrow the search and accelerate human review, but do not let it act as the final judge of exploitability. The useful boundary is “model proposes, human confirms.”

Practitioner takeaway: The highest-value workflow is narrow, iterative, and human-validated, because LLMs are most effective at surfacing candidate weaknesses in critical code, not at independently proving security defects.

Related resources from NHI Mgmt Group

• How should security teams use source and sink analysis to find application vulnerabilities in complex codebases?
• Why do application security teams struggle to patch vulnerabilities quickly in large codebases?
• How should security teams use decompiler output to find vulnerabilities in closed-source binaries faster?
• How should security teams use DAST to find runtime web application vulnerabilities before attackers do?