What's the difference between SAST, DAST, and IAST?

These three acronyms describe complementary ways to find vulnerabilities in an application, and a strong candidate explains the trade-offs rather than reciting definitions.

Static (SAST)

Static Application Security Testing analyzes source code, bytecode, or binaries without executing them. It traces data flow from untrusted inputs (sources) to dangerous operations (sinks) to flag things like SQL injection or XSS. Because it sees the whole codebase, it runs early — often on every commit or pull request — and points to the exact line. The cost is false positives: it cannot tell whether a flagged path is actually reachable at runtime, so triage burden is real.

Dynamic (DAST)

Dynamic Application Security Testing attacks the running application from the outside, like an unauthenticated attacker, with no view of the source. It finds genuinely exploitable issues — broken auth, misconfigurations, injection that actually fires — and produces fewer false positives. The downsides: it runs late (you need a deployed environment), coverage depends on how thoroughly it crawls the app, and it can't point to the offending code.

Interactive (IAST)

Interactive Application Security Testing puts an agent inside the running app and watches code execution while the app is exercised (often by existing functional or DAST tests). By correlating runtime data flow with the actual code, it gives accurate findings with line-level context — fewer false positives than SAST, more code insight than DAST. The catch: it needs runtime instrumentation, language/runtime support, and good test coverage to exercise the paths.

What none of them catch well

Business-logic flaws, broken authorization, and design weaknesses slip past all three — those need threat modeling and manual review.

What interviewers look for

They want you to position these as layers in a pipeline, name a concrete strength and weakness of each, and acknowledge that automated scanning never replaces human review.