KI-generierter Code hat geändert, was SAST erfassen muss

Das Beobachten eines KI-Coding-Assistenten, der in Sekunden eine funktionierende Funktion produziert, kann sich wie ein Durchbruch anfühlen. Der Code compiliert. Die Tests bestehen. Der Pull-Request sieht sauber aus. Für Entwicklungsteams, die unter Druck stehen, schneller zu liefern, fühlt sich das wie Fortschritt an.

Aber funktionsfähiger Code und sicherer Code sind nicht dasselbe.

KI-generierter Code hat die Form des Software-Risikos geändert. Das Problem ist nicht einfach, dass große Sprachmodelle “schlechten” Code schreiben. In vielen Fällen schreiben sie Code, der poliert aussieht, einem vertrauten Framework-Muster folgt und die angeforderte Aufgabe löst. Das Problem ist subtiler: Code kann funktional korrekt sein und dennoch unsicher, veraltet, überberechtigt oder kontextuell falsch sein.

Diese Unterscheidung ist wichtig, weil die statische Anwendungssicherheitstestung (SAST) für eine Welt entwickelt wurde, in der Entwickler Code mit menschlicher Geschwindigkeit schrieben und Sicherheitsteams vorhersehbare Risikomuster überprüften. KI hat beide Seiten dieser Gleichung geändert. Die Code-Menge steigt, Commits werden kleiner und unsichere Muster können jetzt im großen Maßstab generiert werden.

Das Ergebnis ist eine neue Frage für Software-Teams: Was sollte SAST erfassen, wenn der Autor des Codes nicht unbedingt menschlich ist?

Funktionierender Code ist kein starkes Signal mehr

Jahrelang verwendeten Software-Teams eine grobe Hierarchie der Zuversicht. Wenn Code compilierte, Tests bestand und eine Peer-Review überstand, rückte er näher an die Produktion heran. Sicherheitsscans fügten eine weitere Schicht hinzu, aber Funktionalität blieb das erste Tor.

KI-Coding-Assistenten stören diese Hierarchie, weil sie besonders gut darin sind, Code zu produzieren, der vollständig aussieht. Sie können Boilerplate inferieren, APIs verbinden, Fehlerbehandlung generieren und den Stil eines bestehenden Repositorys matchen. Dies macht sie nützlich, aber es macht ihre Fehler auch schwerer zu erkennen.

Ein menschlicher Reviewer kann einen KI-geschriebenen Funktion überfliegen und denken: “Das sieht normal aus.” Genau das ist das Risiko. Viele KI-generierte Schwachstellen sind nicht exotisch. Sie sind vertraute Probleme wie Injection-Schwachstellen, schwache Validierung, unsichere Standardwerte, unsichere Deserialisierung, Logging-Probleme und veraltete Abhängigkeitsauswahlen.

Jüngste Forschungsergebnisse haben diesen Konflikt noch schwerer zu ignorieren gemacht. Veracodes Spring 2026 GenAI Code Security Update zum Beispiel fand heraus, dass KI-Coding-Modelle viel stärker darin geworden waren, syntaktisch korrekten Code zu produzieren als sicheren Code. Mit anderen Worten: KI wird sehr gut darin, Software zu schreiben, die funktioniert, aber das bedeutet nicht, dass sie gleichzeitig gut darin wird, Software zu schreiben, die vertrauenswürdig ist.

Die Ausgabe sieht produktionssicher aus, aber das zugrunde liegende Risiko kann ganz anders sein.

Das alte SAST-Modell wurde für menschliche Engpässe entwickelt

Traditionelle SAST hatte immer einen schwierigen Job. Sie scannen Quellcode, ordnen Muster bekannten Schwachstellen zu und warnen Teams, bevor anfälliger Code ausgeliefert wird. In einem konventionellen Entwicklungszyklus erzeugt dies bereits Reibung: zu viele Warnungen, zu viele Falschpositivmeldungen und nicht genug Zeit, um alles zu beheben.

