Die nächste Ära der AppSec: Warum KI-generierter Code offensive dynamische Tests braucht

Mein Kollege Manoj Nair hat kürzlich über die wachsende Lücke zwischen dem, was KI entwickelt, und dem, was Sicherheitsteams tatsächlich testen geschrieben. Er argumentiert, dass die Geschwindigkeit KI-gestützter Entwicklung die Validierung grundlegend überholt hat und dass die Lösung nicht darin bestehen kann, die Entwicklung zu verlangsamen, sondern darin, die Bedeutung von Tests neu zu definieren. Ich stimme jedem Wort zu.

Ich möchte hier eine Ebene tiefer gehen. Den größten Teil eines Jahrzehnts habe ich damit verbracht, Engines für dynamische Sicherheitstests zu entwickeln. Zuerst bei Probely, das ich mitgegründet habe, und jetzt bei Snyk, wo unsere Technologie Snyk API & Web antreibt. Wenn ich also sage, dass sich die Sichtweise der Branche auf dynamische Sicherheitstests grundlegend ändern wird, stelle ich keine Marktprognose an. Ich beschreibe, was ich in den Architekturen sehe, die wir täglich testen.

Die Codeanalyse ist deutlich intelligenter geworden. Doch das reicht noch nicht.

Beginnen wir damit, anzuerkennen, was sie verdient: Die statische Analyse hat enorme Fortschritte gemacht.

Jahrelang steckte diese Kategorie in einer Ära starrer, störanfälliger Mustererkennung fest. Regelbasierte Engines erzeugten eine Vielzahl von Befunden, aber nur wenige aussagekräftige Ergebnisse.

Dann kam eine erste Welle aus maschinellem Lernen und symbolischer KI, die Datenflüsse über Codebasen hinweg detaillierter nachverfolgen konnte: Engines wie Snyk Code, unterstützt von DeepCode AI, brachten echtes semantisches Verständnis in die statische Analyse.

Und jetzt zeichnet sich eine wirklich neue Fähigkeit ab: agentische Tools, die semantische Schlussfolgerungen nutzen, um die tatsächliche Absicht des Codes zu verstehen, nicht nur seine Syntax. Diese Modelle können komplexe Fehler in der Geschäftslogik und Autorisierungsprobleme direkt im Quellcode erkennen – auf eine Weise, die vor fünf Jahren undenkbar gewesen wäre.

Das ist ein echter, bedeutender Fortschritt. Er ist sogar so groß, dass sich die Frage stellt, ob die Branche diese Technik weiterhin „SAST“ nennen oder einen völlig neuen Begriff dafür prägen wird.

Doch genau hier liegt der Punkt: Selbst die fortschrittlichste Codeanalyse-Engine hat eine Grenze: Sie kann nicht testen, was sie nicht ausführen kann.

Moderne Anwendungen sind keine Monolithen. Sie bestehen aus stark verteilten, zusammengesetzten, mehrschichtigen Umgebungen: Single-Page-Anwendungen kommunizieren mit Dutzenden von Backend-Microservices, von denen jeder einen eigenen Authentifizierungskontext, eigene Datenzugriffsmuster und einen eigenen Deployment-Lebenszyklus hat. Ein ausgefeilter Code-Scanner erkennt vielleicht erfolgreich einen Autorisierungsfehler in der Codebasis eines einzelnen Microservice. Doch was, wenn die Schwachstelle erst im Zusammenspiel mehrerer Komponenten auftritt?

Ein konkretes Beispiel: Ein Autorisierungsproblem tritt nur auf, weil eine Frontend-Anwendung ein Token auf eine bestimmte Weise verarbeitet, ein API-Gateway die Anfrage entsprechend weiterleitet und ein nachgelagerter Backend-Service die Rolle des Benutzers auf eine bestimmte Weise interpretiert. Keine einzelne Codebasis enthält die Schwachstelle. Sie entsteht durch das Zusammenspiel. Statische Analysen haben Schwierigkeiten, den Zustand zwischen Komponenten über verschiedene Codebasen hinweg zu erfassen – ganz gleich, wie intelligent sie sind –, denn sie können das System grundsätzlich nicht als Ganzes beobachten.

