SAST means Static Application Security Testing — analyzing an application's source code, bytecode, or binaries for security vulnerabilities without running the program. The "static" is the key word: SAST reads your code the way a compiler does, tracing how data flows through it, and flags dangerous patterns like an unsanitized user input reaching a SQL query. Because it works on code at rest, it can run the moment a developer saves a file or opens a pull request, which is why SAST is the earliest security check most teams add. This guide explains what SAST means in practice, how it works, what it catches, where it falls short, and how it fits with the other acronyms.
What does SAST mean, in plain terms?
SAST is automated code review for security. Instead of a person reading every line looking for flaws, a SAST tool parses your codebase into a model it can reason about and searches that model for known vulnerable patterns. It's "white-box" testing — it sees the source, unlike a black-box test that only pokes at a running app from the outside.
The everyday value is timing. Because SAST doesn't need a deployed, running application, it fits inside the developer's inner loop: as an IDE plugin flagging issues while you type, or as a pull-request check that comments on the exact line introducing a flaw. Catching a vulnerability as a one-line diff is enormously cheaper than catching it after it ships.
How does SAST actually work?
Under the hood, most SAST engines do some version of the same thing:
- Parse the code into an abstract syntax tree (AST), a structured representation of the program.
- Build a data-flow and control-flow model so the tool understands how a value moves from where it enters the program (a "source," like an HTTP parameter) to where it's used (a "sink," like a database query, a shell command, or an HTML response).
- Run taint analysis, tracking whether untrusted data reaches a dangerous sink without passing through validation or sanitization. That source-to-sink path is the core of how SAST finds injection flaws.
- Match rules for patterns that don't need flow analysis — hardcoded secrets, weak cryptography, insecure random number generation.
A simplified example of what SAST flags:
# SAST traces user-controlled `name` (source) into the query (sink)
name = request.args.get("name")
cursor.execute("SELECT * FROM users WHERE name = '" + name + "'") # SQL injection
The tool sees that name comes from an untrusted source and reaches a SQL execution sink through string concatenation, with no parameterization in between, and reports a SQL injection finding on that line.
What does SAST catch, and what does it miss?
SAST is strong at a specific set of vulnerability classes — mostly the ones visible in the structure of the code itself:
- Injection flaws (SQL, command, LDAP, path traversal).
- Cross-site scripting where untrusted data reaches an output sink.
- Hardcoded credentials and secrets.
- Weak or misused cryptography.
- Insecure configuration expressed in code.
What SAST cannot see is just as important to understand:
- Runtime and environment issues. Authentication logic that depends on a misconfigured server, or a flaw that only appears with production data, is invisible to a tool that never runs the app.
- Business-logic flaws. SAST doesn't know that "users shouldn't be able to refund an order twice" — that's not a code pattern, it's a rule about intent.
- Vulnerabilities in third-party dependencies. SAST analyzes your code. A known CVE in a library you imported is a different tool's job (that's SCA).
The other well-known SAST cost is false positives. Because it reasons about all possible paths, not just the ones that actually execute, it flags things that can't really happen. Tuning rules and prioritizing by reachability is what separates a SAST rollout developers trust from one they mute.
How does SAST compare to DAST and SCA?
The three main acronyms are complementary, not competing:
- SAST (this one) reads your source code at rest, early, from the inside. Great for injection and code-level flaws; blind to runtime and dependencies.
- DAST — Dynamic Application Security Testing — tests a running application from the outside, like an attacker, sending requests and observing responses. It catches runtime and configuration issues SAST can't see, but only for code paths it can reach, and later in the cycle.
- SCA — Software Composition Analysis — inventories your open-source dependencies and flags known vulnerabilities (CVEs) in them. Since most modern code is mostly third-party dependencies, this covers a surface SAST doesn't touch.
A common misconception is that you pick one. You don't — SAST for your code, SCA for your dependencies, DAST to confirm what's exploitable at runtime. Together they cover source, supply chain, and runtime.
Where does SAST fit in a pipeline?
Because it's fast and needs no running app, SAST belongs as early as possible:
- In the IDE, for immediate feedback while writing code.
- On the pull request, as a required check that comments on the introducing line and fails the build on new high-severity findings with a clear fix.
- On merge to main, for a fuller, slower pass that can afford deeper analysis.
The discipline that keeps SAST useful is scoping the blocking checks to new issues a change introduces, rather than failing every build on a backlog of pre-existing findings — that's the difference between a control developers rely on and one they route around. For teams formalizing this, the DevSecOps fundamentals cover how to stage SAST, SCA, and DAST so each runs where it adds the most value.
FAQ
What does SAST stand for?
SAST stands for Static Application Security Testing. "Static" means it analyzes code without executing it — reading source, bytecode, or binaries to find security vulnerabilities.
Is SAST the same as a linter?
No. A linter checks style and common bugs. SAST specifically performs security analysis, including data-flow and taint tracking to find how untrusted input reaches dangerous operations. There's overlap in mechanics, but the intent and depth differ.
Does SAST find vulnerabilities in open-source libraries?
No — that's SCA's job. SAST analyzes your first-party code. A known CVE in a dependency you imported is found by Software Composition Analysis, which is why teams run both.
Why does SAST produce so many false positives?
Because it reasons about all possible code paths, including ones that never actually execute, it flags theoretical issues that can't occur in practice. Reachability analysis and rule tuning reduce the noise so developers act on findings instead of muting the tool.