Für Maschinen sind Menschen Schnecken : Schwachstellenmanagement darf in einer KI-geprägten Welt nicht mehr im menschlichen "Schneckentempo" erfolgen
Die Geschindigkeit, mit der eine KI-unterstützte Welt Schwachstellen findet und deren Ausnutzbarkeit beschleunigt, erfordert mehr als die bloße Steigerung der Schnelligkeit von Patchvorgängen und Verteidigungsmaßnahmen, mahnt unser Autor. Vielmehr ist ein Dreiklang von Fähigkeiten gefragt, die sich in einem "Risk-Operations-Center" (ROC) bündeln lassen.
Die Veröffentlichung von „Claude Mythos“ hat gezeigt, dass ein bahnbrechendes KI-System in der Lage ist, Schwachstellen in Produktionssoftware mit maschineller Geschwindigkeit und Tiefe autonom zu finden und auszunutzen. Kurz darauf wurde deutlich, was geschieht, wenn diese Fähigkeit nicht vollständig eingedämmt wird: Im Juli 2026 brach ein OpenAI-Modell aus einer Sandbox aus, nutzte eine Zero-Day-Schwachstelle in der Paketregistrierung eines Drittanbieters aus und kombinierte diese mit gestohlenen Anmeldedaten, um eine Remote-Code-Ausführung auf der Produktionsinfrastruktur von Hugging Face zu erreichen. Zwei Labore, zwei voneinander unabhängige Vorfälle in weniger als sechs Monaten – zusammengenommen ist das kein Zufall, sondern vielmehr ein bahnbrechender Trend: Die KI-beschleunigte Erkennung von Sicherheitslücken ist kein Zukunftsrisiko mehr. Das haben vorige Woche auch die Vorgänge um die PHP2Shell-Schwachstellen erneut belegt.
Schwachstellenmanagement läuft seit Jahren nach dem gleichen Schema ab: Scannen, Bewerten, Ticket erstellen, Patchen. Dieses Modell geht davon aus, dass Sicherheitsverantwortliche Zeit haben, um eine Warteschlange abzuarbeiten, nachdem eine Schwachstelle bekannt geworden ist. Diese Annahme stand jedoch bereits vor diesem Jahr auf dem Prüfstand: Die M-Trends-Daten von Mandiant beziffern die durchschnittliche Zeit bis zur Ausnutzung von Vulnerabilitys auf etwa minus sieben Tage. Das bedeutet, dass viele Schwachstellen bereits ausgenutzt werden, bevor überhaupt ein Patch verfügbar ist. Qualys-Analysen von über einer Milliarde CISA-KEV-Behebungsdatensätzen, die mehr als 10000 Organisationen umfassen, ergaben zudem, dass das Volumen der abgeschlossenen Schwachstellenvorfälle zwischen 2022 und 2025 um das 6,5-fache gestiegen ist. Gleichzeitig stieg der Anteil der „Known Exploited Vulnerabilities“ (KEV) kritischer Schwachstellen, die eine Woche nach der Offenlegung noch immer offen waren, im gleichen Zeitraum von 56 % auf 63 %. Security-Teams arbeiten zwar immer härter, geraten aber gleichzeitig immer weiter in Rückstand.
Auch der Versuch, diese Lücke durch Patches der heikelsten Probleme zu schließen, ist nicht erfolgreich. Nach Schätzungen von Qualys werden weniger als ein Prozent der als „kritisch“ eingestuften Schwachstellen in der Praxis tatsächlich ausgenutzt. KI beschleunigt beide Seiten des Problems gleichzeitig. Was die Erkennung betrifft, so hat die Athena-Koalition von Chainguard allein in den ersten drei Wochen Zehntausende von durch KI aufgedeckten Open-Source-Sicherheitslücken verarbeitet. Ein bedeutender Anteil dieser Sicherheitslücken erhielt nie eine Common -Vulnerabilities-and-Exposures-(CVE)-Kennung, da der zugrunde liegende Fehler bereits unbemerkt im Upstream-Code behoben worden war. In der Angriffsforschung lassen sich zudem echte Exploit-Ketten ergründen, bei denen zwei für sich genommen moderate Schwachstellen zu einer vollständigen Remote-Code-Ausführung führen – eine solche Kombination würde kein einzelner CVSS-Score jemals als dringend kennzeichnen.
Es gibt also mehr Fundstellen, ausgefeiltere Verknüpfungen und weniger Zeit zum Reagieren – das „alte“ Modell funktioniert unter diesen Voraussetzungen nicht mehr.
Antwort auf neue Herausforderungen durch KI-unterstützte Schwachstellensuche
Um der aktuellen Situation gerecht zu werden fokussiert die Securitybranche zunehmend auf drei zusammenwirkende Fähigkeiten statt nacheinander ablaufende Aktionen:
- Erkennen mit KI-Geschwindigkeit, was Risiken auslöst – unabhängig davon, ob ein CVE vorliegt oder nicht: Diese Erkennung muss auch Fehlkonfigurationen, Identitätsrisiken und Schwachstellen abdecken, denen noch nie ein CVE zugewiesen wurde. Dies ist ein realer und wachsender Anteil der gesamten Sicherheitsrisiken. Angreifer, die KI einsetzen, warten nicht auf eine Kennung, bevor sie handeln. Moderne Erkennungsplattformen bauen deshalb zunehmend eigene Signaturbibliotheken mit oft zehntausenden Einträgen auf, um genau diese Lücke zu schließen.
- Prioritäten entsprechend der individuellen Umgebung des eigenen Unternehmens setzen: Eine Einstufung als „kritisch“ beschreibt zwar eine theoretische Gefahr, gibt jedoch keine Auskunft darüber, ob etwas im eigenen Hause vorhanden, mit dem Internet verbunden oder mit einer geschäftskritischen Ressource verknüpft ist oder bereits blockiert wurde. Die effektivsten Programme kombinieren Dutzende von Threat-Intelligence-Feeds (TI) mit dem konkreten geschäftlichen Kontext und überprüfen dann anhand realer Kontrollmaßnahmen die Ausnutzbarkeit, bevor etwas in eine Behebungswarteschlange gelangt. In großem Maßstab angewendet, kann dieser Filterprozess dramatische Auswirkungen haben: Praktische Einsätze haben gezeigt, dass sich die Menge von zig Millionen Rohbefunden auf zehntausende bestätigter, behebungswürdiger Schwachstellen reduziert hat. Dadurch lassen sich prognostizierte Behebungskosten teils um mehr als 99 % senken.
- Autonome Fehlerbehebung mit soliden Sicherheitsvorkehrungen: Manuelle Patch-Zyklen können mit dem Tempo der KI-beschleunigten Erkennung nicht mithalten – eine pauschale Automatisierung ist jedoch ebenso riskant. Die Lösung liegt in einer abgestuften Autonomie: Zuverlässigkeitsbewertungen, die auf Bereitstellungssignalen aus dem Internet basieren, die mittels Crowdsourcing erhoben wurden, können Software, bei der das Risiko von Betriebsausfällen gering ist – wie etwa Browser –, für eine automatische „Zero-Touch“-Patch-Installation freigeben. Änderungen an risikoreicheren, kritischen Systemen werden hingegen schrittweise und wellenartig eingeführt; falls es zu Störungen kommt, erfolgt ein automatisches Rollback.
Praxis braucht Risk-Operations-Center (ROC)
Eine solche Lösung kann kein weiteres Dashboard sein. Bei diesem Betriebsmodell müssen vielmehr alle Risikoquellen – Schwachstellenmanagement, Cloud- und Container-Sicherheitsstatus, Identitäten, Anwendungen sowie OT/IoT – als Input für eine einzige, priorisierte und validierte Übersicht genutzt werden. Dann ist es nicht mehr notwendig, für jedes Programm eine eigene Liste kritischer Punkte zu erstellen. Ein möglicher Begriff hierfür lautet: Risk-Operations-Center (ROC).
Während ein Security-Operations-Center (SOC) erst reagiert, wenn bereits ein Vorfall eingetreten ist, ist ein ROC darauf ausgelegt, proaktiv und präventiv zu arbeiten. Es bündelt Ressourcen und Erkenntnisse aus der gesamten Umgebung, priorisiert diese anhand von Bedrohungsinformationen und geschäftlichem Kontext, validiert, was tatsächlich ausnutzbar ist, und treibt die Behebung bestätigter Risiken voran. In diesem Modell kann sich die Berichterstattung von Aktivitätskennzahlen, wie beispielsweise gefundenen CVEs oder bereitgestellten Patches, hin zu Ergebnissen verlagern, die für den Vorstand relevant sind: „Value at Risk“, vermiedene finanzielle Risiken durch bestätigte Bedrohungen und eine größere Geschwindigkeit, mit der sich die Lücke zwischen „ausnutzbar“ und „behoben“ schließt.
Fazit: Neues Paradigma für die Sicherheitsbehebung
Der Moment, in dem die KI-gestützte Erkennung von Sicherheitslücken keine Theorie mehr war, wurde „Mythos“ genannt. Der Vorfall bei OpenAI und Hugging Face sowie die potenziell weitreichenden Auswirkungen der aktuellen PHP2Shell-Lücken haben eindrücklich gezeigt, dass dies kein Problem ist, das nur in Pionierlabors auftritt.
Diese Ereignisse führen zu derselben Schlussfolgerung: Ein lediglich intensiveres und schnelleres Patchen innerhalb des bisherigen Modells ist keine tragfähige Strategie mehr. Um mit KI-gesteuerten Bedrohungen Schritt zu halten, ist eine Kombination aus dem Aufspüren von Schwachstellen, die ein Cyberrisiko für das Unternehmen darstellen, einer risikobasierten Priorisierung anhand der tatsächlichen Ausnutzbarkeit statt der theoretischen Schwere sowie der autonomen Behebung mit echten Sicherheitsvorkehrungen erforderlich.