What Is SAST? Static Application Security Testing

A developer commits a function that builds a SQL query by concatenating a user-supplied string. Nothing breaks. The tests pass, the build is green, the feature ships. Three weeks later that line is the injection point in a breach report. The flaw was visible the moment the code was written, in the source itself, before anything ran. Catching it there is the job of static application security testing.

Static application security testing (SAST) analyzes an application's source code, bytecode, or binaries for security flaws without executing the program. It reads the code the way a reviewer would, but at machine speed and across the whole codebase, and flags the patterns that lead to vulnerabilities: an unsanitized input reaching a query, a secret hard-coded in a config file, a call to a broken cipher. Because it works on code at rest, it runs the earliest of any application security test, often before the code is merged.

This guide defines SAST, walks how it works, lists what it actually finds and what it misses, contrasts it with dynamic testing, and shows where it sits in the development pipeline.

What is SAST?

SAST is a white-box testing method: it has full access to the application's internal source and analyzes that code directly, rather than probing a running app from the outside. The tool parses the code into a model it can reason over, traces how data moves through the program, and reports the spots where that flow produces a known class of weakness. No part of the application has to run for this to work.

The defining trait is the word static. SAST inspects code that is not executing. That is what lets it run on a single file, a feature branch, or a pull request, long before there is a deployable artifact to attack. It is the opposite of testing a live system. It is testing the blueprint.

SAST works on three forms of code:

• Source code. The human-written code in the repository. This is the most common and most useful target, because a finding maps straight to a file and line a developer can fix.
• Bytecode. Intermediate compiled output, such as Java bytecode or .NET CIL, analyzed when source is not available but the compiled form is.
• Binaries. Compiled machine code, analyzed when only the built artifact exists. This is the hardest to map back to a readable cause.

Because it reads code instead of behavior, SAST is language-aware. A scanner has to understand the grammar and the security-relevant APIs of each language it supports, which is why tools advertise coverage for specific languages and frameworks. A scanner that understands Java will not, on its own, reason correctly about Python.

How SAST works

A SAST scan is not a text search for bad words. It builds a structural understanding of the code and follows data through it. The pipeline runs in stages.

• Parse. The tool reads the code and builds an abstract syntax tree (AST), a structured representation of every statement, function, and control path. This is what lets it tell a string that is a SQL query from a string that is a log message.
• Model. From the AST it derives data-flow and control-flow models: where values come from, where they go, and which branches reach which code.
• Analyze. It runs taint analysis and pattern rules over those models. Taint analysis tracks untrusted input (a source, like an HTTP parameter) to a dangerous operation (a sink, like a database call) and flags any path where the input reaches the sink without being sanitized.
• Report. Each finding comes back with the file, the line, the vulnerable data path, and usually a severity and a rule reference (often a CWE identifier).

Two analysis terms describe the depth of that work. Lexical analysis looks at tokens and patterns, fast but shallow and prone to noise. Semantic analysis understands meaning, types, and data flow across functions, slower but far more accurate. Serious SAST leans on the semantic side; pure pattern-matching is what produces a wall of false alarms.

Where SAST runs matters as much as how. It integrates with source control like Git and embeds into the CI/CD pipeline, so a scan fires automatically on each commit or pull request. Findings land in front of the developer who wrote the code, in the same workflow, while the change is still fresh. That placement is the entire point: feedback at the moment of writing, not weeks later in a separate report.

What SAST detects, and what it misses

SAST is strongest on flaws that live in the code itself, the kind a careful reviewer could find by reading. It is blind to anything that only appears when the application is running, configured, and connected to real systems.

What it reliably finds:

• Injection flaws. SQL injection, command injection, and similar, where untrusted input reaches an interpreter. These are textbook taint-analysis targets.
• Cross-site scripting (XSS). User input written to a page without proper encoding, traced from source to sink in the code.
• Hard-coded secrets. API keys, passwords, and tokens committed into source or config.
• Insecure cryptography. Use of broken algorithms (MD5, DES), weak modes, or predictable random number generation.
• Buffer overflows and memory bugs. In languages like C and C++, unsafe operations that risk memory corruption.
• Code-quality and correctness defects. Undeclared variables, dead code, and syntax issues that often sit next to real security problems.

What it cannot see:

• Runtime and environment flaws. Race conditions, authentication failures that depend on session state, and bugs that only surface under real traffic. SAST never runs the app, so it never observes them.
• Configuration of the deployed system. Misconfigured servers, exposed ports, and environment-specific settings live outside the source the scanner reads.
• Business-logic abuse. A workflow that lets a user skip a payment step may be perfectly valid code. There is no insecure pattern to match.

And the cost that comes with the method: SAST produces false positives. Because it reasons about every possible path through the code, including ones that cannot occur at runtime, it flags issues that are not exploitable in practice. Every finding needs triage, and a noisy tool that is never tuned gets ignored, which is its own failure mode. Reducing that noise, through better rules and suppression of confirmed non-issues, is a standing part of running SAST well.

