SAST for AI-Generated Code: What Static Analysis Catches and Misses | Blog | Endor Labs

What it is

An Endor Labs blog post arguing that for AI-generated code the SAST problem is triage, not detection, and giving a concrete test to tell real "AI-native" SAST from a rules-plus-LLM wrapper. The distinguishing criterion: does the tool trace dataflow across multiple files and apply reachability analysis, or does it match patterns within a single file?

How it works

The post names the mechanism that separates the two tool classes:

• Multi-file dataflow — trace data from a source (where untrusted input enters, e.g. a web request) to a sink (a dangerous operation, e.g. a DB query or shell command), following the path across files and functions rather than within one file. This is what catches auth and business-logic flaws that single-file rule engines never connect.
• Reachability — separate exploitable findings from noise by determining whether a flagged path is actually reachable (the page cuts off mid-definition here).

The failure mode it opens with: a scan comes back clean — no injection, no hardcoded secret — while the code lets any logged-in user read every other user's records. That broken-access-control flaw is a decision the model made, not a pattern any signature rule describes.

Preconditions / Affected

Applies to any team merging AI-assistant/agent output through a rule-based SAST pipeline. The four pressures that make it acute:

1. Volume floods the queue — a manageable list becomes thousands of findings/month.
2. Provenance is lost — no human author to route a finding to.
3. Insecure patterns repeat at scale — one weak pattern reproduced across many files.
4. Velocity outpaces review — code merges faster than triage.

Supporting figures cited: ~30% of AI-generated snippets carried weaknesses spanning 43 CWEs; AI-assisted developers commit at 3–4× the rate of non-AI peers; one org's monthly findings rose ~1,000 → 10,000+ over six months; developers lose ~3.5 hrs/week to triage, much later deemed inapplicable.

What to do

No commands. The actionable guidance is an evaluation stance:

• When buying SAST, verify it does cross-file dataflow + reachability, not a rules engine with an LLM wrapper — both are sold under the same label.
• Don't rely on prompting the assistant to "write secure code": the model has no view of your threat model, so it guesses.
• Treat three AI-era classes as invisible to signature rules: prompt injection (OWASP LLM01, natural-language input flowing through app logic), hallucinated/slopsquatted dependencies (packages that are unsafe or don't exist), and design drift (copying an insecure architecture that breaks a security invariant).

Caveats

Vendor content (Endor Labs sells AI-native SAST), so the framing favors their product category. The page text is truncated mid-sentence in the reachability section, so the full reachability mechanism isn't stated. The post concedes AI code is not worse than human code by default — flaws arrive at similar rates, just faster.