Am 22. Juni 2026 stellte OpenAI GPT-5.5-Cyber vor. Im ersten fünftägigen Sprint der begleitenden Initiative „Patch the Planet“ entstanden bereits hunderte Findings zur Prüfung. Kurz darauf fragt die Geschäftsführung, ob das Unternehmen mit solchen Werkzeugen jetzt automatisch sicherer wird.

Die ehrliche Antwort lautet: noch nicht.

GPT-5.5-Cyber und zuvor Claude Mythos Preview zeigten in kontrollierten Tests, dass sie Codebasen analysieren, Angriffspfade verfolgen und für bestimmte Schwachstellen funktionsfähige Exploits entwickeln können. Aufgaben, für die erfahrene Sicherheitsforscher früher Tage oder Wochen brauchten, lassen sich dort teilweise innerhalb weniger Stunden erledigen.

Damit verschiebt sich das Problem. Schwachstellen zu finden, war lange der Engpass. Jetzt werden es die Schritte danach: einen Fund bestätigen, seine reale Auswirkung verstehen, einen sicheren Patch entwickeln, Seiteneffekte ausschließen und das Update tatsächlich zu den betroffenen Systemen bringen.

Ein Bericht schützt noch kein Produkt. Erst der eingespielte Fix reduziert das Risiko.

Was GPT-5.5-Cyber, Mythos 5 und Fable 5 verändern

Die aktuellen Modellnamen sind spektakulär, die technische Entwicklung dahinter ist wichtiger. OpenAI veröffentlichte am 22. Juni 2026 die vollständige Version von GPT-5.5-Cyber für einen begrenzten Kreis verifizierter Verteidiger. Anthropic hatte am 9. Juni Claude Fable 5 und Claude Mythos 5 vorgestellt. Beide beruhen nach Angaben des Unternehmens auf demselben Grundmodell; Fable besitzt strengere Schutzmechanismen, während Mythos für spezialisierte Cybersecurity-Arbeit vorgesehen war. Am 12. Juni deaktivierte Anthropic infolge einer US-Regierungsanordnung den Kundenzugang zu beiden Modellen vollständig. Für Hersteller ist jedoch eine andere Entwicklung wichtiger: Die technische Schwelle für anspruchsvolle Schwachstellensuche sinkt.

Diese Systeme durchsuchen nicht nur einzelne Funktionen nach bekannten Fehlermustern. Sie können sich über längere Zeit durch große Repositories bewegen, sicherheitsrelevante Komponenten identifizieren, Erreichbarkeit prüfen, Hypothesen in kontrollierten Umgebungen testen und Patchvorschläge entwickeln.

Die Leistungswerte zeigen, wie schnell sich die Grenze verschiebt. GPT-5.5-Cyber erreichte laut OpenAI 85,6 Prozent im CyberGym-Benchmark. In einer separaten Auswertung des britischen AI Security Institute erzielte GPT-5.5 bei Expert-Aufgaben 71,4 Prozent; der dort getestete Stand von Mythos Preview erreichte 68,6 Prozent. Eine unabhängige AISI-Evaluation von GPT-5.5-Cyber oder Mythos 5 liegt bislang nicht vor.

Solche Benchmarks sind kein Beweis dafür, dass ein Modell jedes reale Unternehmensnetz oder jede industrielle Software zuverlässig prüfen kann. Sie zeigen aber, dass anspruchsvolle Sicherheitsaufgaben nicht mehr ausschließlich erfahrenen Spezialisten vorbehalten sind. Anthropic berichtet, dass Glasswing-Partner ihre Fundrate teilweise um mehr als den Faktor zehn steigerten. Diese Anbieterangabe ersetzt keine unabhängige Bewertung der einzelnen Findings.

