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.
SAST – Code prüfen, bevor er läuft
Statische Codeanalyse ist der am dichtesten kreuzreferenzierte Kontrollpunkt im sicheren Entwicklungszyklus – und zugleich das Werkzeug mit dem größten Frustpotenzial. Was SAST technisch leistet, wo seine Grenzen bewiesen sind, welche Standards es verlangen und was KI daran gerade ändert.
47–80 %der 192 bekannten realen Schwachstellen von sechs C/C++-Analyzern verpasst (ISSTA-Studie der TU München)
35–91 %der Warnungen statischer Analyse laut konsolidierter Forschungsliteratur nicht handlungsrelevant
70 %Fix-Rate bei Meta durch Review-Kommentare am Diff (über 70 %, vorher nahe null)
bis zu 88,6 %weniger Fehlalarme durch LLM-Triage auf dem OWASP Benchmark — bei nur 3,1 % Recall-Verlust
SAST (Static Application Security Testing) prüft Quellcode, Bytecode oder Binärdateien auf Schwachstellen, ohne das Programm auszuführen – im Unterschied zu DAST (Test der laufenden Anwendung von außen), IAST (Instrumentierung zur Laufzeit) und SCA (Analyse der Abhängigkeiten). Die Stärke: SAST findet bekannte Fehlerklassen früh, auf jeder Codezeile und mit exakter Fundstelle – günstig genug für jeden Commit. Der Preis: Weil eine vollautomatische, zugleich vollständige und korrekte Analyse theoretisch unmöglich ist, approximiert jedes Werkzeug – und produziert Fehlalarme oder übersieht Fehlerklassen ohne Signatur. Wer SAST richtig einsetzt, entscheidet deshalb nicht „welches Tool“, sondern: welche Analyse auf welchem Code an welcher Stelle im Workflow – und wer die Findings triagiert. Genau an dieser Triage setzt seit 2024 die größte Veränderung seit Jahren an: KI-gestützte Analyse und Priorisierung.
Werkzeuglandschaft im Umbruch
2024/2025 haben sich die Koordinaten verschoben — Meilenstein antippen für Details.
Dez. 2024
Semgrep-Lizenzwechsel
Semgrep stellt seine gepflegten Regeln unter eine proprietäre Lizenz. Ein Konsortium von rund zehn Security-Anbietern forkt die Engine daraufhin als Opengrep (LGPL) — nach einem Jahr: 43 Releases und funktionsübergreifende Taint-Analyse als Open Source.
Apr. 2025
GitHub teilt Advanced Security
GitHub teilt Advanced Security in Code Security (30 US-$ je aktivem Committer/Monat) und Secret Protection (19 US-$).
Okt. 2025
Gartner-Magic-Quadrant neu aufgelegt
Nach zweijähriger Pause legt Gartner den Magic Quadrant für Application Security Testing neu auf — mit 16 Anbietern und ASPM als Bewertungsdimension.
Das Wichtigste im Überblick
Neun Themenblöcke — zum Aufklappen antippen.
Stärken, Grenzen, Realität
Was SAST zuverlässig findet, wo es strukturell blind ist, wie real das Rauschen ist — und welche Hebel Google und Meta publiziert haben.
- SAST ist stark bei Fehlerklassen mit stabiler Form: Injection, unsichere Kryptografie-Aufrufe, hartkodierte Zugangsdaten, Speicherfehler in C/C++ — mit exakter Angabe von Datei, Zeile und Codestelle.
- Die Findings kommen, lange bevor eine testbare Anwendung existiert. OWASP SAMM setzt automatisierte statische und dynamische Tests deshalb bereits auf Reifegrad 1 des Security-Testing-Streams: die skalierbare Basislinie, auf der tieferes, manuelles Testen aufsetzt.
InjectionKryptografie-AufrufeHartkodierte ZugangsdatenSpeicherfehler C/C++OWASP SAMMReifegrad 1
- 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.
AuthentifizierungAutorisierungGeschäftslogikKonfigurationsfehlerThreat ModelingReviews
- 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 von über 100 Millionen AppSec-Findings aus 178 Organisationen erforderten nur 2 bis 5 Prozent sofortiges Handeln.
- Alert Fatigue ist kein Weichfaktor, sondern der häufigste Grund, warum SAST-Programme scheitern.
Alert FatigueFehlalarmeAppSec-FindingsSAST-Programme
- 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.
Batch-ScansCode-ReviewDiffTricorderFehlalarmquote
Vertiefung · SAST mit LLMs und KI
AI-SAST: Die Analyse lernt, Absicht zu lesen
Seit 2024 verändert sich SAST schneller als in den fünfzehn Jahren davor: Sprachmodelle triagieren Findings, schließen semantisch über Funktionsgrenzen hinweg und finden inzwischen reale Zero-Days. Wiz hat dafür im Juli 2026 ein Drei-Stufen-Modell formuliert — deterministisches Baseline-Scanning, kontinuierliches KI-Reasoning auf jedem Pull Request, gezieltes agentisches Deep-Testing — mit der Kernthese: „Deep scanning everywhere doesn't scale.“ Die vier wichtigsten Entwicklungen im Überblick:
LLM-Triage hinter dem Scanner
Der am besten belegte Nutzen: Ein LLM-Filter hinter dem deterministischen Scanner reduziert Fehlalarme um 88,6 bis 93,3 Prozent bei minimalem Recall-Verlust — über mehrere unabhängige Studien hinweg konsistent.
Semantisches Reasoning auf jedem PR
Statt Mustern prüft die KI Anwendungsstruktur, Trust Boundaries und Datenflüsse — „wie ein Sicherheitsforscher“. Neuro-symbolische Ansätze wie IRIS verdoppeln die Erkennung gegenüber CodeQL allein.
Autonome Tiefenanalyse
Systeme wie Wiz Atlas (über 90 % auf CyberGym, 200+ unbekannte Schwachstellen) oder die DARPA-AIxCC-Finalisten finden reale Lücken selbstständig — das Finden wird zur Commodity.
Neue Grenzen und Angriffsfläche
LLM-Urteile sind nicht deterministisch und manipulierbar: Adversariale Code-Kommentare täuschen LLM-Detektoren in über 90 % der Fälle. Der KI-Analyst braucht dieselbe Härtung wie jedes andere Werkzeug.
Zur Wissensseite: AI-SAST — Codeanalyse mit LLMs
Mit allen Belegen: Studienlage, Werkzeuglandschaft 2026, Risiken und Governance — inklusive des Wiz-Schichtenmodells im Detail.
Unsere Lösung · AI-SAST im Betrieb
VamiAppSec: sechs Scanner, ein Backlog, KI-Triage
Unsere Plattform VamiAppSec orchestriert Semgrep, Gitleaks, Checkov, Syft/Grype und den Claude Code Security Reviewer in einer Pipeline, normalisiert alle Findings in ein einheitliches Schema und reichert jeden Fund per LLM an – mit Kontext, Ausnutzbarkeits-Einschätzung und konkretem Patch-Vorschlag. Genau die Triage-Arbeit, an der klassische SAST-Programme scheitern, übernimmt damit die Maschine – nachvollziehbar und im eigenen Rechenzentrum betreibbar.
6+Scanner in einer Pipeline
−54 %mediane Triagezeit
93 %Dubletten eliminiert
24 hbis zur Inbetriebnahme
- Self-hosted oder SaaS – auf Wunsch vollständig auf Ihrer Infrastruktur
- Integrationen: GitHub, GitLab, Bitbucket, Jenkins, Slack, MS Teams
- Dazu als Beratung: Scanning-Architektur, Kalibrierung und Exploit-Validierung
Kennzahlen aus eigenen Messungen gegenüber roher Scanner-Ausgabe; Details auf vamiappsec.com.
Standards & Quellen
Die Inhalte dieser Seite basieren auf den folgenden öffentlich verfügbaren Leitfäden und Studien.
SP 800-218: Secure Software Development Framework (SSDF) v1.1
Verankert Codeanalyse in Practice PW.7 (und nach Release in RV.1.2); die Referenztabelle mappt PW.7 auf IEC 62443-4-1, ISO/IEC 27034 und OWASP ASVS – der dichteste Cross-Standard-Anker für SAST.
Source Code Analysis Tools
Kanonische Einordnung der Stärken (bekannte Fehlerklassen, exakte Fundstelle) und Schwächen (Autorisierung, Geschäftslogik, Konfiguration, hohe Fehlalarmzahlen).
OWASP Benchmark Project
2.740 lauffähige, tatsächlich ausnutzbare Java-Testfälle in 11 Kategorien; Bewertung über den Youden-Index. Python-Variante in Arbeit.
Juliet Test Suite 1.3 (SARD)
Synthetische Testfälle über 118 CWEs (C/C++) bzw. 112 (Java) mit Gut/Schlecht-Zwillingen zur Diskriminationsmessung.
An Empirical Study on the Effectiveness of Static C Code Analyzers (ISSTA)
Sechs Analyzer gegen 192 reale Schwachstellen in 27 Projekten: 47–80 % übersehen; Werkzeug-Kombination senkt die Lücke nur auf 30–69 %.
Scaling Static Analyses at Facebook (CACM)
Der Diff-Scan-Beleg: Fix-Rate nahe null bei Batch-Scans, über 70 % nach Umstellung auf Review-Kommentare am Diff – bei identischer Analyse.
Lessons from Building Static Analysis Tools at Google (CACM)
Die 10-%-Regel: Analysen über dieser effektiven Fehlalarmquote fliegen aus dem Review; Tricorder liegt real knapp unter 5 %.
TR-03185: Sicherer Software-Lebenszyklus, Teil 1
PROD.DEV.F.2: „Darüber hinaus SOLLTE eine automatische statische Codeanalyse durchgeführt werden“ – mit Querverweisen auf CON.8, SSDF (PW) und IEC 62443-4-1.
IT-Grundschutz-Kompendium, Baustein CON.8 Software-Entwicklung
Basis-Anforderung CON.8.A7: entwicklungsbegleitende Tests, ergänzt um die SOLLTE-Empfehlung zur automatischen statischen Codeanalyse.
PCI DSS v4.0.1, Requirement 6.2.3
Code-Review vor Produktivgang für Individual-Software – manuell oder automatisiert; als zukunftsdatierte Anforderung seit 31.03.2025 verpflichtend.
State of Software Security 2025
Telemetrie aus über 1,3 Mio. Anwendungen: Fix-Halbwertszeit 252 Tage (+47 % in 5 Jahren); 74 % der Organisationen tragen Security Debt, 70 % der kritischen Debt stammt aus Drittcode.
Magic Quadrant for Application Security Testing
Neuauflage vom 6. Oktober 2025 nach zweijähriger Pause; 16 bewertete Anbieter, ASPM als Bewertungsdimension integriert.
Consolidated dataset on static analysis alert actionability
Konsolidiert die Forschungslage zur Alert Fatigue: 35–91 % der Warnungen statischer Analyzer sind nicht handlungsrelevant.
SAST einführen, entrümpeln oder mit KI beschleunigen?
In einem unverbindlichen Erstgespräch schauen wir auf Ihre Pipeline: welche Analyse wo läuft, wie viel Rauschen Ihr Team trägt und wo KI-Triage den größten Hebel hat.