Ist Schwachstellenmanagement schnell genug für die KI-Zeit?

Als ich vor ein paar Jahren über Supply-Chain-Angriffe geschrieben habe, ging es noch um Wochen und Monate: Ein Upstream-Server wird kompromittiert, Wochen später fällt es jemandem auf, und im Anschluss beginnt das Aufräumen. Diese Zeitrechnung gilt seit einer Weile nicht mehr. Das Strategiepapier "The AI Vulnerability Storm: Building a Mythos-ready Security Program", das die Cloud Security Alliance zusammen mit SANS, [un]prompted und dem OWASP Gen AI Security Project im April 2026 veröffentlicht hat, beschreibt, was viele von uns im Betrieb längst spüren, und liefert auch die Zahlen dazu.

Die im Paper beschriebenen Maßnahmen benötigen allerdings Zeit, um eingeführt zu werden. Zeit, die man aktuell schon nicht mehr hat. Denn Angreifer warten nicht, bis die Verteidigung fertig gebaut ist, sondern nutzen die neuen Möglichkeiten sofort. Wie überbrücke ich also die Zeit, bis meine Verteidigung voll einsatzbereit ist?

Ist Open Source Intelligence als Frühwarnung eine Brückentechnologie, die man schnell einsetzen kann, um globalen Angriffen frühzeitig entgegenzutreten? 

Die Kernaussage des Papers der Cloud Security Alliance besagt, dass KI-gestützte Schwachstellensuche und Exploit-Entwicklung sich über das letzte Jahr kontinuierlich beschleunigt haben. Das Frontier-Modell Mythos markiert dabei nur einen Sprung und nicht den Anfang der Entwicklung. Das merken wir durch eine signifikante Erhöhung der gefunden Schwachstellen auch in der Praxis.

Die Zero Day Clock von Sergej Epp zeigt, dass 2018 die durchschnittliche Zeit zwischen CVE-Veröffentlichung und bestätigter Ausnutzung noch bei über zwei Jahren lag. Dies hat sich für 2026 mittlerweile auf wenige Stunden reduziert (2024 waren es 56 Tage, 2025 gut drei Wochen). Das Fenster zwischen Entdeckung und Ausnutzung ist praktisch kollabiert. 

Diese Zahlen sollte man allerdings als Richtungsangabe lesen, nicht als Messwert. Sergej Epp hat die Zero Day Clock im September 2026 überarbeitet und die TTE-Kurve dabei entfernt. Als Grund nennt er ein Alterungsproblem der Daten: Eine vor fünf Jahren veröffentlichte Schwachstelle hatte fünf Jahre Zeit, Belege für ihre Ausnutzung zu sammeln, eine vom letzten Monat nur einen Monat. Dadurch sahen die jüngeren Jahre schneller aus, als sie tatsächlich waren, und er schreibt selbst, dass er den KI-Anteil an der Beschleunigung zu stark gewichtet hat. Die Richtung der Entwicklung bestätigen auch die neuen Zahlen der überarbeiteten Seite, die exakten Jahreswerte aber nicht.

Das Thema an einem einzelnen Modell festzumachen, wäre ein Missverständnis. Diese Fähigkeiten entwickeln sich seit Mitte 2025 quer über die Branche: XBOW erreichte Platz 1 der US-Bestenliste von HackerOne, Googles Big Sleep fand zwanzig echte Zero-Days in FFmpeg und ImageMagick, AISLE meldete zwölf OpenSSL-Zero-Days. Und am 3. September 2026 hat OpenAI GPT-6 Astra veröffentlicht: 100 Prozent auf ExploitBench, erstes Modell, das wegen seiner Cyber-Fähigkeiten verschärfte interne Schutzstufen auslöst.