Die Grenzen zeigen sich besonders in industriellen Umgebungen. Im AISI-Szenario „Cooling Tower“, das eine mehrstufige OT-Umgebung simuliert, bewältigte keines der geprüften Modelle den vollständigen Angriff. GPT-5.5 scheiterte bereits im vorgelagerten IT-Teil. Fortschritte bei Codeanalyse und Exploitentwicklung bedeuten also nicht, dass heutige Modelle industrielle Systeme allgemein verstehen oder autonom beherrschen.

Damit wächst nicht nur die Zahl möglicher Funde. Es wächst auch die Zahl der Meldungen, die jemand prüfen, priorisieren und bis zu einem sicheren Fix verfolgen muss.

Mehr Funde bedeuten noch nicht mehr Sicherheit

OpenAI meldet für Codex Security mehr als 30 Millionen untersuchte Commits in über 30.000 Codebasen. Menschliche Prüfer markierten mehr als 70.000 Findings als behoben; weitere 500.000 wurden automatisiert als behoben erkannt. Diese Größenordnung zeigt das Potenzial, aber auch die neue Last.

Anthropic beschreibt das Problem noch deutlicher. Das Unternehmen ließ 1.752 zunächst hoch oder kritisch eingestufte Findings durch sechs externe Sicherheitsfirmen oder eigene Fachleute prüfen. Daneben wurden auf Wunsch von Maintainern 1.129 Findings ohne vorherige Prüfung weitergegeben. Von 530 gemeldeten hoch oder kritisch bewerteten Schwachstellen waren zum Berichtszeitpunkt 75 gepatcht und 65 mit einem öffentlichen Advisory versehen.

Nicht die Rechenleistung hält den Prozess auf, sondern die anschließende Arbeit aus Validierung, Abstimmung, Entwicklung, Tests und Veröffentlichung.

KI erzeugt nicht nur Erkenntnis, sondern auch Prüfaufwand

Hohe Trefferzahlen klingen zunächst nach einem eindeutigen Fortschritt. Sie müssen jedoch richtig gelesen werden. Von 6.202 durch Mythos Preview zunächst als hoch oder kritisch bewerteten Open-Source-Findings ließ Anthropic 1.752 genauer prüfen. Davon waren 90,6 Prozent echte Schwachstellen; bei 62,4 Prozent bestätigte sich auch die Einstufung als hoch oder kritisch.

Fund und Risikobewertung sind zwei verschiedene Aufgaben.

Ein technisch vorhandener Fehler kann in einem ausgelieferten Produkt unerreichbar sein. Mehrere Agenten können dieselbe Ursache mit unterschiedlichen Symptomen melden. Ein Patchvorschlag kann den Testfall bestehen und trotzdem einen Seiteneffekt erzeugen, den das Modell nicht kennt. Gerade bei proprietären Erweiterungen und kundenspezifischen Konfigurationen fehlt häufig der notwendige Kontext.

Trail of Bits setzt bei „Patch the Planet“ deshalb nicht auf eine ungeprüfte Weiterleitung an Maintainer. Fachleute validieren und deduplizieren Findings, stimmen Prioritäten mit den Projekten ab und prüfen auch die vorgeschlagenen Patches. In der ersten Woche entstanden nach Angaben des Unternehmens für 19 Open-Source-Projekte 64 öffentliche Pull Requests und 51 Issues. 37 Änderungen waren bereits zusammengeführt; nicht alle davon waren Security-Patches.

Das ist die richtige Größenordnung für die Diskussion. Nicht die Zahl gefundener Probleme entscheidet, sondern die Zahl sicher geschlossener Probleme. Selbst ein bestätigter Fund ist damit erst der Anfang. Danach beginnt der Weg durch Produktzuordnung, Patchentwicklung, Tests, Freigabe und Rollout.

Der eigentliche Engpass beginnt nach dem Fund

Bevor aus einem Finding ein Update werden kann, durchläuft es mehrere Entscheidungen. Stimmt die Meldung technisch? Welche Produkte, Versionen und Konfigurationen sind betroffen? Erst mit diesen Antworten lässt sich bewerten, ob der Angriffspfad unter realen Bedingungen erreichbar ist und welches Risiko daraus entsteht.

