Continuous Offensive Security: Eine Linie, die wir seit Jahren verfolgen

KI-Pentesting erlebt gerade einen Aufschwung.

Genauer gesagt: gleich mehrere. Kaum ist eine Woche vergangen, kündigt schon wieder ein Anbieter etwas an oder ein LLM-gestütztes Pentesting-Tool erzielt Spitzenwerte in einem Benchmark für ein Ziel, von dem noch niemand gehört hat. Ein anderes Deck verkündet, endlich den „neuen Goldstandard“ auf den Kopf zu stellen … Es ist einiges los.

Hinter all dem Trubel steckt jedoch ein echter Grund dafür, dass das gerade überall gleichzeitig passiert: Dieselbe Fähigkeit zum Schlussfolgern, die KI-Pentesting erst kommerziell nutzbar gemacht hat, steht jetzt auch Angreifern zur Verfügung. Autonome Angreifer untersuchen bereits kontinuierlich Anwendungsoberflächen – in Maschinengeschwindigkeit und nach einem Zeitplan, mit dem Verteidiger nicht mithalten können.

Entscheidend ist jetzt, ob Ihre Offensive-Security-Tests Schwachstellen finden, bevor die offensive KI eines Angreifers sie entdeckt. Die Ankündigungen der Anbieter sind nicht die eigentliche Geschichte: Der Markt holt lediglich zu einem Problem auf, das längst Realität ist.

Ich arbeite seit mehreren Jahren an Snyk API & Web, unserem Produkt für dynamische Sicherheitstests. Deshalb freut es mich, dass Snyk Continuous Offensive Security ankündigt. Mit diesem Beitrag möchte ich mehr tun, als die Ankündigung zu wiederholen: Ich möchte erklären, warum wir den Weg von dynamischen Sicherheitstests zu KI-Pentesting schon seit Jahren gehen – und warum meiner ehrlichen Meinung nach alle, die das Zweite ohne solides Fundament im Ersten aufbauen wollen, schnell an ihre Grenzen stoßen werden.

Heuristisch erkennbare vs. kontextabhängige Schwachstellen

Hier liegt der grundlegende Unterschied, der für unser gesamtes Argument entscheidend ist.

Heuristisch erkennbare Schwachstellen lassen sich von deterministischen Tools aufspüren. SAST gleicht Muster direkt im Quellcode ab. DAST geht anders vor: Es sendet Payloads an eine laufende Anwendung oder API und beobachtet die Antworten – Fehlermeldungen, Zeitverzögerungen, Verhaltensunterschiede und Ähnliches. Testen, beobachten, Schlussfolgerungen ziehen. SQL-Injection, Cross-Site-Scripting, falsch verwendete APIs und klassische Injection-Muster: All das lässt sich zuverlässig anhand von Verhaltensheuristiken erkennen. Scanner und DAST-Tools sind darin im Lauf der Jahre sehr gut geworden. Hunderte Schwachstellenklassen dieser Kategorie werden heute zuverlässig über den gesamten SDLC hinweg erkannt – ein echter Fortschritt. 

Kontextabhängige Schwachstellen sind etwas ganz anderes. BOLA oder IDOR, mandantenübergreifende Datenlecks, Authentifizierungsumgehungen und insbesondere verkettete Schwachstellen, bei denen mehrere mittelschwere und schwerwiegende Schwachstellen zusammen einen kritischen Angriffsweg bilden. Für keine davon gibt es eine heuristische Signatur, nach der man suchen könnte. Sie können weder in SAST noch in DAST eine Regel für „Benutzer A darf die Rechnung von Benutzer B nicht lesen“ schreiben. Eine solche Regel hängt davon ab, was Ihre Anwendung tun SOLL. Die Schwachstelle liegt in der Lücke zwischen dem beabsichtigten und dem tatsächlichen Verhalten. Es gibt keine Probe, keine Payload und keine Signatur, mit der sich die Absicht von außen erkennen ließe.

