SAST is a testing method that analyzes an application's source code, bytecode or binaries for security weaknesses without running it. The tool parses the code into an abstract syntax tree, then follows control and data flow to find where untrusted input reaches a sensitive operation. Because it reads the code itself, it can run from the first commit, before there is anything to deploy.
MITRE's entry for SQL injection says automated static analysis detects many instances of that weakness, and, in the same section, that "100% accuracy and coverage are not feasible." Both halves of that sentence are measurable. Fluid Attacks' scanner reaches a 100% true positive rate and a 0% false positive rate on the OWASP Benchmark v1.2 test suite, a result anyone can reproduce with one Docker command. Against a real application carrying 1,201 vulnerabilities, the same scanner reported 22.7% of them.
This page covers how static analysis reads code, which weaknesses it reaches and which it cannot, how SAST works at Fluid Attacks, how it differs from DAST and SCA, and what a clean scan does not prove.
What is SAST?
SAST (Static Application Security Testing), also called static analysis, is a white-box testing method: the tool has full access to the application's internal structure and logic, and it never executes the program. It examines source code, bytecode or compiled binaries and reports the file and line where each weakness sits.
SAST works in three stages. Parsing turns the code into an abstract syntax tree that represents functions, variables and control structures. Control flow analysis maps the paths execution can take. Data flow analysis tracks values as they move between those paths, which is how source code analysis connects an attacker-controlled input to the operation that trusts it.
Detection rules sit on top of that model. SAST tools encode patterns associated with known weakness classes, mapped to catalogs such as the OWASP Top 10 and CWE, so that a match produces a finding with a category, a severity and a location.
What SAST is not
Three techniques get grouped under "code scanning." They answer different questions, and the distinction matters when a report comes back clean.
Technique | What it reads | What it answers | What it cannot tell you |
Static application security testing | Your own source code, bytecode or binaries | Where insecure logic was written | Whether the flaw is exploitable in the deployed environment |
Software composition analysis | Third-party dependencies and their versions | Which known CVEs you inherited | Anything about the code your team wrote |
Secret scanning | Files and commit history | Which credentials were committed | Whether those credentials are still valid |
Three scans, three questions. A clean result in one says nothing about the other two.
Why SAST matters
Most of the risk in a custom application is in the code the team wrote, and SAST is the only technique that reads it before the application exists. That is the practical case for running it.
Most vulnerabilities are in code you wrote
In Fluid Attacks' benchmark of 36 third-party AppSec tools against an application with 1,201 vulnerabilities across 105 CWE categories, 80% of them were in the codebase, 13% in the backend and the rest in dependencies and the frontend. The State of Attacks 2026 report, covering 1,119,396 vulnerabilities reported between January 1 and December 31, 2025, shows the same shape: 978,820 of them were found in source code.
Volume is not severity
Automation finds most of what there is to find, and the smaller part of what matters. In that same report, automated techniques detected 88.4% of all vulnerabilities but only 73.4% of the high and critical ones, and the average risk exposure per automated finding was 15.5 CVSSF against 93.2 CVSSF per finding reported by a pentester.
Those two figures set the expectation for any SAST program: broad coverage of the codebase, and a severity profile that still needs security testing of other kinds on top.
Feedback arrives where the code is written
A SAST finding delivered in the IDE or on a pull request is read by the person who wrote the line, minutes after writing it. That timing is what makes the technique part of DevSecOps rather than an audit: fixes land while the context is still in the developer's head, and the same feedback loop improves overall application quality, not only its security.
Secure coding habits form the same way. Developers who see the same SAST rule fire three times stop writing the pattern.
SAST at Fluid Attacks
Fluid Attacks runs SAST as a scanner you can execute yourself, with results delivered in the platform, the IDE and the CI pipeline. What follows is the scope of our SAST, the evidence it produces and the limits we measure.
What we scan, and under what rules
The scanner covers 15 programming languages, six API protocols, eight infrastructure-as-code formats and 19 CI/CD tools. It also reads configuration files and flags credentials committed to the repository.
The rules are public. The Fluid Attacks Database holds 2,200 security rules across 45 targets, mapped to 173 standards, covering code, cloud, applications and binaries. Each rule traces back to a weakness entry with its description, impact, remediation guidance and the requirements it enforces.
Weakness 146, SQL injection, is a concrete example: one weakness, 35 detection rules written for Java, C#, PHP, Python, Dart, TypeScript, Rust, Swift, Go, JavaScript, Elixir, Ruby, Scala and Kotlin, with remediation examples in 11 languages. Weakness 009 covers credentials and other sensitive data left in source code.
One weakness, 35 detection rules across fourteen languages and frameworks.
What it looks like in practice
Where it runs | How it is triggered | What you get |
CLI in a Docker container | A single | A findings file in CSV |
Push to the default branch runs a full scan; feature branches and pull requests run a differential scan | A SARIF file, ready to upload to the GitHub Security tab | |
IDE extensions | Opening a file in the editor | The finding next to the line that caused it |
Vulnerability management platform | Every scan | Severity, risk exposure, location and remediation guidance |
CI Gate | Pipeline execution | A broken build when a finding violates the policy you set |
The same scanner, five entry points. Differential mode is what keeps pull request feedback quick.
A perfect benchmark is not a secure application
Fluid Attacks' scanner scores 100% on the OWASP Benchmark: a 100% true positive rate and a 0% false positive rate on version 1.2 of the suite, almost three times the average score of commercial detection tools and more than 1.5 times the highest-scoring free one. The documentation publishes the commands to reproduce it: clone the benchmark repository, run the scanner container, generate the scorecard with the OWASP plugin.
The scanner reaches a 100% true positive rate and a 0% false positive rate on the v1.2 suite.Fluid Attacks, 2026.
That number describes a synthetic Java test suite built to be measurable. It does not describe your application. In the benchmark against a real application, the same scanner reported 273 of 1,201 vulnerabilities — 22.7% recall at 99% precision — while a pentester working the same target reported 1,076 of them, 89.6% recall at 100% precision.
Evaluator and target | Recall | Precision | What the target is |
Fluid Attacks' scanner on OWASP Benchmark v1.2 | 100% | 100% | A synthetic Java test suite |
Fluid Attacks' scanner on a real application | 22.7% | 99% | 1,201 real vulnerabilities, 105 CWE categories |
A Fluid Attacks pentester on the same application | 89.6% | 100% | Same target, 49 days of work |
Average of the other 34 third-party tools | 1.7% | Varies | Same target |
Both results belong to the same scanner. The gap between them is the gap between a test suite and a codebase.
A perfect score is evidence about the engine, not a statement about your risk.
From a static finding to a CVE
A finding is a lead. Fluid Attacks' research on AI SAST results describes what happens between the two: of 1,006 findings generated and reviewed, 163 survived manual triage as true positives, 118 remained after consolidating duplicates, and 28 reached evaluation as CVE candidates. The stages in between: contextual analysis, source-to-sink review, reproduction, deduplication and disclosure.
That process ends in our Advisories, where entries detected by the AI SAST scanner carry a CVE identifier and the name of the researcher who disclosed them.
A static finding becomes a CVE only after manual triage, reproduction and disclosure.
The practice that decides the rest
Scanning on a schedule produces reports. Scanning on every change, with a gate, produces fixes. Systems using our CI Gate reached a 72.2% remediation rate against 58% for systems without it, with a median remediation time of 22 days against 30, over the 2025 period covered by the State of Attacks 2026 report.
Go deeper: AI SAST explains how machine learning widens the rule set, and our benchmark against coding agents measured AI SAST finding 72 of 100 real vulnerabilities across 52 codebases, against 9 for Codex and 8 for Claude Code given the same audit prompt.
How SAST reads code
SAST answers one question repeatedly: can a value an attacker controls reach an operation that trusts it? Everything in the analysis serves that question.
Parsing turns text into structure. The abstract syntax tree gives the tool functions, parameters, assignments and branches instead of characters.
Control flow analysis maps the order in which statements can execute, including the branches that only run under certain conditions.
Data flow analysis follows values across that map, from sources — request parameters, headers, file contents, database reads — to sinks, which are the operations where an untrusted value causes damage: a query, a shell command, an HTML response, a file path.
Rule matching decides what SAST reports. A rule for SQL injection fires when a tainted value reaches query construction without parameterization, and stays silent when a parameterized statement or a validated allow-list breaks the path.
Parsing, control flow, data flow, rule match: where a finding comes from, and where the analysis stops. Own work.
The chain also explains the blind spot. Everything SAST knows comes from code that is present and parsable. Configuration applied at deploy time, a sanitizer implemented in a service it cannot see, an authorization check enforced by a gateway: none of it is in the tree.
What SAST finds, and what it misses
SAST is strongest on weaknesses that are visible as a pattern in code: a value that travels from an untrusted source to a dangerous operation, a cryptographic call with a weak parameter, a credential written as a literal. Source code analysis reaches those because the evidence is in the file.
Weakness class | Why static analysis reaches it | What it still cannot confirm |
The tainted value and the query construction are both in the code | Whether the account's privileges limit the impact | |
Untrusted data reaches generated web content without validation | Whether a response header or CSP blocks execution | |
OS commands are built from externally manipulable input | Whether the runtime user can execute anything useful | |
Parser configuration and entity resolution are declared in code | Whether the deployed parser uses that configuration | |
Credentials appear as literals in files and history | Whether the credential is still valid |
Every row is an entry in the Fluid Attacks Database, with its rules and remediation guidance.
Two failure modes come with the method, and MITRE documents both for SQL injection. False positives appear when the tool cannot recognize that validation is being performed, which produces warnings with no security consequence. False negatives appear when it cannot analyze custom API functions or third-party libraries, "especially if the API/library code is not available for analysis." MITRE's conclusion about automated static analysis is the sentence worth keeping: "100% accuracy and coverage are not feasible."
False negatives are the quieter problem. A clean SAST report is read as good news, and nothing in it distinguishes "no weakness here" from "no rule for this." That is why we pair SAST with manual code reviews in the Advanced plan, and why severity-weighted coverage, rather than finding count, is the metric worth tracking.
SAST, DAST and SCA are not alternatives
They read different material at different moments, and the gaps of one are the coverage of another. The differences between the three come down to what each can observe.
Dynamic application security testing (DAST) attacks a running application from the outside, with no access to the code. Software Composition Analysis (SCA) inventories third-party components and matches them against known vulnerabilities. SAST reads the code your team wrote, which neither of the other two ever sees.
Feature | SAST | DAST |
Testing method | White-box, inside-out | Black-box, outside-in |
Analysis | Reads code without executing the application | Simulates attacks against a running application |
When it applies | From the first commit | Once there is a deployed, working application |
Typical findings | Injection, insecure data handling, weak cryptography, hardcoded secrets | Runtime configuration, authentication flaws, server-side issues |
Language dependent | Yes: the tool must support the language and framework | No: it interacts from outside |
Remediation detail | File and line number | The request that triggered it, not the line |
Main failure mode | False positives from missing runtime context | False negatives in code paths it never reaches |
SAST and DAST disagree about where to look, which is why running both covers more than running either twice.
Fluid Attacks combines them in one solution, together with Secure Code Review (SCR), Pentesting as a Service (PTaaS) and Reverse Engineering (RE), so that findings from every technique arrive in the same queue with the same severity scale.
How to run SAST effectively
Buying a scanner is the smallest decision in a SAST program. Five practices decide whether it produces fixes.
Select for your stack, not for a feature list: the SAST tool must support the languages and frameworks your teams actually use, and publish how its accuracy was measured. A vendor that cannot tell you how to reproduce its own numbers has given you a claim, not a measurement.
Configure before you scale: tune the rule set, scope the scan to the code you own, and record exclusions explicitly so that a suppressed finding is a documented decision rather than a silent gap.
Integrate where the work happens: IDE extensions for the minute the code is written, differential SAST scans on pull requests for the minute it is proposed, full scans on the default branch for everything else. Secure coding guidance lands best at that moment.
Prioritize by exposure, not by count: triage by severity and exploitability. In our 2025 data, 4.5% of reported vulnerabilities carried 79.9% of total risk exposure, which is why a finding count makes a poor queue.
Verify the fix and keep the gate: re-scan after remediation, and keep the pipeline gate enforcing the policy. The alternative is a report that documents the same vulnerability for a year.
Conclusions
SAST reads the code your team wrote, before there is anything to attack, and points at the exact line. That is a narrow capability and a valuable one: most of the vulnerabilities in a custom application live in that code, and no other technique sees it this early.
The limits of SAST are as specific as its strengths. It cannot confirm exploitability in a deployed environment, it cannot reason about code it cannot parse, and a clean report is not a secure application. Treat a SAST scan as the first layer of evidence, measure it by the risk it covers rather than by the findings it prints, and put the techniques that see runtime, dependencies and business logic on top of it.
Frequently asked questions
What is the difference between SAST and DAST?
SAST reads source code, bytecode or binaries without running the application and reports the exact line. It can run from the first commit. DAST attacks a running application from the outside with no access to the code, so it finds runtime and configuration issues that are invisible in source. They fail in opposite directions: SAST produces false positives from missing runtime context, dynamic testing misses code paths it never reaches.
Does SAST need the application to run?
No. That is the defining property of the technique: it analyzes code at rest, which is why it can be used before the application compiles or deploys, and why it cannot observe runtime behavior.
Can SAST find every vulnerability in my code?
No. MITRE states that for automated static analysis "100% accuracy and coverage are not feasible." In Fluid Attacks' benchmark against an application with 1,201 vulnerabilities, our scanner reported 22.7% of them at 99% precision, while a pentester working the same target reported 89.6% at 100% precision.
What is the difference between SAST and AI SAST?
Traditional SAST matches code against rules written by people, so it finds the patterns those rules anticipate. AI SAST adds machine learning to generate candidates and agents to trace context across files, which widens coverage of flows that span modules. In our benchmark across 52 codebases, it found 72 of 100 real vulnerabilities against 9 for a general-purpose coding agent given the same prompt.
Does a clean SAST report mean my application is secure?
No. It means no rule matched the code that was scanned. Unparsed code, third-party libraries, deploy-time configuration and business logic flaws fall outside the analysis, and a false negative looks exactly like a clean result.
How accurate is Fluid Attacks' SAST scanner?
On the OWASP Benchmark v1.2 test suite it reaches a 100% true positive rate and a 0% false positive rate, for a benchmark score of 100%, and the documentation publishes the commands to reproduce it. On a real application with 1,201 vulnerabilities it reported 22.7% of them at 99% precision. Both numbers describe the same scanner against different targets.
Read the bug before someone else runs it
Our scanners and pentesters review your source code from the first commit, so vulnerabilities get fixed while they are still cheap. Start free trial · Contact us.
Run SAST on what changed in every pull request
