SAST (Static Application Security Testing).

SAST parst Code in Zwischenrepräsentationen – einen abstrakten Syntaxbaum (AST), einen Kontrollflussgraphen (CFG) und einen Datenflussgraphen (DFG) – und wendet dann Musterregeln oder Taint-Analyse an, um unsichere Konstrukte zu erkennen, die CWE-Kennungen zugeordnet werden. Die Taint-Analyse ist die zentrale Engine: Sie markiert nicht vertrauenswürdige Quellen (einen HTTP-Parameter, einen Dateilesevorgang), verfolgt, wie sich diese Daten durch Variablen und Funktionsaufrufe ausbreiten, und meldet einen Fund, wenn sie einen gefährlichen Sink erreichen (eine SQL-Abfrage, exec, eine HTML-Antwort), ohne einen anerkannten Sanitizer durchlaufen zu haben. Da nichts ausgeführt wird, läuft SAST in IDEs, Pre-Commit-Hooks und CI und kann Code lange vor der Auslieferung scannen.

Seine blinden Flecken sind gut dokumentiert. SAST ist stark bei deterministischen Fehlern (SQL-Injection, XSS-Sinks, hartcodierte Secrets, schwache Kryptografie), erzeugt aber Falsch-Positive bei Pfaden, die zur Laufzeit nicht erreichbar sind, und übersieht Konfigurations-, Authentifizierungslogik- und rein laufzeitbezogene Fehler – daher kombinieren reife Programme es mit SCA und DAST. Das Tunen von Regelsets und das Triagieren des Rauschens sind die eigentlichen operativen Kosten. Standards wie OWASP ASVS und NIST SSDF verweisen auf statische Analyse als Verifikationskontrolle. Verbreitete Engines sind Semgrep, GitHub CodeQL (das Code als Datenbank abfragt), SonarQube, Checkmarx, Fortify und Snyk Code.

flowchart LR
  SRC[Quellcode / Bytecode] --> P[Parsen zu AST + CFG + DFG]
  P --> T[Taint-Analyse + Regeln]
  SO[Nicht vertrauenswürdige Quelle] -. verfolgter Fluss .-> T
  T --> SK{Erreicht Sink<br/>ohne Sanitizer?}
  SK -->|Ja| F[Fund, CWE zugeordnet]
  SK -->|Nein| OK[Kein Alert]
  F --> TR[Triage: beheben oder als Falsch-Positiv markieren]