Project Glasswing: Was Mythos unter Beweis gestellt hat

In den letzten Monaten haben wir auf unserer eigenen Infrastruktur eine Reihe von sicherheitsbezogenen LLM getestet. Sie helfen uns beim Aufspüren zu behebender Schwachstellen in unseren eigenen Systemen. Außerdem zeigen sie auf, wozu Angreifer mit den neuesten Modellen in der Lage sind.

Keines dieser LLM hat mehr Aufmerksamkeit erregt als Mythos Preview von Anthropic. Vor ein paar Wochen wurden wir eingeladen, Mythos Preview im Rahmen von Project Glasswing zu verwenden. Schon bald haben wir die Lösung auf mehr als fünfzig unserer eigenen Repositorys angesetzt. Wir wollten sehen, was sie finden würde und wie sie funktioniert.

An dieser Stelle wollen wir unsere Beobachtungen beschreiben und darauf eingehen, wo sich die Modelle gut geschlagen haben und wo nicht. Außerdem beschäftigen wir uns mit der Frage, wie die Architektur und Prozesse, die sie umgeben, angepasst werden müssen, damit sie in großem Stil eingesetzt werden können.

Mythos Preview stellt einen echten Fortschritt dar, das wollen wir hier zunächst klipp und klar feststellen. Wir legen unseren Programmcode schon seit einiger Zeit solchen Modellen vor. Deshalb können wir sagen, dass die heutige Performance von Mythos Preview mehr als eine Verfeinerung dessen ist, wozu frühere allgemeine Frontier-Modelle in der Lage waren – hier wurde ein echter Sprung vollzogen.

Wir haben es mit einer anderen Art von Werkzeug zu, das eine andere Art von Arbeit verrichtet. Das erschwert den direkten Vergleich mit früheren Modellen. Anstatt Mythos Preview allgemeinen Frontier-Modellen gegenüberzustellen, ist es zielführender, zu beschreiben, was die Lösung tatsächlich leisten kann. Zwei Funktionen sind uns bei unserer Arbeit mit Mythos Preview besonders aufgefallen:

• Erstellung einer Exploit-Kette: Ein echter Angriff stützt sich selten nur auf einen einzigen Fehler im System. Vielmehr werden mehrere kleinere Elemente zu einem wirksamen Exploit verknüpft. So könnte beispielsweise ein „Use After Free“-Fehler in eine beliebige Lese- und Schreiboperation umgewandelt, der Kontrollfluss gekapert und mithilfe von ROP (Return-Oriented Programming)-Ketten die vollständige Kontrolle über ein System übernommen werden. Mythos Preview ist in der Lage, mehrere dieser Einzelbausteine zu berücksichtigen und abzuleiten, wie sie sich zu einem echten Verwundbarkeitsnachweis kombinieren lassen. Die dabei dargelegte Argumentationskette ähnelt der Arbeit eines erfahrenen Experten, nicht dem von einem automatischen Scanner gelieferten Ergebnis.

• Erstellung von Nachweisen: Einen Fehler aufzuspüren und nachzuweisen, dass er ausgenutzt werden kann, sind zwei Paar Schuhe. Mythos Preview kann beides. Das Produkt schreibt ein Programm, das den vermuteten Fehler auslösen würde, kompiliert diesen Quellcode in einer Testumgebung und führt ihn aus. Wenn sich das Programm so verhält wie vom Modell erwartet, ist der Nachweis erbracht. Ist das nicht der Fall, erfasst das Modell den Fehler, passt seine Hypothese an und versucht es erneut. Dieser Kreislauf hat ebenso große Bedeutung wie die aufgespürten Fehler, denn eine vermutete Schwäche ohne praktischen Beleg ist lediglich Spekulation. Mythos Preview schließt diese Lücke eigenständig.