Deshalb wurde Pentesting schon immer von Menschen durchgeführt. Bis vor Kurzem konnten nur Menschen das nötige Kontextverständnis aufbauen, um diese zweite Kategorie zu finden. Heuristiken erkennen Signaturen oder Verhaltensweisen, Pentester finden, was sich nur im Kontext zeigt. So einprägsam das klingt: Das ist kein Slogan, sondern beschreibt, wie diese Disziplin seit jeher funktioniert.

Und genau diese Grenze hat KI gerade überschritten.

Die Entwicklungsgeschichte, die wirklich zählt

Hier ist das offene Geheimnis der Branche: Jede glaubwürdige DAST-Engine des letzten Jahrzehnts wurde von Menschen entwickelt, die aus dem Pentesting kamen. Die Engine von Snyk API & Web war da keine Ausnahme. Das Team, das sie entwickelt hat, suchte jahrelang manuell nach Schwachstellen und richtete sie danach aus, wie Pentester tatsächlich arbeiten: Aufklärung, Tests, Beobachten, Schlussfolgern, Eskalieren, Validieren … der gesamte Ablauf. Damals konnten wir allerdings noch nicht alles nachbilden, was Pentester tun. Es fehlte die Fähigkeit zum Schlussfolgern – genau das können wir jetzt, da LLMs Kontext verstehen und Schlussfolgerungen ziehen können.

Diese Erfahrung ist der Grund, warum unsere BOLA-Erkennung, die wir letztes Jahr eingeführt haben, so funktioniert, wie sie funktioniert. Sie gleicht keine Muster mit einer Liste von Signaturen ab, denn für BOLA gibt es keine Signatur. Stattdessen nutzt sie eine Kette von Autorisierungstests, die sich an strukturellen Überlegungen dazu orientiert, wie API-Objekte mit Identitäten verknüpft sind. Die automatisierte Schwachstellensuche überschreitet die Grenze von „Was macht der Code?“ hin zu „Was soll er tun, und kann ich diese Absicht unterlaufen?“

Seit Monaten läuft das bei unseren Kunden in der Produktion. Es beweist, dass der Weg von DAST zu schlussfolgerungsbasierten Tests gangbar ist. Und es ist kein Zufall, dass wir schon lange darüber nachgedacht haben, eine KI-Version davon zu entwickeln – lange bevor „KI-Pentesting“ zu einer Kategorie wurde, für die Investitionen eingesammelt wurden.

Was sich geändert hat – und warum gerade jetzt

Geändert hat sich nicht das Ziel, sondern die Kosten.

Schlussfolgern in großem Maßstab erforderte früher menschliche Pentester. 20.000 bis 50.000 US-Dollar pro Auftrag. Im Durchschnitt zwei Wochen. Und ein Abdeckungszeitraum, der mit der Auslieferung des Berichts endete – zu diesem Zeitpunkt waren bereits drei weitere Releases der Anwendung erschienen.

Das waren die Rahmenbedingungen manueller Pentests: unersetzlich, aber durch denselben Faktor eingeschränkt wie jedes Handwerk – die verfügbare Zeit von Menschen. Ihr Pentest deckt fünfzehn Tage im Jahr ab. Was passiert an den übrigen dreihundertfünfzig?

KI verändert die Wirtschaftlichkeit, nicht aber die Disziplin. Der Schritt des Schlussfolgerns, den bisher nur ein Pentester ausführen konnte, lässt sich jetzt auch von einem hinreichend leistungsfähigen Modell zuverlässig und zu einem Bruchteil der Kosten wiederholt durchführen.

Und es gibt eine dritte Angriffsfläche, die KI selbst geschaffen hat

Alles bisher Beschriebene betrifft eine Angriffsfläche, die es schon so lange gibt wie Webanwendungen: die heuristisch erkennbaren und kontextabhängigen Schwachstellen in traditionellem Code, herkömmlichen APIs und klassischen Architekturen. KI verändert das Testmodell, aber nicht die Ziele: Diese werden seit zwei Jahrzehnten bei Pentests untersucht.