Genau das können dynamische Sicherheitstests leisten. Sie können in einer Live-Umgebung prüfen, ob ein Angreifer ein System tatsächlich ausnutzen kann, wenn all diese unterschiedlichen Komponenten miteinander verbunden sind.

Dieser blinde Fleck bei der Ausführung betrifft direkt auch die neue Entwicklung, die Manoj beschrieben hat: KI-Agenten, die autonom und in großem Umfang APIs aufrufen – auf eine Weise, die ihre Entwickler nie vorhergesehen haben. Risiken wie Prompt-Injection, Goal-Hijacking und Context-Poisoning sind nicht im Quellcode zu finden. Es handelt sich um emergentes Verhalten, das nur zur Laufzeit auftritt. Genau wie bei komplexen Interaktionen zwischen Microservices lassen sich diese Bedrohungen nur durch dynamische Interaktion mit dem Live-System überprüfen.

Die Konvergenz, die niemand benennt

Auf dem Markt passiert noch etwas, dem meiner Meinung nach mehr direkte Aufmerksamkeit gebührt.

Im vergangenen Jahr ist eine neue Bezeichnung aufgekommen: „AI Pentester“. Diese Bezeichnung trifft etwas Reales, denn die Tools stehen für einen echten Wandel im Ansatz. Statt eines starren Scanners, der statische Payloads an jede gefundene Eingabe sendet, kann diese neue Tool-Generation den Zustand der Anwendung analysieren und kontextabhängig die nächsten Schritte festlegen – ähnlich wie ein menschlicher Sicherheitsforscher.

Doch hier ist meine Beobachtung – und meiner Meinung nach liegt der Markt damit falsch: Diese Ansätze ergänzen sich grundlegend, statt miteinander zu konkurrieren.

Vor Kurzem haben wir eine bewusst verwundbare Anwendung sowohl mit einer herkömmlichen Engine für dynamische Sicherheitstests als auch mit einem eigenständigen, KI-gestützten Pentesting-Ansatz getestet. Die Ergebnisse waren aufschlussreich.

Die Engine für dynamische Sicherheitstests fand Schwachstellen, die der KI-gestützte Ansatz übersah. Der Grund: Herkömmliche Engines sind auf konsequente, systematische Vollständigkeit ausgelegt. Sie testen methodisch jeden Parameter, jeden Endpunkt und jeden Grenzfall.

Der KI-gestützte Ansatz fand hingegen komplexe Logikfehler, die die herkömmliche Engine nicht erfassen konnte. Er konnte Autorisierungsketten und Geschäftslogik auf eine Weise analysieren, die einem deterministischen Scanner nicht möglich ist.

Keiner der beiden Ansätze reichte allein aus. Zusammen ergaben sie ein deutlich vollständigeres Bild.

Daran wird für mich deutlich, dass die Branche auf eine Konvergenz zusteuert. Das Produkt der Zukunft in dieser Kategorie wird wahrscheinlich beide Fähigkeiten vereinen: einen umfassenden Modus für eine lückenlose Abdeckung in der Pipeline, wie ihn Unternehmen für kontinuierliche Absicherung benötigen, und einen gezielten, kontextgesteuerten Modus für tiefgreifende, logikbasierte Ausnutzung – um Autorisierungsfehler und verkettete Schwachstellen aufzudecken, die KI-generierter Code in großem Umfang mit sich bringt.

Wie genau diese Kategorie heißen wird – ob sich der Markt an „DAST“ hält, zu „AI Pentesting“ wechselt oder etwas völlig Neues erfindet –, ist noch offen. Die Konvergenz selbst scheint jedoch unvermeidlich.

Wie es weitergeht

Wenn ich den wichtigsten bevorstehenden Architekturwandel beschreiben müsste, würde ich sagen: Code-Intelligenz und dynamische Sicherheitstests werden immer stärker miteinander verwoben.

