Static application security testing (SAST) is a method of finding security weaknesses by analyzing an application’s source code, or its compiled form, without running it. A SAST tool reads the code, traces how data moves through it, and flags patterns that commonly lead to vulnerabilities, such as user input reaching a database query unchecked or passwords written directly into the code. Because it works on code, it can run very early in development and point developers to the exact file and line involved.
At a glance
- SAST is one method within application security testing: the one that examines code rather than the running application.
- It runs without executing the application, so it can be used from the first lines of code onward.
- Findings point to specific files and lines, which makes them easier for developers to fix.
- Tools have to support each programming language and framework you use.
- False positives are common, so tuning and prioritization decide whether developers trust the results.
What problem it solves
The later a security flaw is found, the more it tends to cost to fix: code has to be revisited, retested and re-released, and if the flaw reaches production it may be exploited first. Manual code review catches some issues but doesn’t scale to teams committing changes many times a day.
SAST gives developers automated, early feedback. It can check every change for well-known classes of vulnerability, such as injection, unsafe handling of files and secrets left in code, before the code is merged. That makes security part of normal development and gives software companies evidence for customers and auditors that code is reviewed for security.
How it works
Parsing the code. The tool reads source code (or compiled bytecode or binaries, depending on the product) and builds a model of the program: its functions, data flows and how components call each other.
Applying rules. It checks that model against rules describing insecure patterns. A common technique is taint analysis: following untrusted input, such as a form field, from where it enters the program to where it is used, and flagging paths where it isn’t validated.
Reporting. Each finding includes the location, the type of weakness and usually guidance on fixing it, often mapped to standard weakness categories.
Integration. SAST commonly runs in the developer’s code editor, on each pull request or code change, and in the build pipeline, as part of DevSecOps practices. Policies can block a merge or release if serious issues remain.
Triage. Developers or security staff review findings, mark false positives and prioritize real issues, ideally in the same issue tracker the team already uses.
When it matters for buyers
- When you develop software in-house or through partners. Including internal tools, integrations and customer portals.
- When customers send security questionnaires. Code scanning is a common expectation for software and SaaS providers.
- When moving to frequent releases. Automated checks keep pace with DevOps delivery where manual review can’t.
- When developers are drowning in findings. Tool choice and tuning affect whether results are acted on, and noisy tools add to false positive security alerts.
- When consolidating tools. SAST is often sold in a platform with dynamic testing and component analysis. Our application security testing overview covers how these bundles are compared.
Questions to ask vendors
- Which languages, frameworks and build systems do you support, including the ones we use?
- How do you integrate with our code repository, editors, pipeline and issue tracker?
- What is your false-positive rate on code like ours, and can we test on our own repositories?
- How long does a scan take, and can incremental scans run on each code change?
- Does your platform include software composition analysis and secret scanning, or are they extra?
- How is pricing calculated: per developer, per repository or per line of code?
How it differs from DAST
Dynamic application security testing (DAST) tests the running application from the outside, the way an attacker would, without looking at the code. SAST looks at the code without running it. SAST works earlier and pinpoints the exact line, but can’t see problems that depend on how the application is deployed and configured. DAST sees those runtime issues but can’t say where in the code they come from. Each finds things the other misses, so many teams use both.