Why do raw LLMs miss so many vulnerabilities in code review?

Why This Matters for Security Teams

Raw LLMs can be useful reviewers, but they are not reliable auditors. A model can explain a vulnerable pattern it notices, yet still miss a second endpoint, an alternate sink, or a code path hidden behind a helper, wrapper, or build flag. That matters because code review is not just pattern recognition. It is also coverage, traceability, and repeatability. NIST’s NIST AI Risk Management Framework is a useful reminder that AI outputs need governance, validation, and human accountability rather than blind trust.

Security teams often overestimate LLMs because the first few findings look strong. The failure is usually not that the model cannot identify a bug class at all. It is that it cannot consistently enumerate the full attack surface, so the review becomes uneven across files, services, and branches. That makes the tool better at triage than assurance. In practice, many security teams encounter the missed vulnerability only after a pentest, incident, or post-release abuse has already exposed the gap, rather than through intentional review coverage.

How It Works in Practice

LLMs are probabilistic text systems, so they infer likely relationships from the context they can see. In code review, that means they can flag obvious insecure concatenation, weak authentication checks, or dangerous deserialization when those patterns are directly visible. They struggle when the review depends on repository-wide reasoning, symbol resolution, or control-flow reconstruction across multiple files. That is why deterministic program analysis still matters: it supplies the exhaustive search that the model cannot guarantee.

A practical review stack usually combines the LLM with static analysis, dependency scanning, and targeted prompts that constrain scope. The model can help prioritize findings, explain intent, and summarize likely impact, but it should not be the only mechanism used to identify sinks, entry points, or privileged operations. For AI-enabled review workflows, the OWASP Agentic AI Top 10 and the NIST AI 600-1 Generative AI Profile both reinforce the need for output validation, bounded autonomy, and careful oversight.

• Use the LLM to identify candidate issues, then confirm them with deterministic scans.
• Ask the model to map taint flow, but verify reachability with code search and analysis tools.
• Require file-level and function-level evidence for each finding.
• Cross-check high-risk paths such as auth, deserialization, file I/O, and network egress.
• Track false negatives separately from false positives so coverage gaps are visible.

This approach works best when the repository is well structured and the review scope is explicit. These controls tend to break down in monorepos with weak dependency boundaries, dynamic dispatch, generated code, or heavy feature-flag use because the model cannot reliably reconstruct the reachable path space.

Common Variations and Edge Cases

Tighter review gates often increase analysis overhead, requiring organisations to balance speed against confidence. That tradeoff becomes sharper when teams want LLM-assisted review in fast-moving CI pipelines, because a shallow pass may be acceptable for low-risk refactors but not for authentication, authorization, or input-handling changes.

There is no universal standard for how much reasoning should be delegated to a raw model versus a static toolchain. Current guidance suggests using the LLM as a judgment aid, not as the source of truth. The most mature workflows also test the model against adversarial conditions. The MITRE ATLAS adversarial AI threat matrix is relevant when prompts, context, or retrieved code can be manipulated. For agentic review systems, the CSA MAESTRO agentic AI threat modeling framework helps teams think about tool use, escalation paths, and trust boundaries.

Edge cases also matter. A raw LLM may perform well on a small service with clear entry points, then fail badly on polyglot systems, code generated from schemas, or applications where business logic is split between infrastructure as code, application code, and runtime configuration. The risk is highest when reviewers assume that a persuasive explanation equals complete coverage. For that reason, human review should focus on verifying what was searched, what was omitted, and what execution paths were proven reachable.

Related resources from NHI Mgmt Group

• Why do code scanners miss so many authorization bugs?
• What is the difference between code review and access review in AI-generated software?
• How should security teams govern LLMs that can call tools or run code?
• Why do traditional security tools miss many AI security risks?