SAST vs DAST

The cleanest way to understand SAST is against its counterpart. Dynamic application security testing (DAST) is the inverse method: it tests a running application from the outside, with no access to the source code, by sending crafted requests and watching how the app responds. SAST reads the code; DAST attacks the deployment. They find different bugs, and a mature program runs both.

The split is consistent. SAST knows exactly where a flaw lives in the code but cannot prove it is exploitable at runtime. DAST proves exploitability from the outside but cannot point to the line that caused it. One sees the cause, the other sees the effect. Interactive application security testing (IAST) sits between them, instrumenting a running app to combine source-level location with runtime confirmation, and software composition analysis (SCA) covers the third-party dependencies SAST handles poorly.

SAST in the SDLC

SAST earns its value by running early and often, which is the heart of the shift-left idea: move security testing toward the start of development, where a fix is cheap, instead of the end, where it is expensive and slow. A flaw caught in a pull request is a code-review comment. The same flaw caught in production is an incident.

In a modern pipeline, SAST is wired in at several points:

• In the IDE. Some tools flag issues as the developer types, the fastest possible feedback loop.
• On pull request. A scan runs automatically when code is proposed for merge, blocking or annotating risky changes before they land.
• In CI/CD. A scan runs on each build, with policy gates that can fail the build on new high-severity findings.

This is why SAST is a foundational control in a DevSecOps practice, where security testing is automated into the same pipeline that builds and ships the code, owned by the development team rather than bolted on at the end.

SAST does not stand alone. It covers first-party source code; SCA covers open-source dependencies; DAST and IAST cover runtime behavior; and application security posture management (ASPM) aggregates the findings from all of them into one prioritized view. SAST is the first and earliest layer of that stack, the one that reads the code itself. A complete application security testing program runs the others alongside it, because no single method sees every flaw.

Frequently Asked Questions

What is static application security testing (SAST)?

Static application security testing is a white-box method that analyzes an application's source code, bytecode, or binaries for security vulnerabilities without executing the program. It parses the code, traces how data flows through it, and flags patterns that lead to flaws like injection, cross-site scripting, hard-coded secrets, and weak cryptography. Because it works on code at rest, it runs earlier than any other application security test.

What is the difference between SAST and DAST?

SAST is white-box testing: it reads the source code directly, without running the application, and finds flaws like SQL injection and hard-coded secrets mapped to an exact file and line. DAST is black-box testing: it has no access to the source and instead sends attacks to a running application to find runtime, configuration, and authentication issues. SAST sees the cause in the code; DAST sees the effect at runtime. They are complementary, and mature programs use both.

What vulnerabilities can SAST detect?

SAST reliably detects code-level flaws: injection (SQL, command), cross-site scripting, hard-coded credentials and secrets, insecure or broken cryptography, buffer overflows in memory-unsafe languages, and code-quality defects. It cannot detect issues that only appear at runtime, such as race conditions, authentication failures that depend on session state, deployment misconfigurations, or business-logic abuse.

When should SAST run in the development lifecycle?

SAST should run as early and as often as possible, the shift-left approach. In practice that means in the developer's IDE as code is written, automatically on each pull request, and in the CI/CD pipeline on every build, where policy gates can fail a build on new high-severity findings. Running it early means a flaw is fixed as a code-review comment rather than a production incident.

Why does SAST produce false positives?

SAST reasons about every possible path through the code, including paths that cannot actually occur when the program runs, so it flags some issues that are not exploitable in practice. It also lacks runtime context, like which inputs are truly reachable. Every finding therefore needs triage, and tuning the rules and suppressing confirmed non-issues is a standing part of running SAST well, so the real findings do not get buried in noise.

Is SAST enough on its own?

No. SAST covers first-party source code, but it misses runtime behavior, deployment configuration, business-logic flaws, and most issues in third-party dependencies. A complete program pairs it with software composition analysis for open-source components, DAST or IAST for runtime testing, and posture management to aggregate the results. SAST is the earliest layer, not the whole stack.

The bottom line

SAST is the earliest security test in the development lifecycle. It reads source code, bytecode, or binaries without running them, traces untrusted data from input to dangerous operation, and reports each flaw at the file and line where it lives. That placement is its strength: it catches injection, cross-site scripting, hard-coded secrets, and weak cryptography while the code is still being written, where a fix costs a code-review comment instead of an incident response.

It is not complete on its own. SAST is blind to runtime behavior, deployment configuration, and business logic, and it trades that early reach for false positives that have to be triaged. Run it as the first layer, wired into source control and CI/CD, and pair it with dynamic testing, dependency scanning, and posture management. The code-level view plus the runtime view is what actually covers an application.