Einiges von dem, was wir gerade beschrieben haben, ist nicht auf Mythos Preview beschränkt. Andere dem gleichen Testverfahren unterzogenen Frontier-Modelle haben eine große Zahl derselben zugrunde liegenden Fehler aufgespürt und in manchen Fällen sind sie auch in ihrer Argumentation weitergekommen als von uns erwartet. Wo sie jedoch nicht überzeugt haben, war beim Zusammensetzen der Einzelteile. So haben einzelne Modelle einen interessanten Bug identifiziert, eine gut durchdachte Erklärung dazu verfasst, warum dieser von Bedeutung ist, es dann jedoch dabei belassen. Die begonnene Argumentationskette blieb unvollendet und die Frage der Ausnutzbarkeit wurde nicht beantwortet. Anders sieht das mit Mythos Preview aus: Ein Modell kann nun eine Reihe harmloser erscheinender Fehler (die normalerweise unsichtbar auf ihre Bearbeitung warten) zu einem einzigen, schwerwiegenderen Exploit verknüpfen. 

Das von Anthropic im Rahmen von Project Glasswing bereitgestellte Mythos Preview-Modell weist nicht die zusätzlichen Schutzvorkehrungen auf, mit denen die der Allgemeinheit zugänglichen Modelle (wie Opus 4.7 oder GPT-5.5) ausgestattet sind.

Trotzdem widersetzt sich das Modell bestimmten Anfragen organisch. Ähnlich wie seine für die Jagd auf Schwachstellen nützlichen Cyberfunktionen enthält es eigene, sich entwickelnde Schutzmechanismen. Aufgrund dieser widersetzt es sich manchmal legitimen Anfragen, die der Sicherheitsforschung dienen. Allerdings haben wir festgestellt, dass diese organischen Ablehnungen keinem bestimmten Muster folgen: Wird dieselbe Aufgabe anders formuliert oder in einem anderen Kontext präsentiert, kann sie zu völlig unterschiedlichen Ergebnissen führen. Dies ist veranschaulichen die folgenden Beispiele.

^{Beispiel für eine Weigerung von Mythos Preview, ein funktionierendes Proof of Concept zu erstellen} 

Das Modell hat sich beispielsweise zunächst geweigert, Schwachstellenforschung für ein Projekt durchzuführen. Nach einer nicht damit in Verbindung stehenden Änderung an der Projektumgebung hat es dann aber derselben Forschung am gleichen Quellcode doch zugestimmt. An dem zu analysierenden Programmcode hatte sich nichts geändert. In einem anderen Fall hat das Modell mehrere schwerwiegende Speicherfehler in einer Codebasis gefunden und bestätigt, sich aber geweigert, einen Exploit zu Demonstrationszwecken zu erstellen. Anders formuliert ergab die gleiche Anfrage jedoch eine andere Antwort. Selbst ohne Umformulierung kann die gleiche Anfrage aufgrund der probabilistischen Natur des Modells bei verschiedenen Durchläufen unterschiedliche Ergebnisse liefern. Semantisch gleichwertige Aufgaben können entgegengesetzte Ergebnisse hervorbringen, je nachdem, wie und wann sie dem Modell vorgelegt werden.

Das ist deshalb von Bedeutung, weil organische Verweigerungen / Schutzmaßnahmen innerhalb des Modells zwar vorkommen, aber nicht so konsequent sind, dass sie als alleinige Grenzlinie geeignet wären. Aus diesem Grund muss jedes gut funktionierende Frontier-Cybermodell, das künftig der breiten Öffentlichkeit zur Verfügung gestellt wird, über dieses grundlegende Verhalten hinaus zusätzliche Sicherheitsmaßnahmen umfassen. Nur dann ist es für einen weiter gefassten Einsatz außerhalb eines kontrollierten Forschungskontexts wie dem von Project Glasswing geeignet.

Bei der Priorisierung von Sicherheitslücken besteht eine der schwierigsten Aufgaben darin, zu entscheiden, welche Fehler real sind, welche ausgenutzt werden könnten und welche sofort behoben werden müssen. Das war schon in einer Zeit vor Existenz der KI eine große Herausforderung. KI-gestützte Schwachstellenscanner und KI-generierter Quellcode haben das Problem nun noch verschärft. Um es zu meistern, haben wir bei Cloudflare etliche Nachprüfungsstufen entwickelt.

Zwei Faktoren sind bezüglich der Störsignale besonders wichtig:

• Programmiersprache: C und C++ geben Ihnen direkte Kontrolle über den Speicher und damit Fehlerklassen (wie Pufferüberläufe, Lese- und Schreibvorgänge außerhalb des zulässigen Bereichs), die bei speichersicheren Sprachen wie Rust zur Kompilierungszeit beseitigt werden. Bei Projekten, die in nicht speichersicheren Sprachen geschrieben wurden, haben wir durchgehend mehr Fehlalarme verzeichnet.

• Modellbefangenheit: Ein guter menschlicher Forscher sagt Ihnen, was er gefunden hat und wie sicher er sich diesbezüglich ist. Modelle tun das nicht. Wenn Sie ein Modell auffordern, Fehler zu finden, wird es das tun – unabhängig davon, ob der Programmcode tatsächlich welche enthält oder nicht. Die Antworten beinhalten dann einfach weitaus häufiger Einschränkungen wie „möglicherweise“, „potenziell“, „könnte theoretisch“ und die Zahl der verlässlichen Ergebnisse ist deutlich niedriger. Diese Schieflage ist bei einem Werkzeug, das zur Erkundung gedacht ist, durchaus sinnvoll. Doch bei einer Warteschlange mit Fehlern, über deren Dringlichkeit entschieden werden muss, ist sie fatal. Denn die Überprüfung solcher spekulativen Befunde bindet menschliche Aufmerksamkeit und verschlingt eine große Zahl von Token, was bei tausendfacher Wiederholung die Kosten schnell in die Höhe treibt.

Mythos Preview stellt hier insbesondere aufgrund der Fähigkeit des Modells, Einzelelemente miteinander zu verketten, eine deutliche Verbesserung dar. Denn so können mehrere Schwachstellen in ein funktionierendes Proof of Concept (PoC) integriert werden, anstatt sie isoliert zu melden. Auf einen Befund, bei dem das PoC gleich mitgeliefert wird, können Sie reagieren. Somit verbringen Sie weit weniger Zeit damit, sich zu fragen, ob der Fehler überhaupt existiert.

Unsere Systeme sind bewusst so eingestellt, dass sie zu viele Warnmeldungen generieren, damit wir mehr erkennen (und weniger übersehen). Allerdings geht das auch mit erheblich mehr Störsignalen einher. Bei der Triage erweisen sich die Ergebnisse von Mythos Preview aber als von spürbar höherer Qualität: weniger vage Befunde, klarere Schritte für das Nachvollziehen und ein geringer Aufwand bei der Entscheidung, ob etwas behoben werden muss oder ignoriert werden kann.

Als wir im letzten Jahr mit der KI-gestützten Erforschung von Schwachstellen begonnen haben, war unser naheliegende Instinkt, einen allgemeinen Coding-Agenten auf ein beliebiges Repository anzusetzen und ihn darin nach Schwachstellen suchen zu lassen. Das funktioniert insofern, als das Modell Ergebnisse liefert. Diese Vorgehensweise erlaubt aber weder eine sinnvolle Abdeckung einer echten Codebasis noch die Gewinnung nützlicher Erkenntnisse. Das hat vor allem zwei Gründe:

• Kontext: Programmier-Agenten sind auf ein klar abgegrenztes Aufgabenfeld ausgelegt: eine Funktion entwickeln, einen Fehler beheben, das Programm für ein Refactoring verfassen. Sie verarbeiten eine große Menge Quellcode, prüfen jeweils nur eine einzige Hypothese und führen darauf basierend Iterationen durch. Das ist jedoch genau der falsche Ansatz für die Schwachstellenforschung, die von Natur aus eng gefasst und parallel verläuft. Ein menschlicher Forscher wählt ein bestimmtes Problemfeld aus, das er gründlich untersucht. Dabei kann es sich um eine einzelne komplexe Funktion handeln, um das Übertreten von Sicherheitsschwellen oder um eine bestimmte Kategorie von Schwachstellen wie Befehlsinjektionen, bei denen Eingaben des Angreifers als Shell-Befehl ausgeführt werden. Dann wird der Vorgang für eine andere Funktion, Sicherheitsschwelle oder Schwachstellenkategorie wiederholt – mehrere tausend Mal für den gesamten Quellcode. Eine einzelne Agenten-Sitzung (selbst mit Unteragenten) bei einem Repository mit hunderttausend Zeilen kann vielleicht ein Zehntelprozent der Oberfläche sinnvoll abdecken, bevor sich das Kontextfenster des Modells füllt und die Komprimierung einsetzt – wodurch möglicherweise frühere, relevante Ergebnisse verworfen werden.