Wie weit das reicht, zeigt ein Vorfall bei OpenAI im Sommer 2026. Bei internen Evaluierungen brachen Agenten aus ihrer isolierten Testumgebung aus: Sie fanden dafür eine SSRF-Zero-Day in Artifactory, verschafften sich Internetzugang, stießen auf exponierte Hugging-Face-Zugangsdaten und verketteten weitere Schwachstellen bis zur Codeausführung auf 41 produktiven Workern. Es war also eine gehärtete Produktivumgebung und kein präpariertes Testziel, und der Einstiegspunkt war eine unbekannte Schwachstelle in einer Standardkomponente, die in unzähligen Unternehmen betrieben wird. Auslöser war dabei kein Angreifer, sondern der Versuch der Modelle, die eigene Bewertungsaufgabe zu umgehen. Wenn eine KI das schon versehentlich schafft, stellt sich die Frage, was mit derselben Fähigkeit und erklärter Absicht möglich ist.

Für eine Anwendungssicherheit, die auf CVE-Listen, Behebungsfristen, Threat Modelling, Konzept-Reviews und regelmäßigen Pentests aufbaut, ist das eine strukturelle Herausforderung, keine graduelle. Die Antwort läuft unter dem Begriff "VulnOps": eine dauerhafte Funktion, die kontinuierlich eigene und fremde Software KI-gestützt prüft und die Behebung automatisiert, also analog zu DevOps, nur für Schwachstellenforschung und -behebung. Sechs bis zwölf Monate sind dafür realistisch, denn es braucht Personal, Werkzeuge, Governance und geänderte Abläufe in vielen Teams gleichzeitig. In dieser Übergangszeit gilt das Angriffsfenster von Stunden aber schon.

Die naheliegendste Möglichkeit, in dieser Übergangszeit Zeit zurückzugewinnen, ist auch die billigste: früher erfahren, dass irgendwo eine kritische Schwachstelle oder ein Supply-Chain-Vorfall auftaucht. Öffentlich verfügbare Quellen wie z. B. Security-Blogs, Advisories der Hersteller oder Feeds von Forschungsteams melden solche Vorfälle in der Regel deutlich früher, als sie in den strukturierten Schwachstellendatenbanken landen, aus denen die üblichen Scan-Werkzeuge ihre Treffer ziehen. Genau diese Differenz ist der Hebel.

Dafür habe ich einen kleinen OSINT-Monitor gebaut, der Security-Blogs und Feeds nach Exploit- und Supply-Chain-Meldungen durchsucht und Treffer als Digest-Mail an abonnierte Interessierte verteilt. Es ist ein überschaubares Python-Programm, das als Lambda in AWS läuft, seinen Zustand in einer JSON-Datei hält und Mails verschickt. Bewusst ohne KI und ohne Heuristik. Eine reine Feed- und Keyword-Logik, die alle 30 Minuten läuft und die konfigurierten Webseiten deterministisch und reproduzierbar durchsucht. Wenn ich weiß, dass ein Fund exakt aus einem passenden Schlüsselwort in einem beobachteten Feed folgt, kann ich dem Ergebnis vertrauen, ohne es erst gegenprüfen zu müssen. Bei der wachsenden Zahl KI-gestützter Meldungen, die auch AI Slop enthalten können, ist ein Kanal, dessen Verhalten man vollständig erklären kann, mehr wert als einer, der mehr findet, aber sich häufiger irrt.

Genau das ist aber auch die Grenze des Ansatzes. Das Werkzeug erkennt nur, was öffentlich in einem der konfigurierten Feeds bereits gemeldet wurde, und nur, wenn ein Beitrag zu den hinterlegten Schlüsselwörtern passt. Es sieht keine Angriffe gegen die eigene Infrastruktur, keine Anomalien im eigenen Netzwerk und keine Schwachstelle, bevor irgendjemand öffentlich darüber schreibt. Es ist also kein Angriffserkennungssystem, sondern ein Frühwarnsystem, und dessen Geschwindigkeit hängt davon ab, wie schnell die beobachteten Quellen selbst berichten.

Der Nutzen für die Übergangszeit ist trotzdem erheblich. Bei aktuellen Supply-Chain-Angriffen sind die ersten 24 bis 48 Stunden entscheidend, insbesondere in der npm-Welt: Meist sind die betroffenen Versionen nach dieser Zeit erkannt und beseitigt. Aber sie können noch im Repository des Unternehmens, in der Build-Pipeline oder auf dem lokalen Entwicklerrechner liegen.

