Static Application Security Testing
SAST analyses source code without executing it to find security defects early, trading false positives for speed and shift-left coverage.
Definition
Static application security testing (SAST) inspects source, bytecode, or binaries for patterns that indicate vulnerabilities — tainted data reaching a sink, unsafe deserialization, hardcoded secrets — without running the program. It builds a model of data flow and control flow and reports where untrusted input can reach a dangerous operation. Because it reasons over all paths, it can flag issues no test exercises, at the cost of false positives that must be triaged.
Context and scope
Integrated into CI and IDEs to catch injection, unsafe crypto, and secret leaks before code reaches a reviewer or a runtime.
Common misconceptions
- SAST proves the absence of vulnerabilities — it finds classes of issue it can model; logic flaws and misconfigurations often escape it
- Zero findings means safe code — a clean run may reflect coverage gaps, not the absence of defects
- SAST replaces dynamic testing — SAST and DAST find different things and are complements, not substitutes
Anti-patterns
- Gating merges on every low-severity finding until developers learn to ignore the tool
- Scanning only at release, when fixing a taint flow requires rework across many files
- Suppressing findings to make the dashboard green without recording the risk decision
Related concepts
Related examples
Authoritative source
What it is
A SAST tool parses code into an intermediate representation, builds control-flow and data-flow graphs, and tracks untrusted values from sources such as request parameters to dangerous sinks such as SQL execution or command shells. When a path connects them without sanitisation, it reports a finding with the trace. Rules encode known dangerous patterns; the engine supplies reachability, which is what separates it from a grep.
Why it matters
Fixing a vulnerability found in code review or production costs far more than catching it as code is written. SAST runs without a deployed environment, so it can cover every commit and every branch. It is especially effective on the injection and unsafe-API classes where the pattern is visible statically, and it gives reviewers evidence rather than intuition about taint paths.
How to use it well
Run it on changed code in CI so feedback is fast and scoped, and reserve full-repository scans for a nightly job. Tune rules to your frameworks to cut noise, triage findings rather than blanket-suppressing them, and record every suppression with an owner and a reason. Pair it with secret scanning and dependency analysis, and treat a green SAST run as one signal among several.