Daneben gibt es eine völlig neue Angriffsfläche, die KI selbst geschaffen hat und die es vor gerade einmal fünf Jahren noch nicht gab.

Anwendungen mit integrierten LLMs, KI-Agents, die Tools aufrufen, Chatbots mit Zugriff auf Kundendaten. Retrieval-Pipelines, die Daten aus Quellen abrufen, die Angreifer vergiften, für Prompt-Injection-Angriffe missbrauchen oder anderweitig ausnutzen können. Datenexfiltration über Modellausgaben oder Jailbreaks, die einen Kundendienst-Agent in einen privilegierten Akteur verwandeln – mit Zugriffen, die er niemals haben sollte. Manojs Beitrag beschreibt ein Beispiel dafür: Ein KI-Agent rief eine API auf, die niemand einem Stresstest unterzogen hatte – ausgelöst durch nichts Exotischeres als eine E-Mail-Adresse.

Nach diesen Angriffen können Sie nicht einfach scannen, und sie sind im herkömmlichen architektonischen Sinn keine Schwachstellen. Sie liegen in der Lücke zwischen dem, wozu ein LLM aufgefordert wurde, und dem, wozu ein Angreifer es überreden kann. Um sie zu finden, müssen Sie gegen die LLM-integrierte Ebene genauso vorgehen wie ein Angreifer: testen, eskalieren, Daten exfiltrieren, missbrauchen.

Das ist die dritte Funktion von Continuous Offensive Security: Agent Red Teaming. Mehrstufige adversariale Simulationen gegen LLMs, KI-Agents und die Tools, die sie aufrufen. Ein speziell für die Angriffsfläche entwickeltes Tool, die KI selbst geschaffen hat.

Was mir an der Umsetzung besonders gefällt: Es ist kein separater Scan, den Sie planen müssen, und auch kein zusätzliches Produkt, das Sie kaufen müssen. Während einer Prüfung erkennt der Aufklärungs-Agent, ob das Ziel integrierte LLM-Komponenten enthält. Ist das der Fall, wird das Red-Teaming-Modul automatisch gestartet. Sie müssen nicht im Voraus wissen, welche Art von Angriffsfläche Ihre Anwendung bietet. Das System findet es heraus und führt die passenden Tests auf der richtigen Ebene aus.

Das ist wichtiger, als es zunächst klingt. Inzwischen setzen die meisten Unternehmen irgendwo in ihrem Anwendungsportfolio KI ein, doch ihre Sicherheitsteams haben keinen vollständigen Überblick darüber, wo. Erst aufklären, dann das Gefundene testen – nur mit diesem Modell lässt sich skalieren, wenn „Wo läuft KI in der Produktion?“ ein Ziel ist, das sich ständig verändert.

Das ist also die Angriffsfläche: Schwachstellen in herkömmlichen Architekturen und das neue Terrain, das KI darauf geschaffen hat. Schwieriger ist die Frage, was es tatsächlich braucht, um beide kontinuierlich und im Maßstab eines Unternehmens mit offensiven Tests abzusichern. Ein LLM auf eine Ziel-URL anzusetzen und es einfach machen zu lassen, ist nicht die Antwort. Vier Faktoren unterscheiden diesen Ansatz davon, im Blindflug zu testen.

Plattformkontext

Der naive Ansatz für KI-Pentesting beginnt ganz von vorn. Sie geben dem LLM eine URL, lassen es die Website durchforsten, Vermutungen anstellen und Rechenleistung für irrelevante Aufzählungen verbrauchen – in der Hoffnung, dass es irgendwann etwas findet. Schlimmer noch: Das Modell kann einen theoretischen Fund nicht von einer Schwachstelle unterscheiden, die in Ihrem Stack tatsächlich ausnutzbar ist. Denn es sieht weder Ihren Code noch Ihre Abhängigkeiten, früheren Scans, Ihre Bereitstellungsumgebung oder Vertrauensgrenzen. Das mag sich für eine Demo eignen, aber nicht für Sicherheitstests auf Produktionsniveau.