KI macht dies noch schwieriger, indem sie einen der versteckten Einschränkungen in der Softwareentwicklung entfernt: die Geschwindigkeit des menschlichen Tippens.

Wenn ein KI-Assistent eine Dienstleistung, eine Testdatei, eine API-Integration und eine Konfigurationszeile in einer Sitzung generieren kann, kann die Sicherheitsprüfung nicht auf denselben Annahmen vertrauen. Das Risiko ist nicht nur eine nachlässige Codezeile. Es ist die Multiplikation von plausiblen Code über Dutzende von Dateien, jede mit kleinen Entscheidungen, die das Modell im Namen des Teams getroffen hat.

Hier müssen moderne SAST-Tools evolvieren. Sie können nicht einfach nach bekannten Schwachstellen-Signaturen scannen, nachdem ein Pull-Request fast abgeschlossen ist. Sie müssen näher am Entwickler-Workflow arbeiten, KI-assistierte Änderungsmuster verstehen und Teams helfen, harmlose Automation von riskanter Automation zu trennen.

KI introduziert Sicherheitsverschuldung mit Maschinengeschwindigkeit

Technische Verschuldung ist nicht neu. Sicherheitsverschuldung ist die gefährlichere Cousine: Sie kumuliert, wenn Schwachstellen, schwache Annahmen und riskante Abkürzungen im Codebestand bleiben, weil sie nicht dringend genug sind, um sie heute zu beheben.

KI kann diesen Prozess beschleunigen.

Ein Entwickler kann einen Assistenten bitten, “Authentifizierung hinzufügen”, “Eingabe bereinigen” oder “diesen Endpunkt mit der Datenbank verbinden”. Das Modell wird normalerweise eine Antwort produzieren. Aber es sei denn, der Prompt enthält die richtigen Sicherheitsbeschränkungen, die Antwort kann auf veraltete Praktiken, unvollständige Validierung oder unsichere Standardwerte zurückgreifen. Schlimmer noch, sie kann gut genug sein, um eine lockere Überprüfung zu bestehen.

Es gibt mehrere KI-spezifische Muster, die SAST jetzt erkennen muss:

• Sicher aussehender Boilerplate: KI produziert oft Code, der wie Best Practice aussieht, aber eine wichtige Kontrolle vermisst, wie z.B. Autorisierungsprüfungen oder Ausgabeencoding.
• Veraltete Abhängigkeitsannahmen: Ein Modell kann Bibliotheken, Versionen oder APIs vorschlagen, die auf Mustern basieren, die in seinen Trainingsdaten gemeinsam waren, aber nicht mehr empfohlen werden.
• Kontextfreie Korrekturen: KI kann das lokale Symptom patchen, ohne den umfassenderen Anwendungsfluss zu verstehen, und damit Sicherheitslücken anderswo erzeugen.
• Wiederholte anfällige Vorlagen: Wenn der gleiche Prompt das gleiche fehlerhafte Muster in mehreren Repositorys produziert, kann eine Schwachstelle stillschweigend durch eine Organisation verbreitet werden.

Dies ist nicht nur darum, schlechten Code zu finden. Es geht darum, zu erkennen, wenn Code ohne genügend Kontext produziert wurde.

SAST muss Intent verstehen, nicht nur Syntax

Die nächste Generation von SAST muss über einfaches Mustererkennen hinausgehen. Bekannte Schwachstellenmuster sind immer noch wichtig, und viele grundlegende Fehler sollten automatisch erkannt werden. Aber KI-generierter Code erhöht die Latte, weil Syntax allein selten die ganze Geschichte erzählt.

Betrachten Sie einen Endpunkt, der Kundenunterlagen abruft. Der Code kann parameterisierte Abfragen verwenden, Fehler korrekt behandeln und Standard-Injection-Tests bestehen. Aber erzwingt er Mandanten-Trennung? Er überprüft, ob der aktuelle Benutzer berechtigt ist, auf das angeforderte Unterlagen zuzugreifen? Er loggt sensible Daten?

