01Wie SAST technisch funktioniert
SAST-Engines übersetzen Code in Zwischenrepräsentationen – abstrakte Syntaxbäume oder relationale Programmfakten – und wenden darauf Kontrollfluss-, Datenfluss- und Taint-Analysen an. CodeQL etwa extrahiert den Code in eine Datenbank und formuliert Schwachstellen als Abfragen in einer Datalog-Erweiterung; Semgrep matcht Muster strukturell auf dem Syntaxbaum, mit Quellen, Senken und Sanitizern als Taint-Regeln. Entscheidend für die Tiefe: Analyse innerhalb einer Funktion ist Standard – interprozedurale Analyse über Datei- und Funktionsgrenzen hinweg trennt die Werkzeugklassen und ist etwa bei Semgrep dem kommerziellen Angebot vorbehalten.
02Die bewiesene Grenze: exakt geht nicht
Nach Rice’ Theorem sind alle nicht-trivialen semantischen Programmeigenschaften unentscheidbar – eine Analyse, die alle Schwachstellen findet und nie falsch alarmiert, ist mathematisch unmöglich. Jedes Werkzeug wählt eine Seite: Überapproximation (keine übersehenen Fälle im modellierten Raum, dafür systematische Fehlalarme – das Fundament legten Cousot & Cousot 1977 mit der Abstrakten Interpretation) oder Unterapproximation (präziser, dafür Lücken). Fehlalarme sind also kein Implementierungsfehler, sondern der Preis des Ansatzes – die Frage ist nur, wer sie aussortiert.
03Was SAST zuverlässig findet
Seine Stärken hat SAST bei Fehlerklassen mit stabiler Form: Injection, unsichere Kryptografie-Aufrufe, hartkodierte Zugangsdaten, Speicherfehler in C/C++ – mit exakter Angabe von Datei, Zeile und Codestelle, lange bevor eine testbare Anwendung existiert. OWASP SAMM setzt automatisierte statische und dynamische Tests deshalb bereits auf Reifegrad 1 des Security-Testing-Streams: Sie sind die skalierbare Basislinie, auf der tieferes, manuelles Testen aufsetzt.
04Was SAST strukturell nicht findet
OWASP benennt die blinden Flecken deutlich: Authentifizierungs- und Autorisierungsfehler, falsche Kryptografie-Nutzung und Geschäftslogikfehler sind automatisiert schwer bis gar nicht erkennbar – Konfigurationsfehler stehen gar nicht erst im Code. Die Messung bestätigt das: In einer ISSTA-Studie der TU München verpassten sechs C/C++-Analyzer 47 bis 80 Prozent von 192 bekannten realen Schwachstellen; selbst die Kombination aller Werkzeuge ließ 30 bis 69 Prozent durch. Diese Klassen brauchen Threat Modeling, Reviews – oder semantisches Reasoning.
Wissensseite Threat Modeling →05Die False-Positive-Realität
Zwischen 35 und 91 Prozent der Warnungen statischer Analyse sind laut konsolidierter Forschungsliteratur nicht handlungsrelevant. Eine – anbieterfinanzierte – Feldstudie über knapp 3.000 öffentliche Repositories fand 2025 über 91 Prozent Fehlalarme bei drei klassischen Fehlerklassen, im Extremfall 1.166 Findings mit 6 echten Treffern. Und eine Auswertung von über 100 Millionen AppSec-Findings aus 178 Organisationen zeigte: Nur 2 bis 5 Prozent erfordern sofortiges Handeln. Alert Fatigue ist kein Weichfaktor, sondern der häufigste Grund, warum SAST-Programme scheitern.
06Was Google und Meta anders machen
Die zwei wirksamsten Stellschrauben sind publiziert: Bei Meta lag die Fix-Rate nächtlicher Batch-Scans nahe null; als dieselbe Analyse als Kommentar in den Code-Review des Diffs wanderte, stieg sie auf über 70 Prozent – gleiche Engine, gleiche Fehlalarmquote. Google lässt nur Analysen in den Review, deren effektive Fehlalarmquote unter 10 Prozent bleibt; real liegt das Tricorder-System knapp unter 5 Prozent. Die Lehre: Auslieferungszeitpunkt und Entwickler-Vertrauen schlagen Werkzeugqualität.
07Werkzeuge seriös bewerten
Der OWASP Benchmark ist eine lauffähige Java-Anwendung mit 2.740 tatsächlich ausnutzbaren Testfällen in 11 Kategorien; bewertet wird über True-Positive- gegen False-Positive-Rate (Youden-Index). NISTs Juliet-Suite ergänzt synthetische Testfälle über 118 CWEs in C/C++ und 112 in Java. Vorsicht bei Herstellerangaben wie „100 % Erkennung“: Die Korpora sind öffentlich, Overfitting ist möglich – und neuere Benchmarks wie CASTLE zeigen, dass jede Werkzeugklasse eigene Ausfallmuster hat: formale Verifikation minimiert Fehlalarme, versagt aber außerhalb ihres Modells; LLMs stark auf Snippets, schwächer mit wachsender Codegröße.
08Werkzeuglandschaft im Umbruch
2024/2025 haben sich die Koordinaten verschoben: Semgrep stellte im Dezember 2024 seine gepflegten Regeln unter eine proprietäre Lizenz – ein Konsortium von rund zehn Security-Anbietern forkte die Engine daraufhin als Opengrep (LGPL; nach einem Jahr: 43 Releases und funktionsübergreifende Taint-Analyse als Open Source). Sonar zog seine Sprach-Analyzer ebenfalls aus der LGPL. GitHub teilte Advanced Security zum April 2025 in Code Security (30 US-$ je aktivem Committer/Monat) und Secret Protection (19 US-$). Und Gartner legte den Magic Quadrant für Application Security Testing nach zweijähriger Pause im Oktober 2025 neu auf – mit 16 Anbietern und ASPM als Bewertungsdimension.
09Was KI an SAST ändert
Die belastbarsten Zahlen liegen bei der Triage: LLM-Agenten hinter klassischem SAST reduzierten Fehlalarme auf dem OWASP Benchmark um bis zu 88,6 Prozent bei nur 3,1 Prozent Recall-Verlust; auf realen CodeQL-Alerts identifizierten sie bis zu 93,3 Prozent der False Positives. GitHubs Copilot Autofix verkürzt die Behebung laut Beta-Telemetrie im Median von 1,5 Stunden auf 28 Minuten. Und autonome Systeme wie Google Big Sleep oder die DARPA-AIxCC-Finalisten finden reale Schwachstellen inzwischen selbstständig. Die Grenzen aus Karte 4 verschieben sich damit – verschwinden aber nicht: KI ergänzt die Schichten, sie ersetzt sie nicht.
Vertiefung: AI Code Security → 
