What is SAST? How Static Application Security Testing Works

SAST is a way of finding security vulnerabilities by analyzing an application’s source code, bytecode, or binaries without running it. It’s often called “white-box” testing because the tool sees the program’s internals. It reads the code the way a very patient security reviewer would, looking for patterns and data paths that lead to flaws like SQL injection, cross-site scripting (XSS), or hardcoded secrets.

Where SAST fits

SAST is the most “shift-left” of these. It can flag a bug in your IDE before the code is committed, which is when fixing it is cheapest. That’s why it sits at the center of most DevSecOps programs.

How SAST works, step by step

1. Parsing the code
The tool reads your source files and breaks them into tokens (keywords, variables, operators), much as a compiler does. Some tools need the code to compile or build first so they can resolve types and imports.

2. Building an Abstract Syntax Tree (AST)
The tokens become a tree that represents the program’s structure: functions, statements, expressions, and how they nest. For example, query = "SELECT * FROM users WHERE id=" + userId becomes a tree node for an assignment, with a child node for string concatenation.

3. Building graphs of program behavior

• Control Flow Graph (CFG): every path execution can take, including branches, loops, and early returns.
• Call graph: which functions call which others, including across files.
• Data Flow Graph: how values move between variables, functions, and modules.

4. Running the analysis techniques

• Pattern / rule matching: looks for known-dangerous constructs, such as eval(), MD5 used for passwords, Runtime.exec() with string input, or hardcoded API keys. This is fast but shallow.
• Taint analysis (the core of modern SAST): tracks untrusted data from where it enters to where it’s used dangerously:
  • Sources are where untrusted input enters, such as HTTP parameters, headers, files, or environment variables.
  • Sinks are dangerous operations, such as SQL execution, HTML output, shell commands, or file paths.
  • Sanitizers are functions that make data safe, such as parameterized queries, escaping, or validation.
  If tainted data can reach a sink without passing through a sanitizer, the tool reports a vulnerability.
• Semantic and type analysis: uses type information to understand what an object actually is, which reduces false matches.
• Configuration analysis: checks settings files for problems such as debug mode enabled, weak TLS, or permissive CORS.

5. Reporting findings
Each issue typically includes:

• the vulnerability type, often mapped to a CWE ID or OWASP Top 10 category
• severity and confidence ratings
• the file and line number
• the full trace from source to sink
• guidance on how to fix it

A worked example

from flask import request

@app.route("/user")
def get_user():
    user_id = request.args.get("id")                         # SOURCE: untrusted input
    query = "SELECT * FROM users WHERE id = " + user_id      # tainted data propagates
    cursor.execute(query)                                    # SINK: SQL execution

The SAST tool traces request.args.get → user_id → query → cursor.execute and finds no sanitizer along the way. It reports SQL Injection (CWE-89). The fix is to pass the input as a parameter instead of concatenating it:

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

The tool recognizes parameterized queries as safe, so this finding disappears. This is exactly the class of flaw that CISA and the FBI have urged software makers to eliminate.

What SAST catches well

• Injection flaws: SQL, command, LDAP, XPath, and NoSQL injection
• Cross-site scripting (XSS)
• Path traversal
• Insecure deserialization
• Hardcoded credentials and secrets
• Weak cryptography, such as MD5/SHA1 for passwords, ECB mode, or insecure randomness
• Buffer overflows and memory-safety issues in C/C++
• XML External Entity (XXE) attacks and unsafe parser settings

Limitations

• False positives: the tool can’t always tell whether a custom validation function is truly safe, so some reported issues are harmless. Tuning rules is essential.
• False negatives: complex runtime behavior can hide real flaws. This includes reflection, dynamic dispatch, dependency injection frameworks, and data that passes through databases or message queues.
• No runtime context: SAST can’t see deployment configuration, server settings, or authentication flows as they actually behave. That gap is covered by DAST and, in production, RASP.
• Weak on business-logic bugs: a flaw like “a user can view another user’s invoice by changing the ID” usually needs human review. See these secure code review services.
• Language and framework coverage varies between tools.
• Large codebases can take a long time to scan in depth.

Common SAST tools

• Open source / free: Semgrep, CodeQL (free for open-source projects on GitHub), SonarQube Community, Bandit (Python), Brakeman (Ruby on Rails), gosec (Go), SpotBugs with FindSecBugs (Java), ESLint security plugins (JavaScript)
• Commercial: Checkmarx, OpenText Fortify, Veracode, Snyk Code, SonarQube’s paid editions, GitHub Advanced Security

For detailed comparisons, see GBHackers’ best SAST tools, the SAST features and pricing comparison, and the list of top application security testing companies.

Using SAST effectively in practice

1. Run it in the IDE with plugins, so developers get feedback while they type.
2. Run it on every pull request in CI and scan only the changed code, which keeps it fast.
3. Run full scans on a schedule, such as nightly or weekly, for deep analysis.
4. Gate builds carefully. Start by failing builds only on high-severity, high-confidence findings, then tighten over time.
5. Triage and tune. Mark false positives, suppress them with justification, and add custom rules for your own sanitizers and frameworks.
6. Baseline legacy code. Accept existing issues as technical debt and block new ones, so the tool doesn’t drown the team.
7. Combine it with other testing. SAST plus SCA plus DAST, with periodic manual review, gives far better coverage than any one alone. If you add DAST, avoid these common DAST scanning mistakes.

In short

SAST turns code into structured models (an AST, control flow, and data flow), then hunts for paths where untrusted input reaches a dangerous operation without being cleaned. It’s fast, early, and shows the exact line to fix, but it works best when tuned and paired with runtime testing.

Sources:

• Best SAST Tools 2026
• 12 Best SAST Tools Compared
• 12 Best DAST Tools Compared
• 9 Best IAST Tools Compared
• 10 Best RASP Tools Compared
• Best SCA Tools
• A1 Injection OWASP
• CISA & FBI Warn on SQL Injection
• What is XSS
• OWASP Top 10 Challenges
• Best DevSecOps Companies
• Secure Code Review Services
• Application Security Testing Companies
• Common DAST Scan Mistakes