Diese Art von Änderung wirft auch eine Datenschutzfrage auf: Wenn KI-generierte Logik ändert, was die Anwendung speichert, loggt oder offenlegt, müssen Teams das App-Daten-Sammeln als Teil der Sicherheitsprüfung verstehen.

Diese sind nicht immer Syntaxprobleme. Sie sind Intent-Probleme.

SAST benötigt mehr Bewusstsein für Geschäftslogik, Datenfluss, Framework-Konventionen und die Beziehung zwischen einer Änderung und dem Rest der Anwendung. Das Ziel ist nicht, SAST “KI-gesteuert” für Marketingzwecke zu machen. Das Ziel ist, es kontextbewusst genug zu machen, um die Arten von Fehlern zu erfassen, die KI wahrscheinlich macht.

Entwickler müssen immer noch Sicherheit lernen, nur anders

Bessere Tools werden helfen, aber sie werden nicht die menschliche Verantwortung ersetzen. KI-Coding-Assistenten machen Entwickler produktiver, aber sie machen es auch einfacher für Teams, Code anzunehmen, den sie nicht vollständig verstehen.

Dies schafft eine Schulungsherausforderung. Traditionelle jährliche Sicherheitsschulungen sind zu langsam und zu abgekoppelt von der täglichen Arbeit. Entwickler benötigen kurze, praktische Lektionen, die nahe dem Moment geliefert werden, in dem sie Entscheidungen treffen. Dies ist der Punkt, an dem Microlearning relevant wird: kleine, fokussierte Lernmomente können sichere Codiergewohnheiten ohne die Ingenieure aus ihrem Workflow für Stunden zu entfernen, verstärken.

Die beste Sicherheitsschulung in der KI-Coding-Ära wird weniger wie ein Klassenzimmer und mehr wie eine gut getimte Erklärung innerhalb eines Pull-Requests, eine IDE-Warnung, die lehrt, anstatt zu nerven, oder eine kurze Behebungsnotiz, die erklärt, warum ein KI-generiertes Muster riskant ist.

Der Überprüfungsprozess muss geändert werden

Code-Überprüfung beantwortete früher vertraute Fragen: Ist der Code lesbar? Löst es das Problem? Bricht es etwas?

KI-generierter Code fügt neue Fragen hinzu. War der Prompt sicherheitsbewusst? Hat das Modell eine Abhängigkeit eingeführt? Hat es ein Muster aus einem anderen Teil des Repositorys kopiert, ohne zu verstehen, warum dieses Muster existierte? Hat der Entwickler die Logik oder nur die Ausgabe überprüft?

Dies bedeutet nicht, dass jeder KI-assistierte Commit eine forensische Untersuchung benötigt. Aber Teams benötigen einen leichten Weg, um hochriskante KI-generierte Änderungen zu identifizieren. Authentifizierung, Autorisierung, Kryptographie, Zahlungsflüsse, Datei-Uploads, Datenbankzugriff, Logging und Infrastrukturkonfiguration verdienen mehr Aufmerksamkeit als UI-Kopie oder Test-Scaffolding.

Das Wesentliche

KI macht SAST nicht irrelevant. Sie macht SAST wichtiger.

Wenn Code-Generierung schneller und tiefer in Entwicklungsumgebungen eingebettet wird, gilt die alte Annahme, dass unsicherer Code langsam durch menschliche Hände eingeht, nicht mehr. KI kann nützliche Software produzieren, aber sie kann auch schwache Muster, veraltete Annahmen und kontextfreie Korrekturen schneller generieren, als traditionelle Überprüfungsprozesse absorbieren können.

Die Gewinner werden nicht die Teams sein, die KI-Coding-Tools verbieten. Die Gewinner werden die Teams sein, die ihre Sicherheitsworkflows um die neue Realität herum neu entwerfen: Code kann sofort generiert werden, aber Vertrauen muss immer noch verdient werden.

SAST muss jetzt mehr als nur Syntax-Fehler erfassen. Es muss fehlenden Intent, unsicheren Kontext, wiederholte KI-Muster und Sicherheitsverschuldung vor ihrem Anwachsen erfassen.