Static Analysis Tools (SAST): what they are & how to choose
Static analysis tools read your code without running it to find bugs and security flaws early. When the focus is security, the category is called SAST — Static Application Security Testing. This page explains what SAST and static code analysis are, how they differ from DAST, SCA, secret scanning and IaC scanning, the categories of tooling, and how to choose one. Tools are described factually and neutrally — no benchmarks, no rankings.
Static analysis in brief
- Static analysis (static code analysis) inspects source code, bytecode or binaries without running the program. When its goal is finding security vulnerabilities it is called SAST — Static Application Security Testing.
- SAST reasons about code paths, data flow and taint to surface issues like injection, hard-coded secrets, unsafe deserialization and weak crypto before the code ships. It runs early and often, typically in the editor and in CI.
- It is one layer among several: DAST tests a running app from the outside, SCA checks third-party dependencies, secret scanning hunts for leaked credentials, and IaC scanning checks infrastructure definitions. They overlap little and complement each other.
- Choosing a tool comes down to language and framework coverage, how cleanly it fits your CI and pull-request workflow, its false-positive rate, and how well it supports triage — grouping, suppression and tracking findings over time.
- Both strong open-source tools (for example Semgrep, CodeQL, Bandit and security-focused ESLint plugins) and commercial platforms exist; the right fit depends on your languages, scale and how much triage and policy tooling you need.
What is static analysis (and SAST)?
Static analysis — also called static code analysis — inspects a program's source code, bytecode or compiled binaries without executing it. The tool parses the code into a model such as an abstract syntax tree and, in deeper tools, a control- and data-flow graph, then checks that model against a set of rules. It covers a spectrum, from simple linters that enforce style up to analyzers that reason about whole-program data flow.
SAST (Static Application Security Testing) is static analysis aimed specifically at security vulnerabilities — things like injection, unsafe deserialization, weak cryptography, hard-coded secrets and dangerous API use. Because SAST needs no running application and no test traffic, it can run very early: in the developer's editor and on every pull request, pointing to the exact file and line where a problem lives.
How SAST differs from DAST, SCA, secret scanning and IaC scanning
These are often confused, but they look at different things and overlap little. A mature program usually runs several of them together:
SAST (static analysis)
Analyzes your own source code, bytecode or binaries without running them.
Finds Injection, unsafe deserialization, weak crypto, hard-coded secrets, dangerous API use — with file and line locations.
DAST (dynamic testing)
Exercises a running application from the outside, with no view of the source.
Finds Issues that are actually reachable and exploitable at runtime — but later in the lifecycle and with less precise locations.
SCA (composition analysis)
Inventories third-party and open-source dependencies and their versions.
Finds Known vulnerabilities (CVEs) and license risk in the libraries your code pulls in, not in the code you wrote.
Secret scanning
Searches code, git history and configuration for credentials.
Finds Leaked API keys, tokens, passwords and private keys committed by mistake.
IaC scanning
Checks infrastructure-as-code definitions, not application code.
Finds Insecure settings in Terraform, Kubernetes manifests, CloudFormation and similar — open buckets, permissive policies, missing encryption.
The short version: SAST reads the code you wrote, DAST probes the running app, SCA checks the libraries you depend on, secret scanning hunts for leaked credentials, and IaC scanning checks your infrastructure definitions. None replaces the others.
Categories of static analysis tooling
"Static analysis tool" spans a range of depth and cost. The main categories:
Linters and security linter plugins
Fast, rule-based checkers that run in the editor and on commit. General linters enforce style and catch obvious bugs; security-focused plugins add rules for risky patterns. They are cheap to run and give near-instant feedback, but they reason mostly about single files rather than whole-program data flow.
Pattern- and query-based analyzers
Tools that let you write rules describing dangerous code patterns, and in some cases query the codebase as if it were a database. They strike a balance between speed and depth and are popular for custom organization-specific rules, because teams can encode their own anti-patterns.
Data-flow / taint-tracking engines
Deeper analyzers that trace how untrusted input (a source) can reach a sensitive operation (a sink) across functions and files. Taint tracking is what separates “this looks risky” from “untrusted data can actually reach here,” which is the single biggest lever on false-positive rates.
Platform / ASPM suites
Commercial platforms that bundle SAST with SCA, secret scanning, IaC scanning and a central dashboard for managing findings across many repositories. They add policy, compliance reporting, triage workflow and support on top of one or more scanning engines.
How to choose a SAST tool
There is no single best tool — fit depends on your stack and how your team works. Weigh these criteria against your own code rather than a vendor's feature list:
Language and framework coverage
The most basic filter: a tool is only useful if it understands the languages and frameworks you actually ship. Depth varies by language even within one tool, and framework awareness (knowing that a given call is a web route or an ORM query) drives accuracy. Confirm coverage for your real stack, not just the headline list.
CI and pull-request integration
A scanner only changes outcomes if it runs where developers work. Look for clean integration with your CI, inline pull-request annotations, editor plugins, and the ability to fail or warn a build on policy. A tool that lives in a separate console nobody opens rarely gets acted on.
False-positive rate and tuning
Noise is the quiet killer of SAST adoption. Evaluate the default signal-to-noise on your own code, how precise the engine is (data-flow and taint tracking help), and how easily you can tune rules, set a baseline for existing code, and suppress reviewed findings so they do not reappear.
Triage, ownership and tracking
Finding issues is only half the job. Good tooling groups and deduplicates findings, routes them to the right owners, tracks status over time, and distinguishes new regressions from the pre-existing backlog. Without this, every scan re-litigates the same alerts and nothing closes.
Fit, cost and maintenance
Open-source tools shift cost from licenses to the effort of maintaining and tuning rules yourself; commercial platforms trade license spend for managed rules, dashboards and support. Weigh your team’s capacity, the number of repositories and languages, and any compliance reporting you need.
Open-source vs commercial
Capable tools exist in both camps. Open-source scanners shift cost from licenses to the effort of selecting, tuning and maintaining rules yourself, and they integrate well with modern CI. Well-known examples, described neutrally:
- Semgrep — A pattern-based analyzer with a widely used open-source engine and rule registry; rules are readable and quick to write for custom patterns.
- CodeQL — A query-based engine that treats code as a database you can query for vulnerability patterns across many languages; free for open-source projects.
- Bandit — A focused SAST tool for Python that flags common security issues in Python source.
- ESLint security plugins — Security-oriented rule sets for the JavaScript/TypeScript ESLint ecosystem, run as part of ordinary linting.
Commercial platforms — including broader application-security posture suites — typically add wider language coverage, managed rule sets, finding-management and triage dashboards, policy and compliance reporting, and vendor support. Many teams combine the two: an open-source engine in CI alongside a platform for central reporting. There is no universally "best" option, and this page deliberately avoids benchmarks or rankings — evaluate shortlisted tools against your own repositories.
Related PlayCISO tools: static analysis is one layer of code and supply-chain security. For adjacent checks, try the free secret scanner (leaked credentials), the npm scanner (dependency risk), and the IAM policy analyzer (over-permissive cloud policies). The full set lives on the tools page.
Frequently asked questions
What is a static analysis tool?
A static analysis tool inspects a program’s source code, bytecode or compiled binaries without executing it. It parses the code into a model (such as an abstract syntax tree or a control- and data-flow graph) and checks that model against a set of rules. Static analysis covers a spectrum: linters and style checkers at one end, and deeper correctness and security analyzers at the other. When the rules target security vulnerabilities specifically, the tool is called a SAST tool (Static Application Security Testing). Because it does not need a running application or test traffic, it can run very early — in the developer’s editor and on every pull request.
What is SAST and how does it differ from DAST?
SAST (Static Application Security Testing) analyzes code from the inside without running it, so it can point to the exact file and line where a problem lives and run before anything is deployed. DAST (Dynamic Application Security Testing) does the opposite: it exercises a running application from the outside, sending requests and observing responses, with no view of the source. SAST tends to find a broad set of coding flaws early but can report issues that are not reachable at runtime; DAST finds problems that are actually exploitable against the running system but later in the lifecycle and with less precise location data. They are complementary rather than substitutes — many teams run both.
Is static code analysis the same as SCA or secret scanning?
No. Static code analysis (and SAST) examines the code your team writes. Software Composition Analysis (SCA) looks instead at the third-party and open-source dependencies your code pulls in, matching them against known-vulnerability databases and license data. Secret scanning searches code, history and configuration for leaked credentials such as API keys and tokens. Infrastructure-as-Code (IaC) scanning checks configuration files like Terraform, Kubernetes manifests or CloudFormation for insecure settings. These are distinct categories that address different risks, and a complete program usually layers several of them.
How do I reduce false positives from a SAST tool?
False positives are the main reason SAST programs lose developer trust, so managing them is part of running the tool well. Practical steps: start with a focused, high-confidence rule set rather than enabling everything at once; tune or disable rules that do not apply to your stack; use the tool’s inline suppression or baseline features to acknowledge reviewed findings so they do not reappear; and prefer tools with good data-flow or taint tracking, which cut noise by confirming that untrusted input can actually reach a sensitive sink. Triage workflow matters as much as the engine — route findings to the right owners, group duplicates, and track them over time instead of re-reviewing the same alert on every run.
Are open-source static analysis tools good enough?
For many teams, yes. Open-source tools such as Semgrep, CodeQL, Bandit and security-oriented ESLint plugins are capable and widely used, and they integrate well with modern CI. Commercial platforms typically add breadth of language coverage, managed rule sets, finding-management and triage dashboards, policy and compliance reporting, and support. The right choice depends on your languages and frameworks, how much scale and governance tooling you need, and whether you have the capacity to tune and maintain rules yourself. It is common to combine them — for example an open-source scanner in CI alongside a commercial platform for central reporting.