Static Application Security Testing (SAST) analyzes source code, bytecode, or binaries for security vulnerabilities without running the program. It looks for dangerous patterns — SQL concatenation reaching a query, user input flowing into a command, weak cryptography — by modeling how data moves through the code.
How SAST works
Modern SAST engines parse code into an abstract representation, then run taint analysis: tracking untrusted input from sources (HTTP parameters, file reads) to sinks (queries, commands, responses) and flagging paths that lack sanitization. Rules encode vulnerability classes such as the OWASP Top 10 and CWE categories.
Strengths and limits
- Strength: finds issues early — at the pull request or build, before code ships.
- Strength: full code coverage, including paths tests never execute.
- Limit: false positives are inherent; static analysis over-approximates real behavior.
- Limit: cannot see runtime configuration, deployment context, or third-party services.
Where SAST runs in CI/CD
The two natural surfaces are the pull request — fast, diff-focused feedback while the developer has context — and the build pipeline, where the full artifact gets an authoritative verdict. Mature programs use both, backed by one policy.
