SAST: static application security testing explained

SAST, short for static application security testing, analyzes an application's source code or compiled code for security flaws without running it. A SAST tool reads the code, follows how data moves through it, and reports places that match a known flaw pattern, with the file and line.

What is SAST (static application security testing)?#

SAST means testing the code itself, not the running system. OWASP describes "source code analysis tools, also known as Static Application Security Testing (SAST) Tools" as tools that "can help analyze source code or compiled versions of code to help find security flaws."

Because the app never runs, SAST can start as soon as code exists. A developer can run it in an editor on an unfinished function. That is the main reason teams use it: a flaw found on the day it is written costs less to fix than one found after release.

SAST belongs to a family of testing methods. Methods that read code are "static". Methods that send requests to a running app are "dynamic", and a penetration test is the manual form of dynamic testing. Our types of penetration testing guide shows where each method sits.

How does SAST work, from source to sink?#

Most SAST rules follow one idea: find a source of untrusted input, find a sink that does something dangerous, and check whether data can travel from one to the other without cleaning.

A source is where outside data enters, such as a request parameter, a header or a file upload. A sink is a call that is dangerous with bad input, such as a SQL query, a shell command or an HTML output. A sanitizer is code that makes data safe for a given sink, such as a parameterized query.

The tool builds a model of the code, often a syntax tree plus a data flow graph, and walks it. If the path from source to sink has no sanitizer, the tool raises a finding. Simpler rules skip the data flow and match patterns, such as a call to a weak hash function or a hard-coded password in a string.

SAST tools also differ in what they read. Some read source code. Others read compiled code, such as bytecode. Compiled analysis helps when source is not available. OWASP notes that many tools struggle with code that cannot be compiled, and analysts often lack the right libraries or build instructions.

What does a SAST finding look like? A worked example with the fix#

The classic SAST finding is SQL injection, listed as CWE-89 by MITRE. Its description starts: "The product constructs all or part of an SQL command using externally-influenced input from an upstream component." The code below builds a query from a request parameter.

# notes/search.py (Harbor Notes, fictional)
def search_notes(request):
    term = request.args.get("q")                      # source: user input
    sql = "SELECT id, title FROM notes WHERE owner = %s AND title LIKE '%" + term + "%'"
    rows = db.execute(sql, (request.user.id,))        # sink: SQL execution
    return rows

A SAST tool reports a finding such as this one (format varies by tool):

rule: sql-injection (CWE-89)
file: notes/search.py  line: 4
source: request.args.get("q") at line 2
sink: db.execute() at line 4
path: term -> sql (string concatenation) -> db.execute
sanitizer on path: none

The fix keeps user input out of the query text. Pass it as a bound parameter, so the database treats it as data.

def search_notes(request):
    term = request.args.get("q", "")
    sql = "SELECT id, title FROM notes WHERE owner = %s AND title LIKE %s"
    rows = db.execute(sql, (request.user.id, "%" + term + "%"))
    return rows

After the change, rerun the tool. The finding should close because the path no longer carries a string into the query text. Add a test that sends a quote character in q and expects a normal empty result. That test protects the fix from later edits.

What does SAST find, and what does it miss?#

SAST is good at flaws that have a visible code pattern. It is weak at flaws that depend on how the running system behaves. OWASP lists both sides, and its list is the best neutral summary we found.

Access control is the clearest gap. A tool cannot know that user A should not read user B's note, because that rule lives in your product design. Testers find such flaws with two accounts, as in our IDOR testing guide, and with the methods in business logic vulnerabilities.

How do you triage SAST false positives?#

A false positive is a finding that does not describe a real vulnerability. OWASP lists "high numbers of false positives" as a SAST weakness, so triage is part of the job. Work through each finding with the same short checklist.

1. Read the source and sink. Is the source really attacker-controlled? A constant or an internal ID is not.
2. Read the path. Is there a sanitizer the tool did not recognize, such as a custom escape function or a framework feature that binds parameters?
3. Check reachability. Is the code called at all? Dead code and test code rarely matter.
4. Try to reproduce it. If the code is reachable, send a safe test input to a test environment and watch the result.
5. Decide and record. Mark the finding as fix, accepted risk or false positive, with a reason and the date.
6. Tune the rule. If one rule produces many false positives, add the custom sanitizer to the tool or narrow the rule to the paths it fits.

Keep a suppression file under version control, and require a reason on each entry. A bare "ignore" hides a real flaw the next time the code changes. Review suppressions when a major dependency or framework version changes.

Where does SAST run: IDE, pull request or CI?#

SAST can run at four points. Each trades speed for depth.

A common setup runs fast checks on each pull request and a full scan on a schedule. Block merges only for high-confidence rules at first. If every finding blocks the build, developers learn to dodge the tool. Raise the bar as the false positive rate falls.

How is SAST different from DAST and a pentest?#

SAST reads code. DAST (dynamic application security testing) sends requests to a running app and watches the responses. A penetration test adds a person who chains findings, tests business rules and proves impact.

NIST SP 800-115, published in 2008 and still listed as final, covers technical testing and assessment techniques and their benefits and limitations. It is a useful base for planning, though it predates modern pipelines.

A pentest also tells you which SAST findings matter. If the tool flags 40 issues, a tester can confirm which ones an outside attacker can reach and which are dead paths. Read what is penetration testing for the process. For a neutral view of how scanners and pentests differ, see the PentestCompare scan versus pentest guide.

SAST is one input to your security program, not proof that the app is secure. Pair it with a test of the running system before a launch or a customer security review.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report