Why can LLM-based code review catch issues that SAST misses?

Why LLM-Based Review Finds Different Defects Than Pattern-Based Scanners

LLM-based review is useful because it can evaluate the code as a system, not just as a set of signatures. It can follow data flow, understand intent, and notice when a sequence is unsafe even if no individual line looks suspicious. That is why it often surfaces logic errors, misuse of trust, and cross-component failure paths that static pattern matching can overlook.

The practical difference is context sensitivity. A scanner may recognise a known insecure call or a hard-coded secret, but miss a defect where a safe-looking function becomes risky because of surrounding assumptions, inconsistent state handling, or a boundary crossing between services, roles, or trust zones. An LLM can sometimes infer that broader execution context from surrounding code, comments, tests, and call structure.

That advantage is strongest for defects that are emergent rather than syntactic. For example, insecure fallback logic, privilege confusion, confused-deputy style flows, and validation gaps across multiple functions are easier to reason about when the reviewer can connect the dots across a larger section of the codebase. A conventional static rule engine can still be excellent at known bad patterns, but it is less flexible when the issue depends on the interaction between components.

Where SAST Still Has the Edge

SAST is deterministic, repeatable, and good at finding well-defined patterns at scale. It is especially effective for issues with crisp signatures, such as known dangerous functions, obvious injection sinks, missing sanitisation in predictable locations, or policy violations that can be encoded directly into rules. It also gives teams a stable baseline for regression checking across commits.

LLM-based review does not replace that baseline. It can miss issues too, especially when the code is large, ambiguous, or incomplete, and it may overstate a concern that needs deeper verification. The best workflow is usually complementary: let SAST catch what is explicit and machine-checkable, and use the LLM to probe for context-dependent defects that a rule set cannot easily express.

That complement is also why LLM review can be valuable earlier in the triage loop. It can help prioritise which findings deserve deeper human analysis, identify likely false negatives in areas where a codebase has complex control flow, and explain why a supposedly harmless change may alter the trust model. A useful review result is not just “this is vulnerable”, but “this path only becomes safe if the upstream assumption still holds”.

What Practitioners Should Trust, Verify, and Escalate

LLM-based review is best treated as a reasoning aid, not an oracle. Its output is probabilistic, which means the same code can produce different quality depending on prompting, surrounding context, and how much of the relevant call chain is visible. The right use is to broaden coverage and sharpen suspicion, then confirm the result with tests, code inspection, or a second reviewer.

In practice, the highest-value use case is code whose risk comes from intent and interaction, not just syntax. That includes code that mediates between trust zones, handles authorization decisions, assembles prompts or requests from multiple inputs, or translates one security boundary into another. In those cases, a NIST Cybersecurity Framework 2.0 style control mindset fits well: use the review to strengthen control confidence, then validate the control with evidence rather than relying on one pass of analysis.

Practitioner takeaway: use LLM review to expand the set of defects you can see, but keep SAST for repeatable enforcement and require human verification for any finding that changes security or release decisions.

Risk and Threat Considerations

The main risk is over-trust. If teams assume the model has “understood” the code, a subtle logic flaw or trust-boundary mistake can ship because no deterministic rule fired. The reverse risk also matters: false positives can waste review capacity, causing teams to ignore findings that actually deserve escalation.

Failure mechanism: SAST only detects what it can express as rules, so defects that depend on multi-step reasoning, state, or cross-function interaction can pass unnoticed unless another reviewer reconstructs the path.

Impact: Missed logic flaws, authorization mistakes, unsafe defaults, and boundary violations can survive into production, where they are harder and more expensive to correct.

Practitioner Guidance

What to verify: Treat the model’s explanation as a hypothesis and verify the exact call path, precondition, and boundary assumption it relied on. If the issue cannot be demonstrated from the code or test evidence, downgrade confidence quickly.

Common mistake: Using LLM review as a replacement for secure code review standards instead of as an additional lens for context-heavy defects. That shortcut usually works until the first subtle interaction bug escapes.

What good looks like: SAST, LLM review, and human review each find different classes of issues, and the team can say which class each control is expected to cover. That separation makes misses easier to diagnose and improves triage quality over time.

Practitioner takeaway: The strongest programme is not “LLM versus SAST”, it is a layered review process where deterministic checks catch known patterns and contextual reasoning hunts for the defects that only make sense in the full design.

Related resources from NHI Mgmt Group

• How should security teams combine automated code review tools to catch more AppSec issues in open source projects?
• Why do pattern-based code queries help find issues that simple grep misses?
• How should teams structure testing for LLM applications so they catch both code defects and model quality issues before release?
• Why does cross-model review catch issues that single-model review misses?