SAST Fundamentals

A scanner does not read your code the way you do. It builds a model of it — syntax tree, types, call graph, data flow — and then asks questions of that model. Everything a SAST tool can find, and everything it silently cannot, follows from what the model represents.

What SAST actually does

Static analysis parses the source into an abstract syntax tree, resolves names and types, then builds a control-flow graph per function and a call graph across them. A rule is a query over that model — "a call to this API whose argument is derived from this parameter" — not a regular expression over text. Nothing is executed, so a finding is a claim that a path exists, not proof that it runs.

That distinction predicts which classes the tool is good at. Injection, unsafe deserialization and weak crypto are expressible as "untrusted data reached this API", so a dataflow engine models them well. Broken access control, multi-tenant isolation and business-logic flaws are usually a missing check — and no rule can match an absence. The other blind spot is deployment: the scanner reads the repository, so a patched dependency in the container image, a WAF rule in front of the service and a runtime feature flag are all invisible to it.

Treat the output as a ranked reading list, not a defect count. The engine is good at finding the file; you are still the one who decides whether the path is real.

Taint analysis

Taint analysis has three parts and one direction. A source introduces untrusted data — an HTTP parameter, a header, a message body, a file upload. A sink is an API that gives the value meaning: a query executor, a shell, an HTML parser, a deserializer. Between them the value propagates through assignments, returns, collection inserts and string concatenation. A sanitizer is a call the engine knows removes the danger — a numeric parse, an allowlist check, a bind.

Two properties decide how much a given engine can see. Intraprocedural analysis follows the value inside one function; interprocedural analysis follows it across the call graph. Semgrep CE is single-file by design, so a value that enters in a controller and reaches a sink in a repository class is invisible to it unless the rule is written for the intermediate shape. CodeQL builds a database with cross-function dataflow, which is why it costs a compile and a query run.

// ReportController.java — request parameter is the source
String name = request.getParameter("name");
String sql = "SELECT id, email FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

// ReportController.java — request parameter is the source
String name = request.getParameter("name");
String sql = "SELECT id, email FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

// ReportController.java — the value is bound, never parsed as syntax
String sql = "SELECT id, email FROM users WHERE name = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
  ps.setString(1, name);
  return ps.executeQuery();
}

// ReportController.java — the value is bound, never parsed as syntax
String sql = "SELECT id, email FROM users WHERE name = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
  ps.setString(1, name);
  return ps.executeQuery();
}

The same path written as a taint rule. Note the sanitizer entry: without it, every numeric parse in the codebase looks like a bypass, and the rule's precision collapses.

rules:
  - id: java-sql-string-concat
    languages: [java]
    message: Request parameter reaches a SQL string built by concatenation.
    severity: ERROR
    mode: taint
    pattern-sources:
      - pattern: (HttpServletRequest $R).getParameter(...)
    pattern-sanitizers:
      - pattern: Integer.parseInt(...)
    pattern-sinks:
      - pattern: (Statement $S).executeQuery(...)

Taint analysis - source, propagation, sink, sanitizer

Scroll sideways to see the whole diagram

View full size View full size

Top-down and bottom-up

Run both. A sink that bottom-up finds and top-down cannot reach is usually dead code or a job with no authentication — worth knowing either way. A path that both reach is a finding you can file without further argument. In practice, spend the first hour bottom-up to build the sink inventory and the rest of the day top-down through the entry points that matter, because that is where access control lives.

Dangerous sinks

These are the bottom-up searches. Three flags do the work: -r recurses, -n prints line numbers so a finding is addressable, and -E switches to extended regular expressions so | means alternation. The trailing . is the path operand — without it GNU grep waits on stdin and BSD grep errors, so a search that "finds nothing" is often a search that never ran.

# SQL — CWE-89. -E so | is alternation, -n for line numbers, . is the path operand.
grep -rnE "executeQuery|executeUpdate|createNativeQuery|prepareCall" --include="*.java" .
grep -rnE "cursor\.execute|\.raw\(|RawSQL|extra\(" --include="*.py" .
grep -rnE "\.query\(|\.raw\(|sequelize\.query" --include="*.js" --include="*.ts" .
grep -rnE "mysqli_query|->query\(|PDO::query" --include="*.php" .