Während des größten Teils seiner Geschichte funktionierte dynamisches Sicherheitstesten wie eine Blackbox: ohne Kenntnis des Quellcodes und ohne Verständnis der internen Logik der Anwendung. Es prüfte das System von außen und meldete seine Ergebnisse. Das war zugleich seine Stärke – es testete die Realität, nicht die Theorie – und seine Einschränkung: Es übersah Kontext, der die Tests deutlich wirksamer machen könnte.

Das ändert sich. Mit der Weiterentwicklung von Plattformen geht der natürliche Trend hin zu dem, was Sicherheitsforscher seit jeher „Grey-Box“-Tests nennen: ein Ansatz, der gleichzeitig mit der Live-Anwendung interagiert und den zugrunde liegenden Quellcode versteht. In die eine Richtung kann die Codeanalyse versteckte Endpunkte oder Logikfehler vermuten, die dynamische Sicherheitstests anschließend in der Live-Umgebung bestätigen oder widerlegen. In die andere Richtung – und das entspricht eher der Arbeitsweise herausragender menschlicher Hacker – können dynamische Sicherheitstests verdächtiges Verhalten beobachten, während Anwendungen oder APIs live sind, und anschließend den Code-Kontext nutzen, um genau zu verstehen, wie ein Schutzmechanismus umgesetzt wurde. So lässt sich die präzise erforderliche Payload erstellen, statt blind alles durchzuprobieren.

Damit lässt sich auch eine der größten historischen Hürden dynamischer Sicherheitstests angehen: die Behebung von Schwachstellen. Ein dynamisches Tool konnte zwar stets anhand des schädlichen HTTP-Requests und der HTTP-Response sowie eines Ausnutzungsnachweises belegen, dass ein Exploit möglich war. Entwickler mussten jedoch selbst herausfinden, wo genau im Code die Schwachstelle ihren Ursprung hatte. Werden der dynamische Nachweis und der Code-Kontext miteinander verknüpft, entsteht etwas weitaus Leistungsfähigeres: ein Befund, der die Ausnutzbarkeit zur Laufzeit belegt und direkt auf den zu korrigierenden Code verweist.

Diese Entwicklung lohnt es sich zu beobachten. Nicht, weil sie bereits von einem einzelnen Anbieter vollständig umgesetzt wurde (auch wenn wir das geschafft haben), sondern weil die architektonischen Voraussetzungen geschaffen werden. Teams, die diese Konvergenz früh erkennen, werden die widerstandsfähigsten Sicherheitsprogramme aufbauen.

Die Überzeugung eines Entwicklers

Zum Schluss möchte ich eine Erkenntnis teilen, von der ich mit jeder getesteten Architektur mehr überzeugt bin.

Die Zeit, in der dynamische Sicherheitstests als Compliance-Pflichtübung galten – mit langsamen, störanfälligen Scannern, die vierteljährlich ausgeführt und deren Ergebnisse abgelegt wurden –, neigt sich dem Ende zu. Nicht, weil die Idee falsch war, sondern weil sich das Umfeld verändert hat.

KI-generierter Code wird schneller ausgeliefert, als jeder menschliche Prozess ihn überprüfen könnte. KI-Agenten rufen APIs schneller auf, als sich jedes Inventar erfassen ließe. Und die Schwachstellen, die diese Kräfte mit sich bringen – etwa fehlerhafte Autorisierung, Fehler in der Geschäftslogik und Zustandsfehler zwischen Komponenten –, gehören genau zu den Schwachstellen, die sich nur mit dynamischen Sicherheitstests eindeutig nachweisen lassen.

Was sich abzeichnet, ist kein Ersatz für Codeanalysen, sondern die zweite Hälfte der Gleichung: Codeanalysen zeigen, was möglicherweise verwundbar ist. Dynamische Sicherheitstests zeigen, was sich ausnutzen lässt. Treffen diese beiden Signale aufeinander, nimmt das Rauschen ab und das Signal wird klarer … Entwickler können mit Zuversicht statt mit Sorge ausliefern.

Wenn Sie ein Sicherheitsprogramm für das KI-Zeitalter aufbauen, ist diese Zuversicht die Investition wert.