Bei Snyk sieht das anders aus. Continuous Offensive Security nutzt zunächst alles, was die Plattform bereits über Ihre Anwendung weiß: SAST-Ergebnisse, SCA-Abhängigkeiten, Asset-Inventare, frühere DAST-Scans und Risikosignale aus der gesamten Plattform. All diese Informationen erhält der KI-Pentester, bevor er auch nur eine einzige Anfrage sendet.

Das verändert vom ersten Tag an, was die KI tut. Statt „Finde heraus, was diese Anwendung ist, und suche nach Schwachstellen,“ lautet die Anweisung nun: „Diese Anwendung hat die folgenden Komponenten, Abhängigkeiten, früheren Ergebnisse und erreichbaren Endpunkte sowie dieses Risikoprofil. Suche jetzt nach allem, was noch nicht abgedeckt ist.“ Das LLM rät nicht mehr, sondern legt los.

Direkt aus unserer Ankündigung von dieser Woche: „Snyk unterscheidet sich, weil wir Ihren Code bereits kennen.“ In sieben Worten erklärt das die Vorteile unserer Plattform. Alle anderen KI-Pentest-Tools fangen bei null an. Wir setzen dort an, wo Ihre bestehenden Tools aufgehört haben.

Genau deshalb glaube ich nicht, dass reine Point-Solutions in dieser Kategorie langfristig bestehen können: Diese Ebene lässt sich nicht einfach an ein neues Produkt anbauen. Dafür braucht es einen über ein Jahrzehnt gewachsenen Kontext, gespeist von Engines, die bei echten Kunden echte Schwachstellen aufspüren.

Hybride dynamische Tests und LLM-Erkennung

Das ist der technische Punkt, den die meisten Neueinsteiger übergehen. Ich glaube, viele von ihnen werden daran scheitern, wenn ihre Finanzierungsreichweite und Token-Rechnungen aufeinandertreffen.

Der abermals naive Ansatz für KI-Pentesting lautet: ein reines LLM, das auf das Ziel angesetzt wird und alles selbst herausfinden soll. In Demos funktioniert das, wirtschaftlich tragfähig ist es jedoch nicht.

Jede Payload, die ein LLM gegen einen XSS-Endpunkt ausprobiert, kostet Tokens. Jeder Parameter, der durch Brute Force getestet wird, jede Variation, jeder erneute Versuch? Tokens, Tokens, Tokens. Dynamische Tests erledigen beides umfassend und deterministisch – für ein paar Cent. Frontier-Modell-Tokens für einen Katalog bekannter Bugs zu verbrauchen: So sieht „mit negativen Margen subventioniert“ aus. Anbieter, die heute auf diese Strategie setzen, werden spätestens dann erfahren, was Stückkosten bedeuten, wenn sie profitabel sein müssen.

Architektonisch sinnvoll ist nicht, zwei Ebenen parallel arbeiten zu lassen, sondern ein LLM als Denkzentrum der Prüfung einzusetzen, mit dynamischen Tests als einem der verfügbaren Werkzeuge. Wenn XSS, SQL-Injection oder Fehlkonfigurationen geprüft werden müssen, zählt das LLM nicht selbst Payloads auf. Stattdessen ruft es dynamische Tests auf, die genau das schon seit Jahren umfassend und deterministisch für ein paar Cent erledigen.

So kann das LLM seine Tokens dort einsetzen, wo nur ein LLM sie einsetzen kann: um über Geschäftslogik nachzudenken, Autorisierungsfehler aufzuspüren und einzelne Erkenntnisse zu tatsächlichen Exploit-Pfaden zu verknüpfen. Darauf entfällt der Großteil des Rechenaufwands. Das bekannte Terrain wird deterministisch weiter untersucht, während die Reasoning-Oberfläche die Rechenleistung erhält, die sie verdient.