Auch ein technisch korrekter Patch ist noch nicht fertig. Er muss gebaut, geprüft und gegen bestehende Funktionen getestet werden. Bei einer Bibliothek kann eine kleine Änderung genügen. Bei einem Embedded-System betrifft derselbe Eingriff möglicherweise Bootloader, Firmware-Signatur, Speicherbelegung, Echtzeitverhalten oder die Kommunikation mit anderen Komponenten.

Anschließend braucht es eine Freigabe. Kunden müssen informiert, Security Advisories vorbereitet und Updatepakete verteilt werden. Für Produkte im Feld kommt eine weitere Frage hinzu: Erreicht der Hersteller die betroffenen Installationen überhaupt?

KI kann Teile dieser Kette beschleunigen. Sie ersetzt aber weder Produktkontext noch Verantwortung: Das Modell kennt keine kundenspezifischen Varianten, Wartungsfenster oder Safety-Abhängigkeiten.

Warum industrielle Produkte langsamer reagieren

In einer Webanwendung kann ein Team einen Patch häufig zentral ausrollen und bei Problemen zurücknehmen. Bei Maschinen, Steuerungen und Embedded-Produkten ist der Weg länger.

Viele Systeme bleiben zehn oder zwanzig Jahre im Einsatz. Fremdkomponenten sind fest in Firmwarestände eingebunden, Wartungsfenster knapp und Updates beim Betreiber nicht automatisiert. Manche Anlagen dürfen nur während eines geplanten Stillstands verändert werden. Andere besitzen zwar einen Updateweg, aber keinen belastbaren Prozess für Signaturprüfung, Rückfall oder Versionsnachweis.

Dazu kommen Varianten. Dieselbe Produktfamilie kann mit unterschiedlichen Steuerungen, Betriebssystemständen und kundenspezifischen Erweiterungen ausgeliefert worden sein. Ein Patch muss nicht nur die Schwachstelle schließen. Er darf die Maschine nicht stillsetzen, keine Sicherheitsfunktion verändern und keine Zertifizierung oder Abnahme unterlaufen.

Für Hersteller lautet die entscheidende Frage deshalb nicht: Wie schnell finden wir den Fehler? Sie lautet: Wie schnell können wir einen bestätigten Fehler sicher beheben und die Korrektur nachweisbar in den Bestand bringen?

Wie gut ein Hersteller diese Frage beantworten kann, zeigt sich an der Reife seines Schwachstellenprozesses.

Drei Stufen der Handlungsfähigkeit

Ob mehr KI-Unterstützung einem Unternehmen hilft oder nur den Rückstand vergrößert, hängt vom bestehenden Prozess ab.

Unvorbereitet: Es gibt kein eindeutiges Produkt- und Versionsinventar, keine verwertbare SBOM und keinen geregelten Eingang für externe Meldungen. Neue Findings landen in einzelnen Postfächern oder bei Entwicklern, die nebenbei reagieren sollen.

Teilweise vorbereitet: Scanner, Ticketsystem und technische Ansprechpartner sind vorhanden. Es fehlen aber feste Triage-Kriterien, Freigabefristen oder eine klare Zuordnung zwischen Schwachstelle, Produkt und ausgelieferter Version. Der Prozess funktioniert, solange nur wenige Meldungen gleichzeitig eintreffen.

Handlungsfähig: Produktinventar, SBOM, PSIRT oder eine gleichwertige Verantwortung, Patchprozess, Regressionstests und Kundenkommunikation greifen ineinander. Ein bestätigter Fund erhält einen Verantwortlichen, eine Frist und einen dokumentierten Weg bis zum Rollout.

KI vergrößert den Abstand zwischen diesen Stufen: Ein reifer Prozess kann zusätzliche Funde schneller bewerten, während ein unreifer Prozess zunächst vor allem mehr Tickets bekommt.

Was Hersteller vor dem nächsten großen Fund brauchen

