What is SAST?

What SAST actually does

Static Application Security Testing scans your source code for security vulnerabilities without running the application. It reads your code the way a security reviewer would, except it does it in minutes instead of days.

The “static” part is what matters. SAST tools analyze code at rest. They do not need a running application, a staging environment, or a deployed server. Point the tool at your repository and it tells you where the problems are, down to the file and line number.

A developer pushes code, the CI pipeline runs a SAST scan, and within minutes they know if they introduced a SQL injection or a cross-site scripting vulnerability. Fix it before the pull request merges. That is the whole idea.

SAST has been around since the early 2000s. The first generation of tools was slow, noisy, and expensive. Modern SAST tools are faster, more accurate, and many are free. But the core concept has not changed: read the code, find the bugs, tell the developer where to look.

IBM puts the average cost of a data breach at $4.88 million in 2024. Catching vulnerabilities before they reach production is not optional for most organizations.

How static analysis works

SAST tools use several techniques to find vulnerabilities. Not every tool uses all of them, and the depth of analysis is a major differentiator between free and commercial products.

Parsing and AST generation

The tool parses your source code into an abstract syntax tree (AST), a structured representation that can be traversed regardless of formatting or coding style. Most tools build language-specific ASTs, though some (like Semgrep) use a cross-language intermediate representation.

Pattern matching

The simplest technique. The tool looks for known-bad patterns in the AST: calls to deprecated functions, use of insecure cryptographic algorithms, hardcoded credentials. Fast and low on false positives, but it only catches low-hanging fruit.

Bandit and gosec rely heavily on pattern matching. They are fast and easy to configure, but they miss anything that requires understanding how data flows through your application.

Data flow analysis

This is where SAST tools earn their keep. Data flow analysis (also called taint analysis) tracks the path of user-controlled input from its source (where it enters the application) to its sink (where it does something dangerous).

A concrete example: in a Java web application, data flow analysis traces a value from HttpServletRequest.getParameter("id") through several method calls, string concatenations, and variable assignments until it reaches Statement.executeQuery(sql). If no sanitization or parameterized query is used along the way, the tool flags it as a SQL injection.

The depth of this analysis varies enormously. Some tools only trace data flow within a single function (intra-procedural). Enterprise tools like Checkmarx, Coverity, and Fortify trace across function calls, files, and separate modules (inter-procedural). Deeper analysis catches more real bugs but takes longer to run.

Control flow analysis

Control flow analysis checks the order of operations: race conditions, resource leaks (opening a file but never closing it), improper error handling. This matters most for C/C++ code where manual resource management is common.

Configuration analysis

Some SAST tools also check configuration files: web.xml, application.properties, YAML configs. Misconfigured security headers, disabled CSRF protection, overly permissive CORS settings.

What SAST catches

SAST is good at finding vulnerabilities that have clear code-level patterns:

• Injection flaws — SQL injection, command injection, LDAP injection, XPath injection. Anywhere user input reaches a dangerous function without sanitization.
• Cross-site scripting (XSS) — User input rendered in HTML responses without encoding.
• Hardcoded secrets — API keys, passwords, and tokens committed to source code.
• Insecure cryptography — Use of deprecated algorithms (MD5, SHA-1 for password hashing), weak key lengths, or ECB mode.
• Buffer overflows — Particularly in C and C++, where array bounds are not checked automatically.
• Path traversal — User input used to construct file paths without validation.
• Insecure deserialization — Deserializing untrusted data without type checks.

These all follow recognizable patterns in source code. A data flow from user input to a SQL query without parameterization looks the same regardless of who wrote it.

Where SAST falls short

SAST cannot see everything. Knowing the gaps helps you decide where to add other testing methods.

Runtime and configuration issues. SAST does not execute the application, so it misses server misconfigurations, missing security headers, and authentication bypass that depends on server configuration. That is DAST territory.

Business logic flaws. If your pricing logic lets users buy items for negative amounts, SAST will not catch it. The code is syntactically correct; the logic is wrong.

False positives. SAST flags code that looks dangerous even when it is not. A function that accepts user input and passes it to a database query might have sanitization in a middleware layer that the tool does not model. Untuned SAST can produce false positive rates of 30-60%, which is enough to make developers ignore it entirely. For practical techniques to bring those rates down, see our guide to reducing SAST false positives.