• Durchsatz: Ein Single-Stream-Agent führt jeweils nur eine Aufgabe aus, doch für echte Codebasen sind viele Hypothesen in Bezug auf zahlreiche Komponenten gleichzeitig erforderlich – mit der Möglichkeit weiterer Verzweigungen, falls sich etwas Interessantes ergibt. Man kann einen einzelnen Agenten zwar stärker beanspruchen, aber ab einem bestimmten Punkt wird man nicht mehr durch das Modell eingeschränkt, sondern durch die Form der Interaktion selbst. Die direkte Verwendung des Modells in einem Programmier-Agenten erweist sich als gut geeignet für händische Untersuchungen, wenn ein Forscher bereits eine Spur hat und eine zweite Meinung einholen möchte. Es ist jedoch das falsche Werkzeug, wenn eine hohe Abdeckung erreicht werden soll. Als wir das eingesehen hatten, haben wir aufgehört, Mythos Preview für die falsche Aufgabe einzusetzen. Stattdessen haben wir begonnen, das Gerüst darum herum zu erschaffen.

Aus der Durchführung des Projekts in großem Maßstab haben wir vier Erkenntnisse gewonnen. Diese lassen alle darauf schließen, dass zur Steuerung der gesamten Ausführung ein Grundgerüst erforderlich ist:

• Ein begrenzterer Fokus führt zu besseren Ergebnissen: Wenn man dem Modell die Anweisung „Finde Schwachstellen in diesem Repository“ gibt, lässt man es im Trüben fischen. Sagt man ihm hingegen „Such nach Befehlsinjektionen in dieser bestimmten Funktion, mit dieser darüber liegenden Vertrauensgrenze; hier sind die Architekturdokumentation und die bisherige Berichterstattung zu diesem Bereich“, führt es etwas aus, was der tatsächlichen Vorgehensweise eines Forschers viel stärker ähnelt.

• Gegenprüfung reduziert Störsignale: Durch Einfügen eines zweiten Agenten – mit einem anderen Prompt, einem anderen Modell und ohne die Fähigkeit, eigene Ergebnisse zu erzeugen – zwischen dem ursprünglichen Ergebnis und der Warteschlange werden viele Störsignale abgefangen, die der erste Agent übersehen würde, wenn er lediglich seine eigene Arbeit überprüfen würde. Es hat sich herausgestellt, dass es weitaus effektiver ist, zwei Agenten bewusst in Widerspruch zueinander zu bringen, als nur einem Agenten zu sagen, er solle vorsichtig sein.

• Die Aufteilung der Kette auf verschiedene Agenten führt zu besseren Schlussfolgerungen: „Enthält dieser Code Fehler?“ und „Kann ein Angreifer diesen Fehler tatsächlich von außerhalb des Systems aus erreichen?“ sind zwei unterschiedliche Fragen. Das Modell liefert für jede einzelne Frage bessere Ergebnisse, wenn man sie getrennt stellt, da jede Frage enger gefasst ist als eine kombinierte Version.

• Parallele, eng gefasste Aufgaben liefern bessere Ergebnisse als ein einziger, umfassender Agent: Die Abdeckung verbessert sich, wenn viele Agenten an eng gefassten Fragen arbeiten und man die Ergebnisse anschließend zusammensetzt, anstatt einen übergeordneten Agenten mit der gesamten Frage zu betrauen.

Jede dieser Beobachtungen betrifft das Modellverhalten und zusammengenommen beschreiben sie etwas, das keine Chat-Oberfläche mehr ist. Es handelt sich um ein Grundgerüst, das dabei hilft, zu den endgültigen Ergebnissen zu gelangen. Die ersten Schritte zum Erstellen dieses Gerüsts sind leicht, da man das Modell um Unterstützung bitten kann. Genau das haben wir getan: Wir haben Mythos Preview zur Anpassung und Verbesserung unserer ursprünglichen Gerüste eingesetzt, um ihre Stärken optimal nutzen zu können. Ein Beispiel dafür, wie ein solches Grundgerüst in der Praxis aussieht, wird unten beschrieben.