Wie ungemütlich es werden kann, zeigt der aktuelle Fall CVE-2026-18963. Red Hat hat die Schwachstelle am 18. August 2026 veröffentlicht, bewertet mit CVSS 9.1: Über eine fehlerhafte Zustandsprüfung im reset-credentials-Flow kann ein nicht authentifizierter Angreifer für jedes beliebige Konto, auch für Administratorkonten, ein neues Passwort setzen, ohne den Bestätigungslink jemals erhalten zu haben. Ein Benutzername genügt und eine Interaktion des Opfers ist nicht nötig. Behoben ist das in Keycloak 26.7.2 sowie in den Red-Hat-Builds 26.4.15 und 26.6.6.

Für den Betrieb entstehen daraus gleich zwei Probleme. Erstens wird eine kritische Schwachstelle nicht zwangsläufig für alle betroffenen Versionsstände gleichermaßen gemeldet:

• Erscheint die Meldung zuerst für die kommerzielle Variante, erkennt man in den anderen Versionen nicht rechtzeitig, dass man ebenfalls betroffen ist.
• Zweitens muss man aus einer Zeile wie "Unauthenticated account takeover via reset-credentials flow bypass" selbst erkennen, dass Gefahr im Verzug ist, und nicht warten, bis der Scanner den Fund meldet und die reguläre Frist zu laufen beginnt.

Auch hier hilft Open Source Intelligence. Der OSINT-Monitor lässt sich mit Schlüsselwörtern und passenden Quellen so konfigurieren, dass eine Mail herausgeht, sobald für irgendeine Keycloak-Version eine kritische Schwachstelle erscheint. Damit bekommt man frühzeitig eine Information, kann schnellstmöglich prüfen, ob man betroffen ist, und Maßnahmen zur Angriffsabwehr ergreifen. In diesem Fall haben wir als erste schnelle Maßnahme die Passwort-Reset-Funktion deaktiviert, um die Zeit zu überbrücken, bis der Patch produktiv eingespielt war.

Das ist der Punkt, der oft untergeht: Frühwarnung bedeutet nicht nur früheres Patchen. Sie schafft überhaupt erst das Zeitfenster, in dem mitigierende Maßnahmen möglich sind.

Das zweite Problem ist unabhängig von der Scan-Geschwindigkeit: Bei Supply-Chain-Würmern wie Shai-Hulud im npm-Ökosystem reicht es nicht, schneller zu scannen. Der bösartige Code darf gar nicht erst auf ein Entwicklersystem oder in eine CI/CD-Pipeline gelangen.

Die Kampagne hat sich dabei deutlich weiterentwickelt. Die erste Welle im September 2025 verteilte manipulierte Versionen unter anderem von @ctrl/tinycolor und sammelte über einen postinstall-Hook npm-, GitHub- und Cloud-Zugangsdaten ein. Im November 2025 wanderte die Ausführung in die preinstall-Phase. Damit läuft sie ohne jede Interaktion und unterläuft Prüfwerkzeuge, die erst später im Build greifen.

Unit 42 zählte über 25.000 betroffene Repos und seit Mai 2026 ist der Quellcode des Wurms sogar öffentlich. Beispielsweise genügte die Übernahme eines einzigen Maintainer-Kontos (keyv) am 4. August 2026 um ca. 444 Pakete in über 2.200 Versionen zu infizieren, und das am selben Tag.

Aus einem großen deutschen Unternehmen, für dessen B2B- und B2C-Vertriebsplattform (API, Web, Mobile) ich als einer von mehreren Security-Architekten tätig bin, kann ich beschreiben, wie beides zusammenspielt. Die Grundlage ist ein klassisches, aber konsequent automatisiertes Schwachstellenmanagement:

• SBOMs entstehen beim Bau und werden laufend gescannt. Für jedes produktive Artefakt wird beim Build ein Software Bill of Materials (SBOM) erzeugt und in eine zentrale Datensenke übertragen. Sollte für den Container, in dem die Anwendung läuft, kein SBOM vorhanden sein, dann wird dieser für den Scan-Schritt extra erzeugt. Gescannt wird zwei- bis dreimal täglich mit Trivy, und zwar nur für die Container, die tatsächlich produktiv laufen. Die Ergebnisse laufen zentral in einem DefectDojo zusammen.
• Feste Behebungsfristen mit Ausnahmeregelung. Für internetexponierte Systeme gilt bei High/Critical-Schwachstellen eine Frist von zwei Tagen, bei Überschreitung eskaliert der Vorgang automatisch. Security-Architekten können nach Bewertung der konkreten Ausnutzbarkeit befristete Ausnahmen genehmigen, etwa wenn eine Schwachstelle im konkreten Kontext nicht erreichbar ist.
• Verteilte Verantwortung. Neben dem zentralen Security-Team mit dedizierten Security-Architekten gibt es Security Champions in über 30 Entwicklungsteams verschiedener Domänen. Ohne diese Breite wäre die Zwei-Tage-Frist bei entsprechendem Volumen nicht durchhaltbar.

Dieses Fundament reagiert aber grundsätzlich nur auf das, was in den Schwachstellendatenbanken steht. Das Keycloak-Beispiel zeigt, dass es hier zu Latenzen kommen kann. Deshalb läuft daneben ein zweiter, bewusst schnellerer Strang, der auf öffentlichen Quellen aufsetzt:

Nein, nicht durchgängig. Ein Schwachstellenmanagement, das zwei- bis dreimal täglich scannt und mit festen Fristen und Eskalation arbeitet, ist eine gute Basis und deckt den größten Teil der Schwachstellen zuverlässig ab. Es hilft aber nicht gegen ein Zeitfenster, das laut Zero Day Clock nur noch Stunden beträgt, nicht gegen eine kritische Schwachstelle wie bei Keycloak, die je nach Versionsstand gar nicht oder erst spät im Scan auftaucht, und auch nicht gegen einen npm-Wurm, der sich schon beim npm install selbst verbreitet.

Die Auswertung öffentlicher Meldungen mit anschließendem Abgleich und eine gehärtete Entwicklungsumgebung schließen diese Lücke nicht vollständig, aber sie verschaffen die Tage, die sonst fehlen. Langfristig geht der Weg zu einer VulnOps-Funktion, die kontinuierlich läuft und KI-Agenten dort einsetzt, wo sie heute schon zuverlässig helfen: beim Vorprüfen von Findings, beim Triagieren nach tatsächlicher Ausnutzbarkeit und beim Beschleunigen von Patches. Dass der Aufbau sechs bis zwölf Monate oder länger dauert, ist kein Grund, damit später anzufangen. Es ist der Grund, in der Zwischenzeit nicht abzuwarten.

• CSA CISO Community, SANS, [un]prompted, OWASP Gen AI Security Project: The "AI Vulnerability Storm": Building a "Mythos-ready" Security Program, Version 1.0, 1. Mai 2026.
• Sergej Epp: Zero Day Clock, Visualisierung der Zeit von Schwachstelle zu Ausnutzung.
• Sergej Epp: ZeroDayClock: Beyond AI Doomers and AI Maginot Thinkers, 17. September 2026.
• OpenAI: GPT-6 Astra: A new generation of intelligence, 3. September 2026.
• CNBC: OpenAI begins rolling out Astra model after warning of its advanced cyber capabilities, 3. September 2026.
• OpenAI / Hugging Face: Partnering to address a security incident during model evaluation, Juli 2026.
• OpenAI: The Hugging Face incident and the road ahead, August 2026.
• OpenAI: Hugging Face Incident: Technical Report (PDF), August 2026.
• Thomas Claburn, The Register: OpenAI explains how its naughty AI agents attacked Hugging Face, 27. August 2026.
• heise online: Access Management Keycloak: Account Takeover via Password Reset Function, August 2026 (zu CVE-2026-18963).
• Justin Moore, Unit 42 (Palo Alto Networks): "Shai-Hulud" Worm Compromises npm Ecosystem in Supply Chain Attack, September 2025, aktualisiert November 2025.
• Liran Tal, Snyk: NPM Security Best Practices: How to Protect Your Packages After the 2025 Shai Hulud Attack.
• Elastic Security Labs: Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packages, 6. August 2026.
• heise online: Supply chain attack on keyv: Shai-Hulud worm infects over 440 npm packages, August 2026.