What is SAST (Static Application Security Testing)?
Updated
Static Application Security Testing (SAST) analyzes an application's source code, bytecode, or binaries for security vulnerabilities without executing the program. Because it works from the inside on the code itself, it can point to the exact file and line where a flaw such as an injection or an unsafe deserialization was introduced.
SAST is a 'white-box' technique: it sees everything the code sees. That makes it strong at finding first-party coding flaws early — it can run on every commit before anything is deployed — but it only covers the code a team wrote, which is why it is paired with software composition analysis for dependencies and DAST for runtime behavior.
How SAST works and what it catches
A SAST tool parses code into a model — an abstract syntax tree and data-flow graph — and traces how untrusted input moves through the program to sensitive operations. When input can reach a dangerous sink without proper validation, it flags a potential vulnerability. This lets it catch classic first-party flaws: SQL injection, cross-site scripting, path traversal, hardcoded credentials, and unsafe use of cryptography.
Because it runs on static code, SAST fits naturally into continuous integration: it can gate a pull request before merge, giving developers feedback while the change is fresh. Its main weakness is false positives — a flagged path that is unreachable in practice — so mature programs tune rules and triage findings rather than treating every alert as a confirmed bug.
SAST, DAST, and SCA cover different ground
The three common application-security techniques are complementary, not interchangeable. SAST reads first-party code statically and finds flaws early. DAST exercises the running application from the outside and finds flaws that only appear at runtime, including configuration and authentication issues. Software composition analysis inventories third-party dependencies and their known vulnerabilities — the code a team imported rather than wrote.
A program that runs only one has a predictable blind spot: SAST-only misses runtime and dependency risk; DAST-only misses code-level flaws in paths it never exercises; SCA-only ignores the team's own code entirely. Coverage across all three, with findings deduplicated and normalized, is what produces an honest picture of application risk.
Frequently asked questions
What is the difference between SAST and DAST?
SAST analyzes source code without running it, finding first-party coding flaws early and pointing to the exact line. DAST exercises the running application from the outside, finding flaws that only appear at runtime such as configuration and authentication issues. They cover different parts of the attack surface, so mature programs run both.
Does SAST cover open-source dependencies?
No. SAST analyzes the code a team wrote. Vulnerabilities inherited from third-party and open-source libraries are the domain of software composition analysis (SCA). Since most exploitable flaws today live in dependencies, SAST and SCA are run together to cover both first-party and imported code.
Why does SAST produce false positives?
SAST reasons about code paths statically, so it can flag a route from untrusted input to a sensitive operation that is actually unreachable or already mitigated at runtime. Reducing false positives is a matter of tuning rules and triaging findings, which is why SAST results are reviewed rather than treated as confirmed bugs automatically.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.