What does SAST stand for? Static application security testing — a category of tool that analyzes an application's source code, bytecode, or binary for security vulnerabilities without ever executing the program. The "static" in the name is the key detail: SAST examines the code as written, tracing how data moves through functions and looking for dangerous patterns, rather than running the application and observing its behavior the way dynamic testing does. That distinction is the sast definition worth actually remembering, because it explains both what SAST is good at (finding bugs early, before a build even exists) and what it structurally can't do (catch anything that only shows up at runtime, like a misconfigured server or an authentication bypass in production).
How does static application security testing actually work?
A SAST tool parses source code into an abstract syntax tree, then traces data flow through that tree looking for a path from an untrusted input source to a dangerous operation — a sink — without adequate validation or sanitization along the way. A classic example is user input from a web form reaching a database query without parameterization, which SAST flags as a potential SQL injection vulnerability by following the exact chain of function calls and assignments between the two points, all without ever running the code. Because it works entirely on source before compilation or deployment, SAST can run the moment code is written — in an IDE plugin, in a pre-commit hook, or in the first stage of a CI pipeline — which is exactly why it's positioned as the earliest and cheapest place to catch a vulnerability in the development lifecycle.
Why does the "static" part matter so much?
Static analysis sees every code path in the program, including branches, error handlers, and rarely executed conditional logic, because it's reading the code's structure rather than watching a single execution trace through it. That's a real strength — dynamic testing can only observe what actually executes during a given test run, and a rare error-handling branch that skips a sanitization step might never get exercised in a normal test suite. It's also the source of SAST's most common criticism: without actually running the code, static analysis has to make assumptions about what values a variable could hold, and when it's overly cautious about those assumptions, it flags things that turn out not to be exploitable in practice, which shows up as a higher false-positive rate than most teams expect going in.
How does SAST differ from DAST and SCA?
Dynamic application security testing takes the opposite approach — it runs the application and interacts with it the way a real user or attacker would, sending live requests and observing the actual responses, which catches runtime-only issues like server misconfigurations that no amount of source code reading would reveal. A DAST tool and a SAST tool are complementary for exactly this reason: one sees every code path but can't confirm runtime behavior, the other confirms real runtime behavior but only for the paths it actually exercises during testing. Software composition analysis is a third, separate category that checks third-party dependencies for known vulnerabilities rather than analyzing first-party code logic at all — a mature SCA program handles the "is this library version vulnerable" question that neither SAST nor DAST is built to answer well on its own.
Where does SAST fit in a development pipeline?
Because SAST needs only source code and no running environment, it's the natural first gate — running against every pull request, ideally with fast enough turnaround that a developer sees results before the code review even happens, which keeps the fix cheap because the developer who wrote the code is still in context. Waiting until a later pipeline stage to run SAST, or worse, only running it on a periodic schedule disconnected from individual commits, defeats a lot of its value, since the whole point is catching an issue at the moment it's cheapest to fix rather than after it's shipped through several more stages of a release process.
What should a team actually evaluate when choosing a SAST tool?
Language and framework coverage is the first practical filter — a SAST tool that's excellent for Java but only lightly supports the team's actual Python or Go codebase won't deliver the coverage its reputation suggests. False-positive rate matters just as much as detection rate, because a tool that buries real findings under a pile of noise trains developers to ignore its output entirely within a few sprints, which is a worse outcome than not running SAST at all. Integration depth — whether it plugs cleanly into the IDE and the existing CI pipeline, or requires a separate dashboard nobody checks — is often the difference between a tool that actually gets used and one that becomes a compliance checkbox.
FAQ
What does SAST stand for in a security compliance context?
The same thing — static application security testing — though compliance frameworks like PCI DSS and SOC 2 sometimes reference it as one acceptable method for meeting a code review or vulnerability testing requirement, alongside manual review or other testing types.
Is the sast definition the same across every vendor?
Yes, the core definition is standard across the industry — static analysis of code without execution. What differs between vendors is the depth of the analysis engine, language support, and false-positive tuning, not the underlying concept.
Can SAST catch every type of vulnerability?
No. It's strong on code-level issues like injection flaws and insecure data flow, but it structurally can't catch runtime misconfigurations, environment-specific issues, or vulnerabilities in third-party binaries it can't source-analyze.
Does SAST need a running application to work?
No — that's the defining feature. SAST analyzes source code, bytecode, or compiled binaries statically, without ever executing the program, which is exactly what distinguishes it from dynamic testing approaches like DAST.