Dabei geht es nicht um eine Verdopplung der Leistung gegenüber dem Vorgänger. Mythos ist um mehrere Größenordnungen besser darin, Zero-Day-Schwachstellen zu finden. Firefox-Exploit-Benchmarks zeigen eine 90-fache Steigerung im Vergleich zu Opus 4.6: Mozilla Firefox fand mit Opus 4.6 insgesamt 22 Sicherheitslücken, während Mythos vollständig unbeaufsichtigt 271 Schwachstellen identifizierte. Mythos hat außerdem Fehler gefunden, die menschliche Tests und automatisierte Prüfungen seit über 20 Jahren überstanden hatten – und kann diese Schwachstellen nach ihrer Entdeckung ohne nennenswerte menschliche Anleitung automatisch ausnutzen.
Mozilla hat bereits einen Patch veröffentlicht, der alle 271 von Mythos gefundenen Schwachstellen abdeckt. Die Version „Firefox 150″ wurde maßgeblich durch die Erkenntnisse von Mythos angestoßen und stellte das Mozilla-Team vor eine ernsthafte Bewährungsprobe.
Der CTO von Mozilla erklärte dazu, dass Mythos keine Schwachstelle gefunden habe, die ein hochqualifizierter Mensch nicht irgendwann ebenfalls hätte finden können – der entscheidende Unterschied liegt in der Geschwindigkeit, mit der Mythos dies getan hat.
Warum betrifft das Hersteller, und was ist Project Glasswing?
Die von Mythos gefundenen Schwachstellen betreffen Betriebssysteme, Webbrowser, Open-Source-Bibliotheken und andere eingebettete Software-Infrastrukturen. Während ein normaler Benutzer vielleicht nie mit „FFmpeg libraries“ oder „JIT compilers“ in Berührung kommt, werden diese Tools im Hintergrund von gängigen Anwendungen und Webbrowsern genutzt – und können durch KI-Tools automatisch und in großem Maßstab angesprochen werden.
Angesichts dieser Ergebnisse stuft Anthropic Mythos als Cybersicherheitsbedrohung ein und hat die öffentliche Veröffentlichung zurückgestellt. Stattdessen wurde Project Glasswing ins Leben gerufen, um großen Entwicklungsunternehmen einen Vorsprung beim Schließen kritischer Sicherheitslücken zu verschaffen. Diese reichen vom Diebstahl privater Browserdaten bis hin zur Möglichkeit, Hackern Zugriff auf systemweite Steuerungsfunktionen außerhalb eines Browsers zu verschaffen. Zu den Unternehmen, die an Project Glasswing teilnehmen, gehören Google, Microsoft, Apple und weitere.
Die Frage ist nicht mehr ob solche Tools Schwachstellen in unserer Software finden werden – sondern wo und wann.
Welche Auswirkungen hat das auf Hersteller, insbesondere Medizintechnikunternehmen?
Der Einsatz von KI zur Identifizierung und Ausnutzung von Schwachstellen wird in allen betroffenen Systemen einen enormen Rückstand an erforderlichen Patches erzeugen.
Als Hersteller entsteht dadurch mehr als ein Druckpunkt. Zunächst und am offensichtlichsten müssen Patches entwickelt, validiert, getestet und veröffentlicht werden. Diese Patches entstehen nicht zufällig – Risikomanagementprozesse müssen gemäß ISO 14971 dokumentiert werden. Dies schafft nicht nur Transparenz, sondern ermöglicht es Entwicklerteams auch, zu priorisieren, welche Schwachstellen zuerst behoben werden sollen. Mit jeder weiteren Patch-Version muss die technische Dokumentation aktualisiert werden. Falls erforderliche Änderungen die Systemarchitektur oder Arbeitsabläufe betreffen, gelten sie in der Regel als wesentliche Änderungen, und die Einbindung einer benannten Stelle wird erforderlich.
All dies erfolgt gemäß IEC 62304, die auch Aktivitäten der Marktüberwachung berücksichtigt.
Was können Hersteller tun, um sich vorzubereiten?
Mythos wird sicherlich nicht das letzte seiner Art sein – Anthropic rechnet mit der Veröffentlichung ähnlicher Modelle innerhalb von 6 bis 18 Monaten. Der Einsatz von KI zur Erkennung und Ausnutzung von Schwachstellen ist kein einmaliges Ereignis, sondern wird das gesamte Feld in ein schnelleres Katz-und-Maus-Spiel verwandeln. Die Zeitspanne zwischen der Entdeckung einer Schwachstelle und dem Moment, in dem sie ausgenutzt werden kann, verkürzt sich erheblich. Das bedeutet, dass auch die Zeitspanne zwischen der Entdeckung einer Schwachstelle und der Veröffentlichung eines Patches reduziert werden muss. Wie geht man das an?
Hersteller müssen ihr Denken ändern:
Weg von „Wir veröffentlichen einen Patch, sobald sich genug Fehler angesammelt haben und der Aufwand gerechtfertigt ist“ hin zu „Wir brauchen eine kontinuierliche Sicherheitspflege“. Um diesen Prozess zu optimieren, müssen QMS-Tools definiert werden, die zwischen Releases mit wesentlichen Änderungen und solchen, die reine Sicherheits-Patches betreffen, unterscheiden. Welche Dokumentation ist für Sicherheits-Patch-Releases erforderlich, wie viel Testing muss durchgeführt werden, und ob eine benannte Stelle einbezogen werden muss oder nicht.
Im Rahmen der MDR muss die Folgenabschätzung klar definiert sein. Ändert sich die Benutzerinteraktion? Werden neue Gefährdungen eingeführt? Das sind einige Fragen, die sofort klären können, ob eine Änderung wesentlich ist oder nicht.
Abschließend sollten Unternehmen proaktiv KI-Tools defensiv einsetzen, um Code-Reviews durchzuführen. Dies verschiebt den Fokus von einem reaktiven Arbeitsablauf hin zu einem System, das kontinuierlich auf Sicherheitsverbesserungen abzielt. Solche Maßnahmen können dazu beitragen, dass sich der Ton in Gesprächen mit benannten Stellen von der Einholung einer Genehmigung hin zu einer bloßen Änderungsmitteilung verlagert.
Lamborghini Sotelo | AI Consultant