Hier ist unser Gerüst zur Ermittlung von Schwachstellen – Abschnitt für Abschnitt. Damit wurde Produktivcode in unserer Laufzeitumgebung, dem Edge-Datenpfad, dem Protokoll-Stack, der Steuerungsebene und den Open Source-Projekten, auf die wir zurückgreifen, gescannt.

Phase	Vorteil	Warum das wichtig ist
Auskundschaftung	Ein Agent liest das Repository von oben nach unten, weist die Aufgaben den für die einzelnen Teilsysteme zuständigen Unteragenten zu und erstellt eine Architekturdokumentation mit Build-Befehlen, Vertrauensgrenzen, Einstiegspunkten und der voraussichtlichen Angriffsfläche. Zudem generiert er die ursprüngliche Aufgabenwarteschlange für die nächste Phase.	Stellt jedem nachgelagerten Agenten einen gemeinsamen Kontext zur Verfügung. Löst das Problem des Herumstocherns im Nebel.
Bedrohungsjagd	Jede Aufgabe besteht aus einer Angriffsklasse in Verbindung mit einem Hinweis zum Anwendungsbereich. Jäger (die Agenten, die tatsächlich nach Fehlern suchen) laufen parallel, in der Regel etwa fünfzig gleichzeitig, wobei sich jeder in eine Handvoll Erkundungs-Unteragenten aufteilt. Jeder Jäger hat Zugriff auf Werkzeuge, die Proof of Concept-Quellcode in einem aufgabenbezogenen Arbeitsverzeichnis kompilieren und ausführen.	Hier findet der Hauptteil der Arbeit statt. Viele eng gefasste Einzelaufgaben werden parallel abgearbeitet, nicht durch einen einzigen allumfassenden Agenten.
Kontrolle	Ein unabhängiger Agent liest den Quellcode erneut und versucht, den ursprünglichen Befund zu widerlegen. Ihm wird eine andere andere Eingabeaufforderung gegeben und er hat keine Möglichkeit, eigene neue Erkenntnisse zu generieren.	Fängt einen bedeutenden Teil der Störsignale ab, die dem Jäger bei der Überprüfung seiner eigenen Arbeit entgehen würde.
Schließung von Lücken	Jäger kennzeichnen Bereiche, mit denen sie in Berührung gekommen sind, die sie aber nicht vollständig untersucht haben. Diese Bereiche werden für einen weiteren Durchgang in eine Warteschlange aufgenommen.	Wirkt der Tendenz des Modells entgegen, sich auf Angriffsklassen zu konzentrieren, bei denen es bereits Erfolge verzeichnet hat.
Beseitigung von Dubletten	Befunde, die auf dieselbe Ursache verweisen, werden zu einem einzigen Datensatz zusammengefasst.	Die Variantenanalyse ist eine Funktion und kein Mittel, um die Warteschlange mit Dubletten zu überfrachten.
Nachverfolgung	Für jeden bestätigten Befund in einer gemeinsam genutzten Bibliothek wird ein Nachverfolgungs-Agent gestartet (eine Instanz pro Endnutzer-Repository). Dieser verwendet einen repositoryübergreifenden Symbolindex und ermittelt, ob vom Angreifer kontrollierte Eingaben von außerhalb des Systems den Fehler tatsächlich erreichen.	So wird aus „es gibt eine Schwachstelle“ die Erkenntnis „es gibt eine ausnutzbare Schwachstelle“. Dies ist die entscheidende Phase.
Feedback	Aus erreichbaren Spuren werden neue Suchaufgaben in den Repositorys der Endnutzer, in denen der Fehler tatsächlich auftritt.	Damit schließt sich der Kreis. Je länger die Pipeline in Betrieb ist, desto besser das Ergebnis.
Berichterstattung	Ein Agent verfasst einen strukturierten Bericht nach einem vordefinierten Schema, behebt alle Validierungsfehler gemäß diesem Schema und übermittelt den Bericht an eine API zur Datenaufnahme.	Das Ergebnis ist kein frei formulierter Text, sondern Daten, die abgefragt werden können.