Am Anfang steht ein belastbares Produktinventar, das Produktfamilie, Version, eingesetzte Komponenten und bekannte Installationsstände zusammenführt. Eine SBOM hilft nur, wenn sie aktuell ist und sich einem konkreten Build oder Release zuordnen lässt. Wie sie in den Produktlebenszyklus und das Vulnerability Handling eingebunden wird, zeigt auch der aktuelle DIN-EN-40000-Normenrahmen.

Danach braucht es einen zentralen Eingang für Findings. Das kann ein PSIRT, eine definierte Security-Rolle oder ein kleiner fester Kreis aus Entwicklung, Produktmanagement und IT-Sicherheit sein. Wichtig ist nicht die Bezeichnung, sondern die Fähigkeit, Meldungen anzunehmen, zu bewerten und verbindlich weiterzugeben.

Triage-Regeln schaffen Geschwindigkeit. Sie legen fest, welche Nachweise ein Finding braucht, wann eine Schwachstelle eskaliert wird und wie Erreichbarkeit, Auswirkung sowie bereits vorhandene Schutzmaßnahmen in die Bewertung einfließen.

Für die Behebung sind reproduzierbare Builds und automatisierte Regressionstests entscheidend. Ohne sie bleibt jeder Patch ein Einzelprojekt. Ebenso wichtig sind signierte Updatepakete, ein definierter Freigabeweg und ein Kanal, über den Kunden rechtzeitig erreicht werden.

Erst auf diesem Fundament kann KI die Behebung beschleunigen. Fehlt es, füllt sie hauptsächlich den Eingangskorb.

KI sollte auch die Behebung beschleunigen

Wer KI nur für die Suche einsetzt, automatisiert die falsche Hälfte des Problems. Mehr Nutzen entsteht dort, wo dieselben Werkzeuge Triage und Behebung unterstützen und vorhandene Übergaben verkürzen.

Ein Modell kann ähnliche Meldungen zusammenführen, betroffene Komponenten eingrenzen und zusätzliche Testfälle erzeugen. Es kann einen Patchentwurf mit dem ursprünglichen Fehlerbild verknüpfen, Varianten vergleichen und Entwürfe für Security Advisories oder Release Notes vorbereiten. In gut aufgebauten Entwicklungsumgebungen lässt sich so ein Teil der manuellen Übergaben vermeiden.

Die Grenzen bleiben klar. Risikobewertung, Freigabe und Verantwortung liegen beim Hersteller. Vor allem bei OT- und Safety-relevanten Produkten darf ein automatisch erzeugter Patch nicht direkt in Produktion oder Feldbetrieb gelangen.

Geschwindigkeit ist eine Prozesseigenschaft

GPT-5.5-Cyber und die zuvor mit Mythos Preview demonstrierten Fähigkeiten markieren keinen Moment, ab dem Sicherheitsforscher überflüssig werden. Sie zeigen, dass ein bisher knapper Teil der Arbeit skalierbarer wird. Damit steigt der Druck auf alles, was danach kommt.

Unternehmen brauchen deshalb nicht einfach den nächsten KI-Scanner. Sie brauchen einen Prozess, der aus einem plausiblen Fund eine belastbare Entscheidung und aus einer bestätigten Schwachstelle einen sicher ausgelieferten Patch macht.

Die wichtigste Kennzahl ist nicht, wie viele Schwachstellen ein System findet. Entscheidend ist, wie lange ein bestätigter Fund offenbleibt.

Ich prüfe mit Herstellern in Ulm, Günzburg, Augsburg und deutschlandweit den vorhandenen Weg vom Finding bis zum Fix: Wo bleibt Arbeit liegen, welche Verantwortung fehlt und wie lässt sich die Zeit bis zum getesteten Patch verkürzen? Der Einstieg lässt sich mit einer CRA- und MVO-Gap-Analyse verbinden, muss aber nicht auf Regulierung warten.

Quellenstand