What breaks when SAST is used without reachability analysis in AI-generated code?

Teams end up treating every pattern match as equally important, even when the vulnerable path is blocked by sanitisation or never deployed. In AI-generated codebases, that creates noise, slows triage, and reduces trust in the security workflow. Reachability analysis is what separates useful remediation from alert fatigue.

Why This Matters for Security Teams

Static application security testing is valuable only when its findings are prioritised against actual execution paths. Without reachability analysis, SAST on AI-generated code treats pattern matching as if it were risk confirmation, which is not how secure engineering works. The result is a queue full of theoretical issues, while the defects that can actually be exercised through deployed code receive less attention. NIST control language in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it pushes teams toward risk-based control selection, not blanket treatment of every signal as equal.

AI-generated code makes this problem worse because generated functions often include defensive branches, unused helpers, copied snippets, and framework boilerplate that never become part of a live path. A scanner can still flag all of it. If the pipeline cannot tell whether tainted input can actually reach the sink, security teams spend time arguing about findings instead of reducing exposure. In practice, many security teams encounter the cost of this mismatch only after developers have already started ignoring SAST output, rather than through intentional risk-based triage.

How It Works in Practice

Reachability analysis adds context to SAST by asking a second question after pattern detection: can this code path actually be invoked in the running application? That usually means tracing entry points, data flow, call chains, feature flags, framework routes, and sanitisation steps to determine whether a flagged sink is genuinely exposed. In AI-generated code, this matters because generated code is often broad, repetitive, and sometimes over-defensive, so a syntactic match alone tells very little.

Operationally, teams usually get better results when they combine SAST with:

• Call graph or interprocedural analysis to map whether the vulnerable function is reachable.
• Data-flow checks to see whether user-controlled input can arrive at the sink unsanitised.
• Deployment context so dormant test code, examples, and dead helpers are not prioritised.
• Developer-facing findings that explain why a rule is actionable or why it is low risk.

This approach aligns with secure software assurance guidance from OWASP Top 10 and the secure design principles embedded in MITRE CWE, because both emphasise exploiting real weakness patterns rather than counting every code smell equally. It also becomes more important in MLOps-heavy environments where AI tools generate application code at speed, because the volume of code can outpace manual review and make triage quality the main control point. These controls tend to break down when scanners operate on partial repositories, generated code is not linked to deployment manifests, or the application relies on dynamic routing that static analysis cannot model accurately.

Common Variations and Edge Cases

Tighter reachability analysis often increases build-time cost and tooling complexity, requiring organisations to balance better precision against pipeline latency and false negatives introduced by incomplete modelling. That tradeoff is real, especially when AI-generated code is emitted across multiple repositories, languages, or service boundaries.

Best practice is evolving on how much context is enough. Current guidance suggests that teams should not wait for perfect path sensitivity before acting, but they should avoid treating every SAST issue as urgent without at least basic reachability signals. The exception is security-critical code, such as authentication, file handling, deserialisation, and secrets processing, where a conservative stance is still appropriate even if the analysis is imperfect.

Some edge cases need special handling. Generated wrappers may look vulnerable while the actual risky call sits in a shared library. Feature-flagged code may be reachable only in specific environments. Sanitisation may appear strong in the source tree but be bypassed by alternate inputs in production. In those cases, the right response is not to suppress SAST broadly, but to confirm whether the warning is reachable in the deployed path and to document the decision. For teams using AI-assisted development, this is the difference between scalable remediation and a security backlog that loses credibility.

Related resources from NHI Mgmt Group

• What breaks when AI root-cause analysis is used without ground truth?
• What breaks when AI-generated code is reviewed without security gates?
• What breaks when AI-generated code reaches authentication and authorisation logic without stronger verification?
• What is the difference between SAST and semantic AI code analysis?