What is SAST?
Static application security testing (SAST), also called static code analysis, examines an application's source code, bytecode or compiled binaries without executing it. Because it works from the inside, with a full view of the code, it is a white-box technique. SAST tools run in the developer's editor, on every commit or pull request and in the build pipeline, so flaws are found while the code is still being written. Moving testing earlier like this is often called shifting left, and it pays off because a flaw fixed before release costs far less than one fixed in production.
How SAST works
A SAST tool parses the code into a model of its structure and data flow, then applies rules to that model. Its central technique is taint analysis. Any value an outsider can influence, such as a request parameter, header or uploaded file, is marked as a tainted source. The tool follows that value through assignments and function calls, and if it can arrive at a dangerous sink, such as a SQL statement, an operating system command, a file path or HTML sent to the browser, without being validated, encoded or parameterized on the way, the path becomes a finding. Other rules flag dangerous functions, weak cryptography such as MD5 used for password storage, hardcoded credentials and insecure settings written into code. Each finding names the file, the line and usually a CWE identifier, such as CWE-89 for SQL injection or CWE-798 for hardcoded credentials.
Common tools include Semgrep, CodeQL and SonarQube, and many code hosting platforms build SAST into pull request checks.
Example: a SAST finding
A Node.js route builds a query from a URL parameter:
db.query(`SELECT * FROM orders WHERE id = ${req.query.id}`)
The tool reports CWE-89 at routes/orders.js:31: tainted data from req.query.id flows into db.query(). The fix is a parameterized query, db.query('SELECT * FROM orders WHERE id = $1', [req.query.id]), which keeps the input out of the SQL structure. A pipeline can be set to block the merge until high-severity findings like this one are fixed or formally accepted.
Strengths and limits of static analysis
SAST can cover every line of code, including error paths that testers rarely reach, and it points developers to the exact line to change. It needs no running environment. Its weaknesses are just as predictable:
- False positives: a tool may not recognize a custom sanitizer, so findings need triage, and suppressions should be documented rather than whole rules switched off.
- No runtime view: server configuration, missing security headers and deployment mistakes do not exist in the source.
- Logic flaws: broken authorization, such as a user reading another customer's order by changing an ID, has no telltale pattern for a tool to match.
- Third-party code: known vulnerabilities in libraries are found by software composition analysis, not SAST.
SAST vs. DAST vs. software composition analysis
| SAST | DAST | SCA | |
|---|---|---|---|
| Examines | Your source code or binaries | The running application | Third-party dependencies |
| Needs source | Yes, or binaries | No | A manifest, lock file or build |
| When | While coding and at each commit | In a test or staging environment | At each build |
| Reports | File and line | URL, parameter and request | Component, version and CVE |
Manual code review complements all three, especially for authorization and business logic.
SAST on the CompTIA Security+ exam
Static code analysis is one of the application security controls in SY0-801 objective 4.1, and it comes up again under objective 4.3, where source code review finds vulnerabilities in software an organization writes itself. Wording such as review source code without running the program, find flaws before deployment or scan every commit in the build pipeline points to SAST. The distractors are close relatives: DAST tests the running application without the source; fuzzing sends malformed input to a running program; manual code review is a person reading a change; dependency scanning checks libraries for known CVEs; and secrets scanning looks for credentials committed to repositories.