What is SAST? A developer's guide to static application security testing

By Rushabh Shah, Senior Software Developer · 2026-06-25

Static Application Security Testing (SAST) is the practice of analyzing source code — or bytecode, or compiled binaries — for security vulnerabilities without executing the program. A SAST tool reads your code the way a security-aware compiler would: following execution paths, tracking data flow, and flagging patterns that match known vulnerability classes. The key word is *static*: analysis happens offline, on source files, with no running server or test environment required.

That property makes SAST the right tool for catching security bugs when they're cheapest to fix: at the moment a developer writes the code, on every commit, in the CI pipeline before a PR is merged.

SAST full form and meaning

SAST stands for Static Application Security Testing. It is a way of finding security vulnerabilities by analysing an application's source code, bytecode or binaries without running the program. "Static" means the analysis happens on the code at rest; "application security testing" means the goal is to find flaws an attacker could exploit. You will also see it called static code analysis for security, or white-box testing, because the tester can see the code. In DevSecOps terms it is the "shift-left" test: it runs early, on the developer's own code, before anything is deployed.

A quick example

Here is the kind of bug a SAST tool flags. This Python function builds a SQL query by pasting user input into a string:

def get_user(request):
    name = request.args["name"]
    return db.execute("SELECT * FROM users WHERE name = '" + name + "'")

A SAST tool sees that name comes from the request (an untrusted source) and reaches db.execute (a dangerous sink) with no sanitisation in between, and reports SQL injection (CWE-89). The fix is a parameterised query:

def get_user(request):
    name = request.args["name"]
    return db.execute("SELECT * FROM users WHERE name = %s", (name,))

How SAST works: three technical approaches

1. Pattern matching (regex-based)

The simplest approach is pattern matching: define a regular expression for a dangerous construct (eval(, System.exec(, password =) and flag every match. This is fast, easy to write rules for, and works across any language without a parser. The downside is false positives: eval( appears in safe code too, and a regex can't distinguish whether the argument to eval is attacker-controlled or a hardcoded constant.

2. Abstract Syntax Tree (AST) analysis

More sophisticated tools parse source code into an AST — a structured tree representing the code's syntax — and analyze patterns within that structure. An AST rule can express "find all method calls to query() where the first argument is a concatenation involving a non-constant value," which is far more precise than a regex. AST analysis understands code shape rather than raw text.

3. Taint analysis / data flow

The most powerful approach is taint analysis: the tool tracks data from untrusted sources (HTTP request parameters, form inputs, user-uploaded content) through the code until it reaches a dangerous sink (database queries, shell commands, HTML output). A taint finding fires only when there is a confirmed path from source to sink with no sanitization in between.

Taint analysis is how serious SQL injection, XSS, and command injection detections work. It requires building a data flow graph across the codebase, which is more expensive than pattern matching but dramatically reduces false positives. DepWarden's SAST engine combines all three: pattern rules for broad coverage, tree-sitter AST rules for structural precision on supported languages, and an intra-file taint pass that only fires injection-class rules when user-controlled data actually reaches the sink.

The vulnerability categories SAST covers

SAST tools primarily find code-level vulnerabilities — flaws in the application's own logic:

SAST, DAST, and SCA: the three-scanner model

These scanner types are complementary, not interchangeable:

ScannerWhat it findsWhen it runs
SASTBugs in your own source codeCI, pre-commit, every PR
DASTBugs exposed at runtime in a deployed appStaging environment, release gate
SCAVulnerabilities in open-source dependenciesCI, pre-commit, every PR

SAST catches bugs in the code you write. SCA catches bugs in the code you import. DAST catches bugs that only manifest when the application is running — misconfigured servers, race conditions, issues SAST can't reach statically. A mature security pipeline uses all three; SAST and SCA run on every commit.

Integrating SAST into CI/CD

The most valuable property of SAST is that it runs without a deployed application. Upload a source zip in the browser, or connect a GitHub, GitLab, Bitbucket or Azure DevOps repo branch and schedule recurring scans so new findings surface without you doing anything.

The key configuration choice is --fail-on. Setting it to critical only blocks the most severe findings; high blocks high and critical. Starting with critical and moving to high once you've baselined your codebase is the practical approach. Failing on medium is usually too noisy until you've tuned suppressions for your codebase.

Managing false positives

The main challenge with SAST is false positives, which create alert fatigue that causes developers to ignore the scanner entirely. Good tooling reduces false positives through:

Taint gating: Only fire injection-class rules when the data flow is confirmed. A rule that matches eval( pattern-only fires on every eval call; a taint-gated rule fires only when the argument comes from user input.

Confidence levels: Separate HIGH-confidence (taint-confirmed, specific pattern, no plausible safe use) from MEDIUM and LOW (pattern-only, more context needed). Treat them differently in CI — block on HIGH, review MEDIUM.

Suppression markers: When a specific finding is safe by design, document it in code:

// depwarden-ignore: eval-user-input — content is from a curated config, not user input
eval(configExpression);

Not-patterns: Rules can include patterns that cancel the match. A "hardcoded password" rule can exclude lines that reference process.env or os.environ, since those are reading from environment variables, not hardcoding.

What DepWarden's SAST covers

DepWarden's static analysis covers:

- Core injection, XSS, secrets, weak crypto (applies to all languages) - Framework-specific: Django, Spring Boot, Express, Rails, Laravel, ASP.NET Core - Advanced cryptography: ECB mode, DES, RC4, hardcoded IV, bcrypt cost, TLS version - Shell script security: eval injection, wget/curl pipe exec, world-writable files - Mobile: Android WebView, iOS keychain, SSL pinning bypass - API & web: JWT algorithm confusion, SSRF, open redirect, GraphQL introspection

Every finding includes CWE and OWASP Top 10 mapping, severity (CRITICAL/HIGH/MEDIUM/LOW), confidence level, remediation guidance, and a redacted code snippet that never exposes actual credentials.

Findings are separated from SCA dependency results and filterable by severity, confidence, category, language, and status. The engine runs in under 10 seconds for most projects.

SAST tools and languages

You can run SAST from the command line, in CI, or in the browser. To compare the options, see free SAST tools compared. DepWarden's scanner has dedicated guides for Python, Java, JavaScript and TypeScript, PHP, Go (Golang), C#, Ruby, Kotlin and Swift, plus a free secret scanner for hardcoded API keys and passwords. You can open the SAST scanner and try it on your own code without an account.

Frequently asked questions

What does SAST stand for?

SAST stands for Static Application Security Testing.

Is SAST the same as static code analysis?

Static code analysis is the broader technique of examining code without running it; linters, type checkers and quality tools all do it. SAST is static analysis aimed specifically at security vulnerabilities.

Does SAST run the code?

No. It reads source code or bytecode and reasons about it. That is why it can run before an application is deployed, and why it cannot see problems that only exist at runtime, such as a misconfigured server.

What is the difference between SAST and DAST?

SAST examines the code from the inside without running it. DAST tests a running application from the outside, the way an attacker would. They find different problems, and mature pipelines use both.

What is the difference between SAST and SCA?

SAST finds vulnerabilities in the code you write. SCA (software composition analysis) finds known vulnerabilities in the open-source packages you import. See SAST vs SCA.

Is there a free SAST tool?

Yes, several exist; see free SAST tools compared. DepWarden's SAST scanner is free in the browser with no account.

Where does SAST fit in the software development lifecycle?

As early as possible: in the editor, on every commit, and as a required check on pull requests. That is why it is called a shift-left practice.

See also: SAST vs SCA — why you need both, catching typosquats in CI, CVSS, EPSS and KEV guide.