Lesson 19 of 35SASTSAST

What is SAST?Static Application Security Testing explained

Reads an application's source code without running it, looking for coding mistakes — like SQL injection or hardcoded secrets — that could become exploitable vulnerabilities, and flags them before the code ever ships.

By Cyber Tool Stack Editorial TeamReviewed August 4, 2026

Verified August 4, 2026Sources: owasp.org, en.wikipedia.org, paloaltonetworks.com

The lesson

Catching security bugs by reading code, not running it

Some of the worst vulnerabilities are ordinary coding mistakes that sit in plain sight until an attacker finds them. This lesson shows how a scanner reads source code like a security-trained editor and flags trouble before the app ever runs.

If it helps, think of it as… the blueprint review

A structural engineer can look at a building's blueprints and spot a beam that won't bear its load — before any concrete is poured. Fixing the drawing costs an eraser; fixing the finished building costs a fortune. Reviewing code before it runs works the same way: the flaw is cheapest to fix while it's still just lines on a page.

Developer pushes code

A change goes up for review

Scanner models the code

Builds a map of how data flows through it

Traces risky paths

User input reaching dangerous operations

Merge proceeds

No new high-severity findings

Finding in the PR

Flagged line, explanation, suggested fix

Code is modeled and traced for dangerous paths, and findings land in the pull request where they're cheapest to fix.

What it does

Static application security testing (SAST) reads an application's source code without ever running it, looking for the coding mistakes that become vulnerabilities. "Static" is the key word: where other testing pokes at a live application, a static scanner works from the text of the code itself, the way an editor reviews a manuscript before it's printed.

That vantage point has two big advantages. The scanner sees every line — including code paths a running test might never trigger — and it can point at the exact file and line where the problem lives, right at the moment the developer wrote it. This is the heart of what security teams call shifting left: moving security checks earlier in development, where fixes are measured in minutes instead of incident reports.

The attack it stops

Consider a login page that builds a database query by gluing the username the visitor typed directly into the query text. An attacker types a fragment of database syntax instead of a name, the database obediently executes it, and the attacker walks out with the user table. This is SQL injection — decades old, still on the OWASP Top 10 list of critical web application risks, and still breaching companies.

A static scanner catches it before it ships. It traces the "taint" path: untrusted input from the request travels through the code and reaches a database call without being sanitized. The same tracing catches its cousins — script injection into web pages, file paths built from user input — plus a different classic: a real password or cloud API key hardcoded in the source, waiting for whoever reads the repository next.

How it works, step by step

The scanner parses the source code into a structured model — not just text, but an understanding of functions, variables, and how data moves between them.
It applies rules describing known-dangerous patterns, drawn from catalogs of weakness types like CWE (Common Weakness Enumeration) and tuned per language and framework.
Data-flow analysis follows untrusted input from where it enters — a form field, a URL, a file — to where it's used, flagging paths that reach a sensitive operation without validation.
Findings are filtered and ranked, because raw static analysis is noisy and a wall of warnings gets ignored.
Results surface where developers already work: in the editor as they type, and in the pull request, where a serious new finding can block the merge until it's fixed.

What it doesn't do

A static scanner can't see problems that only exist at runtime — a misconfigured server, a broken login flow, two services combining insecurely. It doesn't check the open-source libraries your code imports, only the code you wrote. And it produces false positives: findings that look dangerous on paper but are unreachable in practice.

The common beginner misconception is that a clean scan means a secure application. A scanner verifies the absence of known bad patterns in your code — not the presence of good design, correct configuration, or safe dependencies.

How it fits the stack

Static analysis is one half of application testing; its counterpart DAST attacks the running app from outside and finds what code reading can't. The libraries your code pulls in are checked by software composition analysis. And while flaws are being fixed, a WAF in front of the app can blunt attempts to exploit them in production.

Terms you just met

Each links to its plain-language definition in the glossary.

The field guide

Evaluating this category

A second pass for buyers: market context, distinctions that matter, and what to weigh when tools in this category start looking alike.