Die deutlichsten Reaktionen anderer Sicherheitsverantwortlicher auf Mythos Preview betrafen die Geschwindigkeit: schnelleres Scannen und Patchen ermöglichen eine Verkürzung des Reaktionszyklus. Mehr als ein Team, mit dem wir gesprochen haben, arbeitet mittlerweile nach einem SLA von zwei Stunden von der CVE-Veröffentlichung bis zum Patch im Produktivbetrieb. Der Ansatz ist verständlich: Wenn sich der Zeitrahmen für Angreifer verkürzt, müssen die Verteidiger mithalten. Doch Beschleunigung allein wird nicht ausreichen. Unserer Meinung nach sind viele Teams im Begriff, viel Zeit, Mühe und Geld darauf zu verwenden, dies auf die harte Tour zu lernen.

Schnellere Fehlerbehebung ändert nichts an der Struktur der Pipeline, die den Patch erzeugt. Wenn Regressionstests einen Tag dauern, lässt sich ein SLA von zwei Stunden nicht einhalten, ohne diese Tests zu überspringen – und die Fehler, die man beim Auslassen der Regressionstests in Kauf nimmt, sind in der Regel schwerwiegender als diejenigen, die man eigentlich beheben wollte. Wir haben eine ähnliche Erfahrung gemacht, als wir versuchten, das Modell seine eigenen Patches erstellen zu lassen. Dabei konnten wir beobachten, das in einigen Fällen zwar der ursprüngliche Fehler behoben, unbemerkt aber etwas anderes beschädigt wurde, wovon der Code abhängig war.

Die schwierigere Frage ist, wie die Architektur rund um die Sicherheitslücke aussehen sollte. Das Prinzip besteht darin, einem Angreifer die Ausnutzung zu erschweren, selbst wenn ein Fehler vorliegt. So verliert nämlich der Zeitraum zwischen der Bekanntgabe einer Sicherheitslücke und ihrer Behebung an Bedeutung. Dies bedeutet, dass Abwehrmaßnahmen, die eine Ausnutzung des Fehlers verhindern, der Applikation vorgeschaltet werden. Es bedeutet, die Anwendung so zu gestalten, dass ein Fehler in einem Teil des Quellcodes einem Angreifer keinen Zugriff auf andere Teile davon ermöglicht. Es bedeutet, in der Lage zu sein, einen Fix an jedem Ort, an dem der Quellcode ausgeführt wird, gleichzeitig bereitzustellen, anstatt darauf zu warten, dass die einzelnen Teams ihn implementieren. 

Wir erkennen an, dass dieses Thema in beide Richtungen Auswirkungen hat. Die gleichen Funktionen, die uns dabei geholfen haben, Fehler in unserem eigenen Programmcode zu finden, erleichtern in den falschen Händen Angriffe auf jede Anwendung im Internet. Cloudflare ist Millionen dieser Applikationen vorgeschaltet und die oben beschriebenen Architekturprinzipien sind genau diejenigen, die unsere Produkte im Auftrag unserer Kunden anwenden sollen. In den kommenden Wochen werden wir näher darauf eingehen, was das für unsere Kunden bedeutet.

Falls Ihr Team an ähnlichen Projekten arbeitet und sich darüber austauschen möchte, schreiben Sie uns einfach an security-ai-research@cloudflare.com.

Unsere Forschungsarbeiten mit Mythos Preview wurden in einer kontrollierten Umgebung auf Grundlage unserer eigenen Programmierrichtlinien durchgeführt. Jede dabei aufgedeckte Sicherheitslücke wurde im Rahmen des formellen Schwachstellenmanagements von Cloudflare geprüft, validiert und, sofern erforderlich, behoben.

Es handelt sich um eine Teamleistung. Herzlichen Dank an Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl und Rohit Chenna Reddy für ihre diesem Blogbeitrag zugrunde liegenden Beiträge zur Recherche, technischen Umsetzung und Auswertung.