SAST

How it works

SAST (Static Application Security Testing) analyzes an application's source code, bytecode, or binaries for security flaws without running the program. It reads the code the way a compiler does and traces how data flows through it, flagging patterns like SQL injection, hardcoded secrets, and unsafe deserialization. Because it works on static code, SAST runs early in development (in the IDE or CI pipeline) and can point to the exact file and line, which makes fixes cheap. It is white-box testing: it sees the internals. Its counterpart, DAST, tests the running app from the outside.

When it matters

SAST matters for shifting security left, catching vulnerabilities during coding and code review rather than after deploy. It fits naturally in CI, failing a build when a serious issue appears. The tradeoff is false positives: SAST flags code paths that may not be exploitable in practice, so tuning and triage matter. It is one layer of a broader application security program covered in Application Security 101.

Common misconceptions

• "SAST finds every bug." It finds classes it recognizes in code; runtime and logic flaws need DAST and testing.
• "SAST and [DAST](/glossary/dast/) are interchangeable." SAST reads code (white-box); DAST attacks the running app (black-box). Use both.
• "A clean SAST scan means secure." It reduces one class of risk; it is not a security guarantee.