# Android SQLite — rawQuery/execSQL are the platform API, not JDBC. Same defect, different driver.
grep -rnE "rawQuery|execSQL" --include="*.java" --include="*.kt" .

# Command execution — CWE-78
grep -rnE "getRuntime|ProcessBuilder" --include="*.java" .
grep -rnE "os\.system|subprocess\.(run|call|Popen)|os\.popen" --include="*.py" .
grep -rnE "child_process|execSync|spawnSync" --include="*.js" --include="*.ts" .
grep -rnE "shell_exec|passthru|proc_open|system\(" --include="*.php" .

# XSS — CWE-79. The sink is where the value is handed to an HTML parser.
grep -rnE "innerHTML|outerHTML|document\.write|insertAdjacentHTML" --include="*.js" --include="*.ts" .
grep -rnE "dangerouslySetInnerHTML|v-html" --include="*.jsx" --include="*.tsx" --include="*.vue" .
grep -rnE "\|safe|Markup\(" --include="*.html" --include="*.jinja" .

# Deserialization — CWE-502
grep -rnE "ObjectInputStream|readObject|XMLDecoder|XStream" --include="*.java" .
grep -rnE "pickle\.loads|yaml\.load" --include="*.py" .
grep -rnE "unserialize" --include="*.php" .
grep -rnE "BinaryFormatter|TypeNameHandling" --include="*.cs" .

# Path traversal — CWE-22
grep -rnE "new File\(|Paths\.get|FileInputStream|Files\.copy" --include="*.java" .
grep -rnE "path\.join|fs\.(readFile|createReadStream|writeFile)" --include="*.js" --include="*.ts" .
grep -rnE "send_file|os\.path\.join|open\(" --include="*.py" .

A hit is a lead, not a finding. The table is what each sink actually means, so the next step — read the call site, check the argument, find the route — starts from the right question.

Triage and prioritisation

The first useful act on a scan report is to collapse it. Group by rule and file: a rule that fires 200 times in a generated client is one decision, not 200 findings, and a rule that fires twice in an authentication filter is two. Read the grouped view before you open a single result.

Then ask three questions of every group. Is it reachable from a route, job or consumer an attacker can touch? Is there an authorisation check in front of that path, and does it constrain the object or only the route? What is the data class at the sink — public content, tenant data, credentials? The answers sort the report into prove now, ask the owner, and close as unreachable with a reason recorded.

# Group findings by rule and file before reading any of them.
jq -r '.runs[].results[] | [.ruleId, (.locations[0].physicalLocation.artifactLocation.uri // "?")] | @tsv' results.sarif | sort | uniq -c | sort -rn | head -40

The limits of SAST

Three techniques sit behind the reports you will read, and they fail differently. Pattern and semantic matching looks for known shapes — a call, an annotation, an assignment — and is fast and deterministic, but it has no reach across functions and no idea what happens to the value later. Taint and dataflow analysis follows the value, which is why it finds real chains; it depends entirely on models for your frameworks, so a wrapper class or a custom ORM becomes a blind spot. AI-assisted review is the 2026 addition: useful for "this looks wrong" on logic the rules cannot express, non-deterministic between runs, and with recall nobody has convincingly measured.

This is also why no honest false-positive figure exists for SAST as a category. Precision varies by rule class: a hardcoded-secret rule and a taint rule aimed at a custom data layer have nothing in common, and vendor numbers are self-reported on their own benchmarks. Measure it yourself — run the tool against OWASP Benchmark for a comparable score, then label fifty findings from your own repository and count. That second number is the one that tells you how much of the report to trust.

# Two engines, one tree: the diff between the SARIF files is the interesting part.
semgrep --config p/java --sarif --output semgrep.sarif src/
codeql database analyze db codeql/java-queries:codeql-suites/java-security-extended.qls --format=sarif-latest --output codeql.sarif

Evidence Collection

False Positive Identification

SAST Programme Checklist

Remediation & Defense