KI entdeckt kritische Schwachstellen schneller, als Teams sie beheben können

In den vergangenen 90 Tagen haben wir autonome Pentests gegen verschiedene Produktionssysteme durchgeführt — und die Ergebnisse sind kaum zu ignorieren.
Moderne Anwendungen sind nicht nur verwundbar. Sie sind kontinuierlich verwundbar.
Das Problem ist nicht, dass teams nicht auf Sicherheit testen. Es ist, dass Angreifer inzwischen mit Maschinengeschwindigkeit arbeiten, während Tests und Behebung noch in menschlichen Zeitabläufen stattfinden.
Während KI die Entdeckung von Schwachstellen beschleunigt, schrumpft das Zeitfenster zwischen der Einführung eines Fehlers und seiner Ausnutzung. Wenn Tests und Behebungen nicht mit derselben Geschwindigkeit mithalten, wird diese Lücke zur Angriffsfläche.

Was wir in der Praxis sehen

Über 28 Unternehmen hinweg haben unsere Agenten Folgendes identifiziert:

• ~2000 Gesamt-Schwachstellen

• 44,6 % kritisch oder hochgradig schwerwiegend (829 Befunde)

• Durchschnittlich 21,6 Schwachstellen pro Scan (Median: 15)

• 65,1 % der Scans deckten mindestens ein kritisches Problem auf

• Spitze: 88 Schwachstellen in einem einzigen Scan

Das sind keine theoretischen Risiken. Jeder Befund wird mit einem funktionierenden Proof-of-Concept-Exploit validiert.
Fast die Hälfte aller von uns gefundenen Schwachstellen ist schwerwiegend, und die meisten Systeme haben mindestens ein kritisches Problem.
Was noch beunruhigender ist, ist die Art der Schwachstellen hinter diesen Zahlen. Es handelt sich nicht um einfache Fehlkonfigurationen oder veraltete Abhängigkeiten. Es sind tiefere Probleme darin, wie Anwendungen entworfen sind und sich verhalten.

Das sind keine einfachen Bugs

Die häufigsten Probleme, die wir sehen, sind Logikfehler.
Ein Logikfehler bedeutet, dass sich das System genau so verhält, wie es programmiert wurde, aber das Design selbst unsicher ist.
Das sind keine Konfigurationsfehler oder veralteten Bibliotheken. Es sind Fehler darin, wie die Anwendung tatsächlich funktioniert, wie Daten fließen, wie Berechtigungen durchgesetzt werden und wie Systeme einander vertrauen.

So sieht das in der Praxis aus:

• IDOR (Unsichere direkte Objektverweisung) — 177 Befunde
  Angreifer können auf Daten anderer Nutzer zugreifen oder sie verändern, indem sie einfach Kennungen ändern (z. B. Benutzer-IDs, Datei-IDs). Dadurch können sensible Daten in großem Umfang offengelegt oder sogar Kontoübernahmen ermöglicht werden.

• SSRF (Serverseitige Anforderungsfälschung) — 122 Befunde
  Angreifer können den Server dazu bringen, im eigenen Namen Anfragen zu senden, oft an interne Systeme. Dadurch können interne APIs, Cloud-Zugangsdaten oder Infrastruktur offengelegt werden, die niemals öffentlich erreichbar sein sollten.

• Fehlende Authentifizierung — 105 Befunde
  Sensible Endpunkte oder Aktionen sind ohne Anmeldung zugänglich. Das bedeutet, dass jeder im Internet kritische Funktionen auslösen oder auf geschützte Daten zugreifen kann.

Diese Schwachstellen sind besonders gefährlich, weil sie ausnutzen, wie sich die Anwendung verhält, nicht nur, wie sie konfiguriert ist.
Traditionelle Scanner tun sich hier schwer, weil sie Verhalten nicht verstehen. Sie suchen nach Signaturen, nicht nach Logik.