Diese Architektur war von Anfang an vorgesehen – sie ist kein Ziel, auf das wir hinarbeiten. Deshalb ist es meiner Ansicht nach deutlich schwieriger, das Ganze ohne eine Dynamic-Security-Testing-Engine im Kern zu entwickeln, als es von außen betrachtet scheint.

Angriffsszenarien statt Alert-Listen

Ein herkömmlicher Scanner liefert eine Liste von Schwachstellen, nach Schweregrad sortiert und mit Stacktraces oder HTTP-Anfragen versehen. Sicherheitsteams ertrinken seit Jahren in solchen Listen. CVSS 9,8 neben CVSS 9,6 neben CVSS 9,4 … und irgendwo dazwischen ein tatsächlich ausnutzbarer Pfad, der zwei davon mit einem dritten Fund mit niedrigem Schweregrad kombiniert, den das Team vor Monaten aussortiert hat.

Die zuvor beschriebenen kontextabhängigen Schwachstellen treten fast nie als eigenständige Funde auf. Sie erscheinen als Kombinationen: eine Lücke bei der Autorisierung an einem Endpunkt, ein Logikfehler bei der Vergabe von Kennungen durch die API und eine veraltete Sitzung, die der Bereinigungsjob übersehen hat. Für sich genommen wirken diese drei Funde unspektakulär. In Kombination können sie jedoch zu einem Datendiebstahl führen.

Continuous Offensive Security liefert Funde nicht als Liste, sondern als Exploit-Ketten: den konkreten Pfad vom Erstzugriff bis zur Auswirkung, belegt durch den Verlauf von Anfragen und Antworten. Alles ist reproduzierbar und auditierbar. Statt einer 400-zeiligen Tabelle, die jemand an einem Freitagnachmittag durchgehen muss, erhalten Sie eine Darstellung dessen, was Angreifer mit dieser Anwendung tatsächlich tun könnten.

Colleen Carroll, Senior Director und Information Security Officer bei Emburse, brachte diesen Punkt aus Kundensicht in unserer Ankündigung auf den Punkt:

„Sicherheitsteams suchen nach Lösungen, die ihnen helfen, echte Risiken zu priorisieren, statt einfach nur noch mehr Alerts zu verwalten. Snyks Continuous Offensive Security verschafft Teams einen klareren Überblick über ausnutzbare Schwachstellen und deren Verknüpfungen. So können sie schneller handeln, das Risiko reduzieren und Innovationen mit Zuversicht vorantreiben.“

Das ist der Unterschied zwischen „Das haben wir gefunden“ und „So lässt sich das gegen Sie ausnutzen“.

Enterprise-KI-Harness

Der Teil, der ernsthafte Entwicklungsarbeit erfordert und es fast nie in die Schlagzeilen schafft, ist der verantwortungsvolle Einsatz von KI-Agenten in Systemen, die nur einen Netzwerksprung von der Produktionsumgebung entfernt sind.

Governance, Durchsetzung des Testumfangs, persistenter Kontext bei lang laufenden Vorgängen und Reproduzierbarkeit, damit sich ein Fund validieren und erneut untersuchen lässt. Reasoning-Traces, damit ein Sicherheitsteam nachvollziehen kann, wie eine Schlussfolgerung zustande kam. Die gesamte Ebene, die aus „ein LLM probiert etwas aus“ etwas macht, das ein Enterprise-Sicherheitsteam tatsächlich gegen eine Anwendung einsetzen wird.

Wir nennen es das AI Security Harness. Es ist der Teil von Continuous Offensive Security, der unter der Oberfläche liegt. Und genau hier steckt der größte Teil der eigentlichen Herausforderung. Auch hier kommt es auf die Erfahrung an. Diese Ebene zu entwickeln, ist schwieriger, als die darauf aufbauende KI zu entwickeln. Unternehmen, die seit Jahren Penetrationstests und Dynamic Security Testing im Enterprise-Maßstab durchführen, haben gegenüber denen, die jetzt erst einsteigen, einen erheblichen Vorsprung.

