SAST, DAST, SCA, and AI code review: which checks do you need?

If you ship software built with AI, you have probably run into a wall of acronyms: SAST, DAST, SCA, plus the newer “AI code review.” They overlap enough to be confusing and differ enough that picking the wrong one leaves real gaps. Here is the plain-English version.

The three classic checks

SAST, Static Application Security Testing. Reads your source code without running it, looking for insecure patterns: hardcoded secrets, broken auth, untrusted input flowing into a query. Good at code-level flaws; blind to anything that only happens at runtime. See SAST for AI-generated code.

SCA, Software Composition Analysis. Checks your dependencies, the third-party packages your code pulls in, for known vulnerabilities, abandoned libraries, and license risk. Critical now that AI picks libraries no human vetted. See SCA for AI code.

DAST, Dynamic Application Security Testing. Runs the actual application and probes it like an attacker would: endpoints answering without authentication, access control that fails open, misconfigured headers. Catches what static analysis cannot see. See continuous DAST.

Where AI code review is different

“AI code review” is not a fourth scanner so much as a different lens. Classic scanners match known patterns. AI-shaped review looks for the failure modes specific to AI-written code:

• Hallucinated dependencies, packages that do not exist
• Green tests that pass while proving nothing
• Plausible-but-wrong logic that satisfies the prompt but misses the real requirement

A pattern matcher rarely flags these because nothing is technically “a known bad pattern”, the code just does the wrong thing convincingly.

Which do you need?

For AI-built software, the honest answer is usually all of them, working together:

• SAST for code-level flaws
• SCA for the dependency tree AI keeps adding to
• DAST for what only appears when the app runs
• AI-aware review for the mistakes unique to generated code

The trap is buying four disconnected tools that each report into a separate dashboard. The value is in correlation, a runtime finding tied back to the code that caused it, returned where your team already works.

That is the approach behind Enji Guard: one audit across code, dependencies, tests, and runtime, with findings as reviewable GitHub issues or pull requests. The first one is free, see a sample report.