Warum KI mehr findet

Bis vor Kurzem erforderte das Finden und Ausnutzen solcher Schwachstellen Zeit, Können und manuelle Arbeit.
Das hat sich geändert.

KI-Agenten können jetzt mit Anwendungen so interagieren, wie es ein menschlicher Angreifer tun würde, aber in einer völlig anderen Größenordnung und Geschwindigkeit.
Sie scannen nicht nur Endpunkte, sie erkunden sie.

• Sie testen Randfälle

• Sie verketten mehrere Schritte miteinander

• Sie iterieren schnell durch Tausende von Möglichkeiten

Anstatt nach bekannten Problemen zu suchen, prüfen sie aktiv, wie sich eine Anwendung verhält, und suchen nach Wegen, sie zu brechen. Sie schlafen nie. Ihr Arbeitstag endet nie. Sie haben die Wissensbasis der Welt auswendig gelernt.
Dieser Wandel treibt die Ergebnisse an, die wir sehen: eine konsistente Entdeckung kritischer Probleme bei der Mehrheit der Scans.

Warum Open Source die Schwachstellenentdeckung beschleunigen kann

Open Source verändert, wie Schwachstellen entdeckt werden.
Stellen Sie sich vor, Sie knacken ein Schloss. Wenn Sie die inneren Mechanismen des Schlosses kennen, ist es viel einfacher, es zu knacken.
Wenn KI-Systeme Zugriff auf den Quellcode haben, können sie jeden Codepfad direkt analysieren, statt das Verhalten von außen abzuleiten.
In kontrollierten Benchmark-Tests mit der öffentlich verfügbaren XBow validation suite, erhöhte der Zugriff auf den Quellcode die Erkennung von Schwachstellen um ungefähr 20 % im Vergleich zu Black-Box-Tests.
Wir sehen diese Lücke auch in realen Szenarien.
Mit vollständiger Sichtbarkeit können KI-Agenten:

• Datenflüsse end-to-end nachverfolgen

• Fehlerhafte Annahmen in der Geschäftslogik identifizieren

• Randfälle wesentlich effizienter erkunden

Das macht Logikfehler erheblich leichter zu finden und auszunutzen.
Je mehr Anwendungen offen entwickelt werden und je besser KI-Systeme werden, desto weiter steigt die Geschwindigkeit der Schwachstellenerkennung.
Das heißt jedoch nicht, dass Closed Source automatisch sicher ist.
Sicherheit durch Verschleierung war nie eine echte Verteidigung. Ein entschlossener Angreifer mit genug Rechenleistung und genug Tokens zum Verbrauchen kann dennoch weiterhin enumerieren, fuzzing betreiben und schließlich ausnutzbare Pfade aufdecken, selbst ohne direkten Zugriff auf den Code.
Die Schlussfolgerung lautet also nicht, zwischen Open und Closed Source zu wählen. Es geht darum, anzupassen, wie Sie Systeme testen und absichern.
Unabhängig von der Architektur verfehlen traditionelle Punkt-in-Zeit-Bewertungen das Ziel. Codebasen entwickeln sich mit Maschinengeschwindigkeit, und ebenso die Angriffsflächen.

Das eigentliche Problem: mehr Geschwindigkeit = geringere Kosten

Vor ein paar Jahren erforderte das Finden und Ausnutzen von Schwachstellen Zeit, Können und Geduld.
Heute ist dieser Zeitrahmen zusammengebrochen.
KI-Systeme können:

• Tausende von Tests parallel ausführen

• Kontinuierlich neue Codepfade erkunden

• Exploits automatisch miteinander verketten

Das bedeutet, dass Schwachstellen schneller denn je entdeckt werden, oft innerhalb von Stunden oder Tagen nach ihrer Einführung.
Die meisten Organisationen haben sich dieser Verschiebung jedoch noch nicht angepasst.
Sicherheitstests werden immer noch als periodisches Ereignis behandelt:

• Einmal im Jahr

• Vielleicht einmal pro Quartal

Und die Behebung verläuft oft noch langsamer und wartet auf Priorisierung, Engineering-Kapazität und Release-Zyklen. Selbst die Zeit, die benötigt wird, um Code in die Produktion zu bringen, erzeugt Lücken, die schnellere Systeme ausnutzen können.
Das schafft eine wachsende Lücke:

• Schwachstellen werden mit Maschinengeschwindigkeit entdeckt

• Fixes werden nach menschlichen Zeitabläufen ausgerollt

Diese Lücke ist die eigentliche Angriffsfläche.
Wenn eine kritische Schwachstelle tagelang oder wochenlang existiert, bevor sie behoben wird, spielt es keine Rolle, wie sie gefunden wurde. Sie ist ausnutzbar.
Das traditionelle Modell „testen, melden, später beheben“ trägt einfach nicht mehr, wenn sowohl Angreifer als auch Entdeckungssysteme kontinuierlich arbeiten.
Dieses Modell ist bereits überholt.

Was tatsächlich funktioniert

Bei der Veränderung geht es nicht um Tools. Es geht um den Ansatz.
Sicherheit muss sich bewegen von:

• Punkt-in-Zeit-Tests → kontinuierliches Testen

In der Praxis ist das nicht nur eine Änderung der Werkzeuge.
Es erfordert, neu zu denken, wie Sicherheit in den Entwicklungszyklus passt.
Kontinuierliches Testen kombiniert typischerweise:

• Automatisierte Systeme, die Tests kontinuierlich ausführen, nicht nur einmal im Jahr

• Sicherheit, die direkt in CI/CD-Pipelines integriert ist

• Entwickler, die Probleme im Rahmen normaler Arbeitsabläufe übernehmen und beheben

• Periodische manuelle Tests für tiefere, komplexere Angriffswege

Das ist nichts, was die meisten teams allein mit mehr Personal lösen können.
Manuelle Tests skalieren nicht, um mit der Geschwindigkeit moderner Entwicklung oder moderner Angreifer mitzuhalten.
Deshalb sehen wir eine Verschiebung hin zu Automatisierung und in vielen Fällen das Auslagern kontinuierlicher Tests an Systeme, die mit Maschinengeschwindigkeit arbeiten können.
Die Dringlichkeit hier ist real.

Was kommt als Nächstes?

KI beschleunigt die Entdeckung von Schwachstellen bereits. Angreifer warten nicht auf Ihren nächsten geplanten Pentest.
Wenn sich Ihre Anwendung täglich verändert, müssen Ihr Sicherheitstest und Ihre Fähigkeit, Probleme zu beheben, mithalten.
Unabhängig von der Architektur verfehlen traditionelle Punkt-in-Zeit-Bewertungen das Ziel. Codebasen entwickeln sich mit Maschinengeschwindigkeit, und ebenso die Angriffsflächen.
Open-Source-Systeme müssen die zusätzliche Angriffsfläche anerkennen und verantworten, die mit der Sichtbarkeit des Codes einhergeht. Closed-Source-Systeme hingegen können sich nicht auf Verschleierung verlassen und müssen ebenfalls ihre Sicherheitslage verbessern.
Die Lücke zwischen der Geschwindigkeit, mit der wir Software entwickeln, und der Häufigkeit, mit der wir sie testen, wird größer.
KI beschleunigt beide Seiten, aber im Moment haben die Angreifer die Oberhand.
Wenn Sie die Sicherheit nicht aktiv so skalieren, dass sie zur Bedrohung passt, werden Ihre Systeme versagen.

Der oben erwähnte Benchmark (XBow) ist öffentlich auf GitHub verfügbar. Unsere Ergebnisse kombinieren kontrollierte Benchmark-Tests mit realen Daten aus Produktionssystemen über unsere Plattform hinweg.