SAST (Static Application Security Testing).

SAST parses code into intermediate representations — an abstract syntax tree, control-flow graph, and data-flow graph — then applies pattern rules or taint analysis to detect insecure constructs mapped to CWE identifiers. Taint analysis is the core engine: it marks untrusted sources (an HTTP parameter, a file read), tracks how that data propagates through variables and function calls, and raises a finding when it reaches a dangerous sink (a SQL query, exec, an HTML response) without passing through a recognised sanitiser. Because nothing executes, SAST runs in IDEs, pre-commit hooks, and CI, and can scan code long before it ships.

Its blind spots are well documented. SAST is strong on deterministic bugs (SQL injection, XSS sinks, hard-coded secrets, weak crypto) but generates false positives on paths that are unreachable at runtime, and misses configuration, authentication-logic, and runtime-only flaws — so mature programs pair it with SCA and DAST. Tuning rulesets and triaging noise are the real operational costs. Standards such as OWASP ASVS and NIST SSDF reference static analysis as a verification control. Common engines include Semgrep, GitHub CodeQL (which queries code as a database), SonarQube, Checkmarx, Fortify, and Snyk Code.

flowchart LR
  SRC[Source code / bytecode] --> P[Parse to AST + CFG + DFG]
  P --> T[Taint analysis + rules]
  SO[Untrusted source] -. tracked flow .-> T
  T --> SK{Reaches sink<br/>without sanitiser?}
  SK -->|Yes| F[Finding mapped to CWE]
  SK -->|No| OK[No alert]
  F --> TR[Triage: fix or mark false positive]