What Is SAST? Static Application Security Testing Explained
Static Application Security Testing (SAST) analyses source code, bytecode or binaries without running the application. It looks for patterns and data flows that indicate vulnerabilities, ideally before code ever reaches production.
How SAST works
Modern SAST tools build a model of your code and trace how data flows from sources, such as request parameters, to sinks, such as SQL queries, shell commands or HTML output. If untrusted data reaches a dangerous sink without passing through a sanitiser, the tool reports a finding.
Simpler tools match patterns, such as calls to eval() or hardcoded passwords.
What SAST finds well
- SQL injection and command injection patterns.
- Cross-site scripting sinks.
- Path traversal and unsafe file handling.
- Insecure deserialisation.
- Hardcoded secrets.
- Use of weak cryptography.
- Dangerous functions and insecure framework settings.
What SAST misses
- Authorisation logic. SAST cannot know that user A should not see user B's data.
- Business logic flaws.
- Runtime configuration such as headers, TLS and cloud settings.
- Issues across services, where data flows through queues or APIs.
- Vulnerabilities in how the deployed system behaves, as opposed to how the code reads.
The noise problem
SAST's biggest weakness is false positives. Tools often cannot tell whether input was validated elsewhere or whether a code path is reachable. Teams that turn on every rule quickly learn to ignore the results.
Make SAST useful:
- Start with a small, high-confidence rule set: injection, secrets, dangerous functions.
- Run on pull requests, showing only new findings in changed code.
- Tune and suppress with documented reasons.
- Track precision: if most findings are dismissed, adjust rules.
SAST in the development workflow
| Stage | Use |
|---|---|
| IDE | Instant feedback on obvious issues |
| Pull request | New findings in changed code, blocking for high-confidence criticals |
| Main branch | Full scans tracked over time |
| Release | Evidence for audits |
SAST and AI-generated code
AI coding assistants produce code quickly, including insecure patterns like string-built SQL, missing authorisation and hardcoded keys. SAST in pull requests is a useful safety net, but it will not catch missing authorisation, which needs runtime testing.
Combine SAST with dynamic testing
SAST sees the code; dynamic testing sees the running application. Together they cover far more than either alone. See SAST vs DAST vs IAST.
SecurityInfinity combines static analysis for secrets and insecure code with AI pentesting agents that test the running application, so findings are verified in context. Start free.
Frequently asked questions
Is SAST the same as code review?
No. SAST is automated analysis. Human security code review catches logic and design issues that SAST cannot.
Does SAST work for all languages?
Coverage varies by tool. Check support for your languages and frameworks, since framework awareness greatly improves accuracy.
Is SAST required for SOC 2?
Not explicitly, but it is common evidence for secure development controls alongside code review and testing.