Das Paradoxon zur Offenlegung von Schwachstellen: Warum schnellere Patches KI-generierte Angriffe nicht überholen können
Jahrzehntelang basierte das Patch-Management auf einer Annahme: Wenn man schnell genug ist, besiegt man die Angreifer. Der M-Trends 2026 Report von Mandiant zeigt, dass das Rennen vorbei ist. Die durchschnittliche Schwachstelle wird nun sieben Tage vor einer Lösung ausgenutzt.
Der Kontrast zur jüngeren Vergangenheit ist krass. Im Jahr 2018 hatten Verteidiger etwa zwei Monate nach der Veröffentlichung einer Schwachstelle Zeit, bevor jemand versuchte, sie auszunutzen – Zeit, einen Patch zu testen und auszurollen, bevor jemand anklopfte. Dieses Fenster ist jetzt negativ geworden.
Der Global Threat Report 2026 von CrowdStrike bestätigt dies und stellt fest, dass 42 % der ausgenutzten Schwachstellen angegriffen wurden, bevor sie überhaupt öffentlich gemacht wurden.
Ich habe mich mit Jason Garbis, Gründer von Numberline Security und Co-Vorsitzenden der Zero Trust Working Group bei der Cloud Security Alliance, zusammengesetzt, um diese Erkenntnisse für eine kürzliche Folge des The Segment Podcasts zu besprechen.
Sobald eine Schwachstelle öffentlich bekannt wird, argumentierte er, müssten Angreifer überhaupt nicht mehr nach dem Fehler suchen. Die Offenlegung selbst liefert ihnen einen Bauplan, und ein Exploit aus einem veröffentlichten Advisory zu erstellen, erfordert weit weniger Arbeit, als die Schwachstelle von Grund auf zu finden.
Dieser Wandel ist der Grund, warum die lange Obsession der Sicherheitsbranche mit Patch-Geschwindigkeit der falschen Ziellinie hinterherjagt. Die Teams, die unter dieser neuen Zeitlinie bestehen, teilen eine Eigenschaft. Sie gehen davon aus, dass sie irgendwo zwischen der Offenlegung und dem Patch gehackt werden, und sie haben bereits begrenzt, wie weit dieser Bruch reichen kann.
Wenn die Patch-Warnung zur Blaupause des Angreifers wird
Jeder verantwortungsvolle Offenlegungsprozess existiert aus gutem Grund.
Anbieter müssen den Kunden sagen, was kaputt ist, damit sie es beheben können, und die Regulierungsbehörden verlangen dies zunehmend. Aber dieselbe Transparenz funktioniert jetzt in beide Richtungen.
In dem Moment, in dem ein CVE öffentlich wird, müssen Angreifer kein Mystery mehr rückentwickeln. Sie müssen nur die Warnung lesen. Dann vergleichen sie den gepatchten Code mit der verwundbaren Version. Aus diesem Unterschied können sie einen funktionierenden Exploit erstellen.
Forschungen der AI Safety Initiative der Cloud Security Alliance zeigen, wie weit dieser Prozess bereits automatisiert wurde. Multi-Agenten-KI-Systeme, die darauf ausgelegt sind, offengelegte Schwachstellen zu reproduzieren, haben etwa die Hälfte aller in den letzten zwei Jahren veröffentlichten CVEs rekonstruiert, viele davon mit funktionierenden Exploits, zu einem durchschnittlichen Preis von unter 3 Dollar pro Versuch.
Was früher einen erfahrenen Reverse Engineer und Tage stiller Arbeit erforderte, passiert jetzt für Kleingeld. Es dauert ungefähr so lange, wie die Warnung zweimal zu lesen.
Das ist der Mechanismus, den Jason und ich im Podcast besprochen haben. Ein Angreifer mit Zugang zu einem Frontier-KI-Modell, das Code-Repositories nach unentdeckten Fehlern scannt, ist ein echtes Risiko.
Aber die unmittelbarere Bedrohung ist einfacher. Angreifer warten auf die Offenlegung und eilen dann, um den Exploit zu bauen, bevor die Verteidiger die Validierung und Bereitstellung des Patches abgeschlossen haben.
Offenlegung ist still und leise zu Aufklärung geworden, und die meisten Patch-Management-Programme wurden nie darauf ausgelegt, das zu überstehen.
Der post-Mythos-Patch-Tsunami
Jason hat einen kreativen Begriff für das, was er in naher Zukunft sieht: einen Patch-Tsunami.
Frontier-KI-Modelle decken nun Schwachstellen auf und lösen Sicherheitsupdates in einem Volumen und Tempo aus, dem die meisten Teams noch nie erlebt haben. Die Debatte um Mythos-Klassenmodelle und Project Glasswing fügte dieser Diskussion nur noch mehr Nährstoff.
Aber Jasons Ansicht ist, dass es egal ist, wie viel von dem anfänglichen Hype Marketing war. Diese Modelle werden immer besser darin, Fehler zu finden, und Verteidiger müssen sich unabhängig vom Tempo darauf vorbereiten.
Die Zahlen bestätigen das. Die weltweite CVE-Veröffentlichungen überschritten 2025 48.000, ein Anstieg von 20 % gegenüber dem Vorjahr, laut einer Analyse offizieller CVE-Daten des Cisco-Forschers Jerry Gamblin. Sein Nachfolgebericht zur Jahresmitte zeigt, dass die Kurve vertikal geht: Allein in der ersten Hälfte des Jahres 2026 wurden mehr als 35.000 CVEs produziert, fast 50 % mehr als im gleichen Zeitraum des Vorjahres. Das sind alle 7,4 Minuten ein neuer CVE.
Auch kommerzielle Softwareanbieter komprimieren, wie lange sie ältere Versionen unterstützen, was schnellere Upgrade-Zyklen im gesamten Unternehmen erzwingt.
Open-Source-Bibliotheken werden ebenfalls zu einer wachsenden Quelle der Sichtbarkeit. Jason wies darauf hin, dass sie oft viel weniger Strenge bei Verpackung und Versionierung tragen als kommerzielle Software. So viel individuell angepasste Unternehmenssoftware hängt von ihnen ab, manchmal wurde sie jahrelang nicht angerührt.
Jason argumentierte, dass sich die Grundlagen der Informationssicherheit nicht geändert haben. Die Branche weiß bereits, wie sie sich gegen jede Angriffskategorie verteidigen muss, denen sie heute ausgesetzt ist.
Was sich ändert, ist das Volumen und die Geschwindigkeit, mit der bekannte Risiken eintreffen. Dieser Wandel zeigt Teams, die nie die Disziplin aufgebaut haben, um Schritt zu halten, selbst bevor KI ins Spiel kam.
Wie weit sich eine Verletzung ausbreiten kann, ist die entscheidende Kennzahl
Wenn allein die Patch-Geschwindigkeit keinen negativen Zeitpunkt zum Ausnutzen überholen kann, brauchen Sicherheitsverantwortliche eine andere Kennzahl. Die eigentliche Frage ist, wie viel vom Netzwerk ein Angreifer erreichen kann, sobald er drin ist.
Jason lieferte ein konkretes Beispiel aus seiner Beratungsarbeit. Stellen Sie sich eine Finanzanwendung vor, die auf einem flachen Unternehmensnetzwerk läuft, von dem 5.000 Mitarbeiter und Geräte direkt erreichbar sind. Stellen Sie sich nun vor, dass dieselbe Bewerbung auf die etwa 200 Personen beschränkt ist, die tatsächlich im Finanzbereich arbeiten.
Die Schwachstelle muss trotzdem gepatcht werden. Aber die Bevölkerung, die es vor dem Landen des Patches ausnutzen könnte, ist gerade um mehr als 95 % geschrumpft.
Das gilt für die Behandlung von Segmentierung als grundlegende Kontrolle. Das beseitigt nicht die Notwendigkeit, am ersten Tag Patches zu patchen oder eine perfekte, detaillierte Regelung zu verlangen. Grobe Segmentierung, angewandt rund um Ihre wertvollsten Systeme, bringt dennoch Vorteile.
Mit der richtigen Segmentierung wird eine Schwachstelle, die zu einer großen Katastrophe hätte werden können, stattdessen zu einem kleinen Vorfall, den Ihr Team an einem Nachmittag bewältigen kann.
Die Leitlinien selbst sind seit Jahren konstant. Was sich geändert hat, ist die Kosten, sie zu ignorieren, angesichts der Tatsache, wie schnell eine neue Offenlegung inzwischen zu einem funktionierenden Exploit werden kann.
Drei Schritte, die sich vor deinem nächsten Offenlegungszyklus lohnen
Ein paar konkrete Schritte ergaben sich aus meinem Gespräch mit Jason. Ich würde jeden Sicherheitsleiter ermutigen, diese gegen seine aktuelle Roadmap abzuwägen.
Erstelle ein echtes Inventar dessen, was läuft und wer es erreichen sollte.
Jason betonte das nachdrücklich. Segmentierungstechnologie liefert nur dann Wert, wenn sie genaue, maschinenlesbare Daten über Ihre Arbeitslasten und die Identitäten, die darauf Zugriff benötigen, erhalten. Diesen Schritt zu überspringen ist der schnellste Weg, um eine Police zu bekommen, die auf dem Papier gut aussieht und in der Produktion unterbricht.
Segmentieren Sie Ihre wertvollsten Systeme jetzt, wenn auch grob,
Auf eine perfekte, vollständig durchdachte Politik zu warten, bevor man handelt, ist die Analyseparalyse, vor der Jason direkt gewarnt hat. Ein grober erster Durchgang um deine kritischen Assets schlägt einen wunderschön dokumentierten Plan, der nie ausgeliefert wird.
Setzen Sie einen Refresh-Timer auf Ihre Altsysteme ein
Jason empfiehlt, dass alle neuen Systeme von Anfang an moderner Governance folgen müssen. Jedes bestehende System sollte einen verpflichtenden Neuaufbau- oder Überprüfungszyklus erhalten, sagen wir einmal alle 12 bis 18 Monate. Wenn man diese Arbeit über den Kalender verteilt, verhindert man, dass sie zu einem Stapel wird, den kein Team je angeht.
Der Zeitpunkt zum Handeln ist vor der nächsten Offenlegung, nicht danach
Im Juni machte die Cybersecurity and Infrastructure Security Agency (CISA) diese Änderung offiziell zur Politik. Die verbindliche Betriebsrichtlinie 26-04 verlangt nun, dass Bundesbehörden innerhalb von drei Tagen die gefährlichsten Schwachstellen (öffentlich offengelegt, aktiv ausgenutzt und automatisierbar) beheben müssen, was dem vorherigen Zwei-Wochen-Standard entspricht. CISA nannte KI direkt als Grund und wies darauf hin, dass sie die Geschwindigkeit der Schwachstellenerkennung für Angreifer und Verteidiger gleichermaßen erheblich erhöht.
Die Richtlinie bindet nur Bundesbehörden, aber CISA ermutigt den Privatsektor, denselben Ansatz zu verfolgen. Die Erwartung der Branche an die Reaktionszeit wurde bereits neu geschrieben.
Die gute Nachricht ist, dass all das nicht erfordert, Ihr Sicherheitsprogramm von Grund auf neu zu erfinden. Es erfordert die Akzeptanz, dass eine Verletzung irgendwo zwischen Offenlegung und Patch nun das Szenario ist, auf das man sich planen muss. Und es erfordert Segmentierung um Ihre wichtigsten Systeme, sodass ein Datenverstoß einen Nachmittag kostet statt einer Schlagzeile.
Die Teams, die dies jetzt als dringend behandeln, solange zwischen der heutigen Bedrohungslandschaft und dem, was mit der nächsten Generation kommt, noch eine gute Geschichte erzählen werden, sind diejenigen, die in einem Jahr noch eine gute Geschichte erzählen werden. Auf einen saubereren Moment zu warten, ist eine Wette, die die Daten nicht mehr unterstützen.
Hören Sie die vollständige Folge von The Segment: A Zero Trust Leadership Podcast auf Apple Podcasts, Spotify (Englisch), oder Unsere Website.

.webp)
.webp)

.webp)
