München, 1. September 2026 – Ein Sicherheits-Update wird veröffentlicht – und Stunden später ist bereits ein fertiger Exploit dafür im Umlauf. Fortschrittliche KI-Modelle machen dieses Szenario möglich, wie die Besorgnis in der Branche rund um das Mythos-Preview von Anthropic im Frühjahr 2026 gezeigt hat. Diese Modelle können veröffentlichte Patches automatisch analysieren, erkennen, welche Schwachstelle behoben wurde, daraus Exploit-Code erzeugen und sogar alle exponierten Systeme identifizieren, auf denen das Update noch nicht eingespielt wurde – und das innerhalb von Sekunden. Während Unternehmen früher oft Wochen Zeit hatten, eine bekannte Schwachstelle zu schließen, bleiben heute häufig nur noch Stunden, wenn überhaupt. Jan Wildeboer, EMEA Evangelist bei Red Hat, stellt vier Maßnahmen vor, mit denen sich die eigene IT an die neue Geschwindigkeit von Bedrohungen anpassen lässt.
Sobald ein Sicherheits-Patch für eine Open-Source-Komponente veröffentlicht wird, lässt sich aus ihm ablesen, welcher Fehler behoben wurde. Ein Umstand, den KI-gestützte Analysen ausnutzen. Eine von Angreifern eingesetzte KI vergleicht automatisiert alte und neue Versionen, rekonstruiert die Schwachstelle und generiert daraus einen funktionierenden Exploit. Im nächsten Schritt sucht sie nach Systemen, die über eine Internetverbindung verfügen und noch alte, ungepatchte Versionen einsetzen – jedes davon ein sofort verwertbarer Angriffspunkt.
Dadurch ist die Zeitspanne zwischen Patch-Veröffentlichung und aktiver Ausnutzung von Wochen auf heute teils nur noch Stunden geschrumpft. Wer seine Systeme nicht in vergleichbarem Tempo aktualisiert, eröffnet Angreifern ein Zeitfenster, das diese gezielt und automatisiert nutzen werden. Vier Ansatzpunkte helfen, diese Zeitspanne zu minimieren:
- Auf aktive, vertrauenswürdige Anbieter setzen: Nicht alle Software-Anbieter sind gleich zuverlässig, wenn es um Sicherheit geht – insbesondere bei den Open-Source-Komponenten, die in ihren Produkten zum Einsatz kommen. Ein wichtiger Hinweis auf Vertrauenswürdigkeit und proaktives Handeln ist, ob ein Anbieter selbst aktiv zu den Open-Source-Projekten beiträgt, die er ausliefert. Das können etwa eigene Commits, Security-Backports oder verantwortungsvolles Offenlegen gefundener Lücken sein. Für Anbieter gilt daher auch umgekehrt: Wer aktiv handelt und in Open-Source-Ökosysteme investiert, sichert nicht nur die eigene Kundenbeziehung, sondern auch die Codebasis, auf die sich viele Anwenderinnen und Anwender verlassen.
- Ein Dependency Inventory aufbauen und pflegen: Wer nicht genau weiß, welche Open-Source-Bibliotheken, Abhängigkeiten und Versionen im eigenen Produktivbetrieb laufen, kann im Ernstfall nicht schnell reagieren. Genauso wichtig ist es, die tatsächliche Zeit zu kennen, die ein Patch heute von den internen Sicherheitsprüfungen über die Tests und Freigabeprozesse bis zum Deployment in die Produktion braucht. Erreichbar sind spürbare Verkürzungen aber nur, wenn Rebuild- und Redeploy-Prozesse durchgängig automatisiert statt manuell durchgeführt werden.
- Automatisierung an den Medienbrüchen ansetzen: Der größte Bremsklotz für schnelle Patch-Zyklen sind meist nicht fehlende Tools, sondern die menschlichen Übergabepunkte zwischen Entwicklung, Staging, Pre-Production und Production. Wichtig sind diese Schnittstellen trotzdem. Sie lassen sich aber entschärfen, indem Anwendungen in unabhängige Layer aufgeteilt werden, die sich automatisiert und getrennt voneinander ausrollen lassen. Voraussetzung dafür sind stabile Schnittstellen (API/ABI-Stabilität) zwischen den Layern, damit ein Layer aktualisiert werden kann, ohne die gesamte Anwendung neu zu testen und freizugeben.
- Reaktionszeiten nach Kritikalität staffeln: Nicht jede Schwachstelle benötigt dieselbe Reaktionsgeschwindigkeit. Wer seine eingesetzten Bibliotheken nach Risiko priorisiert, kann bei kritischen Komponenten sofort reagieren. Bei weniger kritischen Anwendungen ist der Netzwerkzugang vorübergehend blockierbar, bei Bedarf können aber auch andere prozessbasierte Maßnahmen ergriffen werden, bis eine Lösung bereitsteht, anstatt einen unvollständigen Patch übereilt zu veröffentlichen. Dieser Kompromiss ist eine klassische Aufgabe des CISO, bei der es darum geht, Risiko und Produktivität gegeneinander abzuwägen und erfordert eine enge Zusammenarbeit mit den Architekten und Architektinnen.
Diese Maßnahmen erfordern seltener neue Werkzeuge oder Technologien als neue Priorität. Denn: In vielen Fällen beginnt die Umstellung auf schnellere Prozesse oder wehrhaftere Strategien erst, wenn ein eklatanter Sicherheitsvorfall bereits geschehen ist. Systeme mit jahrealten, ungepatchten Versionen laufen häufig im Hintergrund weiter, weil sie im Stillen ihren Zweck erfüllen. Angesichts der neuen Angriffsgeschwindigkeit und präzisen Erkennung dieser Schwachstellen ist genau diese abwartende Haltung das eigentliche Risiko.