Most vulnerabilities are typos in disguise — a missing input check, a string concatenated straight into a database query, a secret pasted into a config file and forgotten. None of that requires a live server to find; it's visible in the source the moment it's written. Static application security testing reads code without running it, tracing through the logic the way a very patient reviewer would, and flags the patterns that tend to become exploitable bugs.

Because it works on source alone, it can run the instant code is written — in an editor, in a pull request, in a nightly build — long before anything reaches a server an attacker could reach.

The problem it solves

Modern applications ship changes daily, and a manual security code review can't keep pace with that volume. Left unchecked, coding mistakes that are individually small — an unescaped input, a debug flag left on, a credential embedded for convenience — compound across a large codebase into a real breach.

Finding these issues before code merges is far cheaper than finding them after: a flagged line in a pull request costs a developer a few minutes, while the same bug live in production can mean an incident, a patch under pressure, and a public disclosure.

How it works

A scanner parses source code into a structure it can reason about — often an abstract syntax tree — and traces how data moves through the program. Two ideas do most of the work: pattern matching for known-dangerous constructs, and taint tracking, which follows untrusted input from where it enters the program to where it's used, flagging any path that reaches a sensitive operation unvalidated.

Results are ranked so developers see the findings that matter first, rather than wading through hundreds of low-severity notes. Findings surface directly where code is written — inline in the editor or as a pull-request comment — and a merge can be blocked once a new high-severity issue appears. Because static analysis has no runtime context, every tool trades some false positives for coverage; the best ones let a team tune or suppress rules that don't fit their codebase, and add custom rules for patterns no generic scanner would catch.

SAST vs DAST

Static testing reads code that never runs; dynamic testing attacks an application that's already running and watches what comes back. SAST can point at the exact line of a bug before deployment, but can't see how a request behaves in production — configuration issues, cross-service authentication, or otherwise-fine components combining into a real hole. DAST catches exactly what SAST can't, at the cost of finding only what it happens to test, and only after the code already runs. Most mature programs run both rather than treating either as a substitute.

Scanning doesn't stop at your code

The application a team ships is more than its source: it's the source plus its dependencies, the container image it runs in, and the infrastructure-as-code that provisions everything around it. That IaC — Terraform, CloudFormation, Kubernetes manifests, Dockerfiles — is just config-as-code, and the same static analysis that reads application logic reads those templates too, flagging an open security group or a privileged container before it is ever applied. Modern SAST platforms (GitLab, Checkmarx, SonarQube via its sonar-iac engine) now scan it in the same pipeline as the code.

Some vendors push further, wiring in cloud connectors or agentless scanners that correlate a static finding with the deployed environment it lands in — blurring the line with the cloud-native application protection platforms (CNAPP) that grew up on the infrastructure side. If you already run one of those, check the overlap before buying both.

Choosing one

Start with language and framework coverage: a scanner that doesn't understand your stack is worthless no matter how good its engine is elsewhere. From there, weigh signal quality over raw finding counts — a tool that surfaces twenty well-prioritized issues a team will actually fix beats one that produces two thousand nobody has time to triage.

Consider where developers already work. A scanner that plugs into the existing pull-request workflow and editor gets used; one that requires a separate portal gets ignored, however accurate its findings are. Finally, check how much rule customization is realistically achievable — custom rules are only valuable if someone has the time and skill to maintain them.

Capability taxonomy

What buyers typically evaluate when comparing tools in this category.

Source code vulnerability scanning: Analyzes source code for security flaws without executing the application.
IDE & CI/CD integration: Surfaces findings directly in the developer's editor or pull request.
Language & framework coverage: Breadth of programming languages and frameworks the scanner understands.
False-positive triage & prioritization: Ranks and filters findings so developers focus on the issues that matter.
Secrets detection: Flags hardcoded credentials, API keys, and tokens committed to source code.
Custom rule authoring: Lets teams write organization-specific detection rules beyond the built-in set.
PR / commit gating: Blocks merges when new high-severity findings are introduced.
IaC & container config scanning: Scans infrastructure-as-code templates and container configurations for misconfigurations alongside application code.