Veröffentlicht am: 16. September 2026
6 Minuten Lesezeit
SAST oder LLM-Sicherheitsscanner: Wann welcher zum Einsatz kommt
KI-basiertes Review und SAST erkennen unterschiedliche Fehlerklassen. So lässt sich entscheiden, was wo läuft und wann beides gebraucht wird.
Diese Art von Experiment läuft längst in vielen Teams: ein Frontier-Modell auf einen Merge Request ansetzen und es zugleich als Schwachstellenscanner nutzen lassen. Bei einem einzelnen Merge Request funktioniert das oft gut. Das Modell liest den Code, denkt darüber nach, was er tun soll, und findet reale Probleme – manche davon Probleme, die ein musterbasierter Scanner komplett übersieht.
Der nächste Gedanke liegt nahe: Wenn ein Modell einen Merge Request so gut prüft, warum es nicht auch als Scanner für die gesamte Pipeline einsetzen? Genau da bricht die Idee zusammen. Ein Frontier-Modell als primären Scanner auf jedem Commit einer Enterprise-Codebasis laufen zu lassen, kostet mehr und verhält sich unberechenbarer, als es nur für die Prüfung eines einzelnen Merge Requests einzusetzen.
Für alle, die Application Security für ein Platform- oder Produktteam verantworten, war die Entscheidung nie ein Entweder-oder: Static Application Security Testing (SAST) oder LLM-Scanner. Es geht darum, welcher wo läuft. Wird diese Aufteilung richtig getroffen, bleibt deterministische Abdeckung auf jedem Commit erhalten, kommt Reasoning dort hinzu, wo es seinen Platz verdient, und lassen sich sowohl unberechenbare Inferenzkosten als auch Lücken im Audit-Trail vermeiden. So schneiden beide im Vergleich ab:
| Deterministischer Scanner (SAST) | KI-basiertes Review (LLM) | |
|---|---|---|
| Kosten | Besser Bruchteile eines Cents pro Scan, fest und planbar. | Ein kostenpflichtiger Inferenzaufruf pro Scan. Die Kosten skalieren mit dem Codevolumen und sind schwer vorhersehbar. |
| Konsistenz | Besser Meldet dieselben Schwachstellen, jedes Mal. | Kann bei gleichem Code von Durchlauf zu Durchlauf unterschiedliche Schwachstellen melden oder übersehen. |
| Audit-Nachweise | Besser Reproduzierbar: dieselbe feste Methode jedes Mal, einer CWE zugeordnet. | Ergebnisse können zwischen Durchläufen variieren, schwerer als eigenständiger Audit-Nachweis nutzbar. |
| Schwachstellentypen | Abhängig vom Schwachstellentyp Musterbasierte, nachvollziehbare Schwachstellen (Injection) | Abhängig vom Schwachstellentyp Intentionsbasierte und neuartige Schwachstellen: fehlende Auth-Prüfungen, defekte Ownership-Logik und Probleme, die noch keiner CVE oder CWE zugeordnet sind. Kann Geschäftslogik anhand von Kontext aus Issues, Epics und Docs einordnen. |
| Bestätigung eines Fundes | Meldet mögliche Schwachstellen, kann aber nicht bestätigen, ob eine davon ausnutzbar ist. | Besser Prüft Funde, indem ein funktionierender Exploit erzeugt wird, sodass weniger False Positives in die Warteschlange gelangen. |
Die Kosten des Scannens bei jedem Commit
Besser: SAST
Die Kosten, wenn ein LLM einen einzelnen Merge Request prüft, wirken gering. Wird dasselbe Modell aber auf jeden Commit einer Enterprise-Codebasis angesetzt, geht die Rechnung nicht mehr auf. Jeder Scan wird zu einem unberechenbaren, kostenpflichtigen Inferenzaufruf, und diese Kosten summieren sich mit jedem Commit, jeden Tag. SAST läuft im selben Umfang für Bruchteile eines Cents pro Scan, jedes Mal auf die gleiche Weise, planbar. SAST hält das Scannen pro Commit günstig und planbar, sodass Sicherheitsabdeckung nie mit dem Budget konkurriert. Ein LLM in dieser Rolle lässt die Kosten mit der Nutzung skalieren und schwer vorhersehbar werden.
Konsistenz und Audit-Nachweise
Besser: SAST
Läuft derselbe Code zweimal durch ein LLM, können sich die erkannten Schwachstellen unterscheiden. Das liegt nicht an einem Fehler des Modells, sondern daran, wie sampling-basiertes Reasoning funktioniert. Diese Inkonsistenz wird zur Herausforderung, sobald belegt werden muss, dass ein Scan stattgefunden hat und für Audits vertrauenswürdig ist. Auditor(inn)en prüfen Vollständigkeit und Genauigkeit von Scannern unabhängig, indem sie diese erneut laufen lassen und die Ergebnisse abgleichen. Weil ein deterministischer Scanner regelbasiert arbeitet, liefert er Konsistenz von Haus aus. Ein erneuter Lauf bringt jedes Mal dasselbe Ergebnis.
Schwachstellentypen
Besser: Abhängig vom Schwachstellentyp
Statische Scanner und LLM-Scanner sind bei unterschiedlichen Schwachstellenklassen stark. Ein deterministischer Scanner ist für musterbasierte Schwachstellen wie Injection-Fehler, hartcodierte Secrets und unsichere Krypto-Aufrufe gebaut. Er folgt festen Regeln und meldet daher bei jedem Lauf dieselben Probleme.
Ein LLM-Scan funktioniert anders. Er kann den Kontext rund um den Code lesen, die Epics, Issues und Docs, die beschreiben, was das System eigentlich tun soll – etwas, das ein Scanner strukturell nicht verarbeiten kann. Genau dieser Kontext ermöglicht es, Probleme in der Geschäftslogik zu erkennen, etwa eine fehlende Autorisierungsprüfung oder eine falsche Annahme zur Ownership. Ist dieser Kontext vorhanden, erkennt ein LLM, was ein musterbasierter Scanner strukturell niemals kann.
Einen Fund bestätigen
Besser: LLM-Scanner
Ein deterministischer Scanner meldet Kandidaten, kann aber nicht sagen, ob ein Fund tatsächlich ausnutzbar ist. Ein LLM geht weiter. Es schreibt einen schnellen Test, der versucht, die Schwachstelle auszulösen, sodass sich zeigt, ob ein Fund echt ist, bevor er in die Warteschlange gelangt. Das erspart die Untersuchung von False Positives und schafft bei Entwickler(inne)n Vertrauen in die Qualität der Funde.
Sicherheitsprogramme setzen zunehmend auf beides
Sicherheitsteams entscheiden sich nicht für einen Scanner-Typ, sondern bauen ein Programm auf, das beide nutzt. Deterministisches Scanning bleibt die Basis, die auf jedem Commit läuft, ohne Ausnahme, denn genau diese Abdeckung kann ein Programm nicht aufgeben. LLM-Scanner ergänzen das um die Reasoning-lastigen Prüfungen, in denen sie stark sind, meist auf Ebene des Merge Requests statt bei jedem Commit. Genau dort erkennen sie Schwachstellen, die ein deterministischer Scanner strukturell nicht finden kann. Gemeinsam ergibt das umfassende Abdeckung: deterministisches Scanning, das Muster zu planbaren Kosten erkennt, und LLM-Scanner für das Reasoning, das Logikfehler aufdeckt.
Neu bei GitLab? Advanced SAST scannt jeden Commit, während Security Review Flow (GitLabs LLM-basierter Sicherheitsscanner) das reasoning-basierte Review ergänzt – beides in derselben Pipeline. Kostenlose Testversion von GitLab Ultimate starten.
Bereits auf GitLab Ultimate? Security Review Flow aktivieren, damit es parallel zu den bereits laufenden SAST-Scans läuft.
FAQ
Kann KI SAST ersetzen?
Nicht als einziger Scanner. KI-basiertes Review findet reale Probleme, kann aber bei gleichem Code von Lauf zu Lauf unterschiedliche Schwachstellen melden oder übersehen. Ein LLM über jeden Commit im Enterprise-Maßstab laufen zu lassen, kostet zudem mehr und ist schwerer vorhersehbar als ein Scanner, der für kontinuierliches, deterministisches Laufen gebaut ist.
Warum sind reproduzierbare Audit-Nachweise für Compliance wichtig?
Frameworks für sichere Softwareentwicklung wie SOC 2, PCI DSS und der Cyber Resilience Act der Europäischen Union verlangen reproduzierbare, prüfbare Nachweise. Ein Scanner liefert Informationen, die Auditor(inn)en unabhängig überprüfen, indem sie ihn erneut laufen lassen und das Ergebnis abgleichen. Ein deterministischer Scanner unterstützt diese unabhängige Bestätigung von Haus aus. Ein probabilistisches Modell garantiert nicht bei jedem Scan dieselben Ergebnisse.
Was können KI-basierte Reviews erkennen, das SAST nicht kann?
KI-basierte Reviews erkennen Fehler in der Geschäftslogik: fehlende Autorisierungsprüfungen, defekte Ownership-Validierung und Bugs, die davon abhängen, zu verstehen, was der Code tun soll, nicht nur, wie er geschrieben ist. KI-basierte Reviews ermöglichen Reasoning über Intention, wozu musterbasiertes Scanning nicht gebaut ist.
Sollten Sicherheitsteams beides einsetzen?
Ja. SAST und KI-basierte Reviews sind auf unterschiedliche Schwachstellentypen spezialisiert. Programme können SAST kontinuierlich auf jedem Commit laufen lassen und KI-basiertes Review für die Reasoning-lastigen Prüfungen reservieren, etwa Schwachstellen in der Geschäftslogik, die ein Scanner strukturell nicht erkennen kann.
Weiterführende Ressourcen
Weitere Inhalte
Alle Blogbeiträge anzeigen
Feedback erwünscht
Hat dir dieser Blogbeitrag gefallen? Hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab-Community-Forum und lass andere an deinen Eindrücken teilhaben.
Feedback teilen