Framework-specific behavior. If a SAST tool does not understand your framework, it reports false vulnerabilities. A tool that does not understand Django’s ORM will flag database queries as SQL injection risks even though the ORM parameterizes them automatically.

Third-party dependencies. SAST scans your code, not the code inside your npm packages or Maven dependencies. That is SCA territory.

SAST in your CI/CD pipeline

Running SAST manually works for a one-time audit. The real value comes from running it automatically on every code change.

Pre-commit and IDE

The fastest feedback loop. Snyk Code and SonarLint scan code in the IDE as developers type. Semgrep and Bandit can run as pre-commit hooks, catching issues before code is even pushed.

Pull request scanning

The most common setup. The CI pipeline runs SAST on every pull request and posts findings as PR comments. Developers see issues in context, right next to the code they changed. SonarQube, Checkmarx, and Snyk Code all do this well.

Quality gates

Block merges when critical vulnerabilities appear. Without enforcement, SAST findings become suggestions that get ignored. SonarQube quality gates and Checkmarx policies are the most common implementations.

Baseline management

When you first run SAST on an existing codebase, you will get hundreds or thousands of findings. Nobody fixes all of those on day one. Baseline the existing findings, require that all new code is clean, and fix legacy issues gradually. Most commercial tools support this out of the box.

Open-source vs commercial

The gap between free and paid SAST tools is real, but not as wide as vendors want you to believe.

Semgrep, SonarQube Community Edition, Bandit, and Brakeman handle pattern matching and basic data flow well. Semgrep in particular has a strong rule ecosystem and makes writing custom rules straightforward. For teams using a single primary language, these are often enough.

Checkmarx, Fortify, Veracode, and Snyk Code add deeper inter-procedural data flow analysis, broader language coverage, better IDE integration, compliance dashboards, and dedicated support. The analysis depth matters most for large codebases with complex call chains across multiple files and modules.

The honest take: if you are a small team writing a Python web application, Bandit plus Semgrep will catch most of what a $200K enterprise tool would find. If you are an enterprise with 50 applications across Java, .NET, Go, and Python, commercial tools earn their price through breadth and management features.

Top SAST tools

These are the tools I would look at first. For full reviews, see the SAST tools page.

Free and open-source

• Semgrep — 20+ languages, custom rules are easy to write, large community rule registry. The best general-purpose free option.
• SonarQube Community Edition — 35+ languages, combines code quality with security. Quality gates are useful for CI enforcement.
• Bandit — Python-specific. If Python is your main language, start here.
• Brakeman — Ruby on Rails-specific. Deep Rails awareness makes it accurate for that ecosystem.
• GitHub CodeQL — Free for public repositories. Semantic code queries are powerful but have a learning curve.

Commercial

• Checkmarx One — 35+ languages, deep data flow analysis, SAST + SCA + DAST + IAST in one platform. Gartner Leader seven times.
• Snyk Code — Developer-first approach, fast IDE feedback, AI-powered. Gartner Leader in 2025.
• Veracode SAST — Binary analysis (no source code upload needed), broad language support. Gartner Leader eleven times.
• Fortify — 33+ languages including legacy (COBOL, ABAP). The widest language support in the market.
• Coverity — Particularly strong for C/C++ and embedded systems. Now part of Black Duck.

Getting started

If you have never run SAST before, here is a practical path.

Pick a tool that supports your primary language. Do not overthink this. Semgrep for multi-language, Bandit for Python, Brakeman for Rails. Install it and run it locally.

Triage the initial results. The first scan will produce noise. Go through the findings, identify real issues, suppress the false positives. This is an afternoon’s work, not a month-long project.

Add it to CI. Run the tool on every pull request. Start in warning mode (do not block merges yet). Let the team get used to seeing findings.

Enable quality gates. Once the team is comfortable, block merges on critical and high-severity findings. Keep medium as warnings.

Write custom rules. Every codebase has patterns that generic rules miss. If you use an internal framework or have specific security requirements, write rules for those. Semgrep and CodeQL make this straightforward.

Consider adding DAST. SAST covers your code. DAST covers your running application. Together they give you much better coverage than either alone. See our SAST vs DAST vs IAST comparison for guidance.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.