Static Application Security Testing (SAST)

Static Application Security Testing analyses an application’s source code, bytecode, or binaries without executing the program. Because it works on the code itself, it is white-box testing: the tool sees every path, including ones no user has yet exercised, and can flag the exact file and line where a flaw lives. Typical catches are injection flaws, buffer overflows, hardcoded credentials, and unsafe library calls. SAST runs early, in the developer’s IDE or on every commit in a DevSecOps pipeline.

The trade-off is context. SAST cannot see the running environment, so it misses configuration errors, authentication weaknesses, and anything that only appears at runtime. It also produces a high false positive rate: the tool flags code that looks dangerous but is unreachable or already mitigated, so findings need human triage before anyone raises a defect. A clean SAST report therefore does not mean a secure deployment.

Exam relevance: if a scenario mentions analysing code without running it, scanning at commit time, or identifying the precise line of a flaw, the answer is SAST. The confusable term is Dynamic Application Security Testing, which tests the running application from outside and finds runtime issues SAST misses; the two are complements, not competitors, and mature pipelines run both.