Hier haben wir auch eine bewusste Architekturentscheidung getroffen, die sich nicht ohne Weiteres nachbilden lässt: Continuous Offensive Security basiert nicht auf einem einzelnen Frontier-Modell. Das AI Security Harness orchestriert mehrere führende Modelle, Modelle auf Defender-Niveau sowie weitere offene und proprietäre Modelle, die im Laufe der Zeit abgestimmt wurden. Für uns ist das eine grundlegende Architekturentscheidung darüber, wie ein KI-System für Unternehmen aufgebaut sein sollte.

Continuous Offensive Security setzt ein System für offensive Sicherheit mit mehreren Modellen ein, das speziell für Penetrationstests in Unternehmen entwickelt wurde. Frontier-Modelle führen die Prüfungen im offensiven Harness von Snyk durch. Ein dediziertes Validierungsmodell fungiert als unabhängige Instanz und bestätigt die Ausnutzbarkeit, bevor ein Fund angezeigt wird. Und die Plattformintelligenz von Snyk verankert jeden Angriff im realen Anwendungskontext. So entsteht ein System, das auf Präzision statt auf Rauschen ausgelegt ist.

Was das bedeutet

Gabriel Brolo, Staff Security Engineer bei Yalo, hat es kürzlich klarer formuliert, als ich es könnte:

„Umfang und Tempo KI-generierten Codes haben das Pentesting-Modell, mit dem die meisten von uns seit Jahren arbeiten, grundlegend überholt. Wir können eine kontinuierliche Risikofläche nicht durch immer mehr geplante Tests beherrschen. Wir brauchen offensive Tests, die mit der heutigen Softwareentwicklung Schritt halten – mit genügend Kontext, um sich auf tatsächlich ausnutzbare Schwachstellen zu konzentrieren und nicht nur auf theoretisch mögliche. Solche Fähigkeiten geben Teams die Möglichkeit, ihre Bedrohungslandschaft und tatsächlichen Risiken besser zu verstehen und gezielter zu minimieren.“

Für Kundinnen und Kunden von Snyk API & Web ist Continuous Offensive Security kein separates Produkt, das zusätzlich erworben werden muss. Es ist vielmehr die nächste Ebene desselben externen Testpfads, den Ihr Dynamic Security Testing bereits abdeckt. Der Scanner erkennt heuristisch erkennbare Probleme, die KI deckt kontextabhängige Probleme ab und Red Teaming prüft die KI-spezifische Angriffsfläche, sobald die Reconnaissance ein LLM im Stack entdeckt. Derselbe Sicherheitsansatz, ausgeweitet auf die tatsächliche Zusammensetzung Ihrer Anwendungen von heute.

Für den Markt lautet die Frage nicht mehr „Brauchen Sie KI-Pentests?“ (und nun ja, wir glauben, dass Sie sie brauchen), sondern „Für welchen Anbieter von KI-Pentests sollte ich mich entscheiden?“

Da wir Continuous Offensive Security diese Woche endlich ankündigen, ist es unser Ziel, dass Kunden, die heute KI-Pentesting-Lösungen bewerten, Optionen abwägen, Demos besuchen und herausfinden möchten, wem sie vertrauen können, wissen: Eine der Antworten kommt von denselben Menschen, die schon dabei waren, lange bevor es diesen Raum überhaupt gab.

Wenn Sie Manojs Beitrag zur Angriffsfläche verfolgen, die KI schafft und meinen vorherigen Artikel darüber lesen, wie sich dynamische Tests weiterentwickeln müssen, um Schritt zu halten, ist dies der dritte Teil – und die Verbindung ist klar erkennbar. Sie bestand schon immer, und wir haben die ganze Zeit darauf hingewiesen.

Auf der Black Hat erzählen wir Ihnen mehr. Wir freuen uns darauf, Sie dort zu treffen!