Project Glasswing: Was Mythos gezeigt hat

• Mythos Preview ging in mehr als 50 Repositories von Cloudflare über die reine Erkennung einzelner Bugs hinaus und verknüpfte mehrere primitive Bausteine zu Exploit-Ketten
• Es blieb nicht bei der Erkennung verdächtiger Bugs, sondern schrieb Trigger-Code, kompilierte und führte ihn provisorisch aus und passte nach Fehlschlägen die Hypothesen wiederholt an, um einen Funktionsnachweis zu erzeugen
• Selbst bei legitimer Schwachstellenforschung zeigte das Modell spontane Verweigerungen, doch diese hingen von Kontext und Formulierung ab und waren daher zu inkonsistent, um als Sicherheitsgrenze zu dienen
• Allzweck-Coding-Agenten haben Grenzen bei der Abdeckung großer Repositories und bei paralleler Exploration; deshalb baute Cloudflare ein Harness, das eng umrissene Aufgaben parallel ausführt
• Für Security-Teams reichen schnelleres Scannen und Patchen allein nicht aus; wichtiger wird eine Architektur, die Exploits und Erreichbarkeit erschwert, selbst wenn Bugs vorhanden sind

---

Wie Mythos Preview die Schwachstellenforschung verändert hat

• Cloudflare testete in den vergangenen Monaten sicherheitsfokussierte LLMs in der eigenen Infrastruktur und setzte Anthropic's Mythos Preview als Teil von Project Glasswing in mehr als 50 eigenen Repositories ein
• Mythos Preview war weniger eine einfache Verbesserung bestehender allgemeiner Frontier-Modelle als vielmehr ein neues Werkzeug, das andere Phasen der Schwachstellenforschung übernimmt
• Die zentrale Veränderung besteht darin, nicht bei der Auflistung einzelner Bugs stehenzubleiben, sondern mehrere Angriffs-Primitive zu einer Exploit-Kette zusammenzufügen
  • Reale Angriffe nutzen meist nicht nur einen einzelnen Bug, sondern verwandeln etwa ein Use-after-free in Primitive für beliebiges Lesen und Schreiben, übernehmen den Kontrollfluss und erlangen per ROP-Kette die Systemkontrolle
  • Mythos Preview kombinierte solche Primitive zu funktionierenden Nachweisen und zeigte damit eher ein Schlussfolgern wie ein erfahrener Forscher als wie ein automatischer Scanner
• Eine weitere Veränderung ist die Fähigkeit, nach dem Auffinden eines verdächtigen Bugs selbst einen Funktionsnachweis zu erstellen
  • Es schreibt Trigger-Code, kompiliert ihn in einer temporären Umgebung und führt ihn aus
  • Funktioniert er wie erwartet, ist das der Nachweis; scheitert er, liest es den Fehler, passt die Hypothese an und versucht es erneut
  • Ein Defekt ohne funktionierenden Nachweis bleibt Spekulation, doch Mythos Preview verringerte diese Lücke eigenständig
• Andere Frontier-Modelle im selben Harness fanden ebenfalls einige grundlegende Bugs und schlussfolgerten teils weiter als erwartet, doch beim Zusammenfügen mehrerer Teile zu einer realen Kette zeigte sich der Unterschied
• Mythos Preview konnte Bugs, die traditionell mit niedriger Schwere im Backlog gelandet wären, zu einem schwerwiegenderen Exploit verbinden

Modellverweigerungen selbst bei legitimer Schwachstellenforschung

• Das für Project Glasswing bereitgestellte Mythos Preview enthielt nicht die zusätzlichen Sicherheitsmechanismen allgemein verfügbarer Modelle wie Opus 4.7 oder GPT-5.5
• Trotzdem widersetzte sich das Modell bestimmten Anfragen spontan und zeigte neben nützlichen Cyber-Fähigkeiten bei der Schwachstellensuche auch emergente Guardrails
• Diese spontane Verweigerung war nicht konsistent
  • Dieselbe Aufgabe konnte je nach Formulierung oder Kontext zu völlig anderen Ergebnissen führen
  • In einem Projekt verweigerte es zunächst die Schwachstellenforschung, akzeptierte später aber nach einer irrelevanten Änderung der Projektumgebung dieselbe Untersuchung desselben Codes
  • In einem anderen Fall fand und bestätigte es mehrere schwere Speicherfehler in einer Codebasis, verweigerte danach aber das Schreiben eines Demo-Exploits
  • Aufgrund der stochastischen Natur des Modells konnte selbst dieselbe Anfrage von Lauf zu Lauf unterschiedliche Ergebnisse liefern
• Spontane Verweigerung und Guardrails existieren zwar tatsächlich, sind für sich genommen aber nicht konsistent genug, um eine vollständige Sicherheitsgrenze zu bilden
• Damit leistungsfähige Cyber-Frontier-Modelle allgemein bereitgestellt werden können, sind zusätzliche Sicherheitsmechanismen nötig, damit sie auch außerhalb kontrollierter Forschungsumgebungen wie Project Glasswing angemessen eingesetzt werden

Das Problem von Signal und Rauschen

• Bei der Triage von Sicherheitslücken ist es am schwierigsten zu entscheiden, welcher Bug real ist, ausnutzbar ist und jetzt behoben werden sollte
• Dieses Problem war schon vor AI schwierig, wurde durch AI-Schwachstellenscanner und AI-generierten Code verschärft, und Cloudflare baute mehrere Nachvalidierungsschritte auf

• Programmiersprachen

  • C und C++ erlauben direkte Speicherkontrolle und erzeugen dadurch Bug-Klassen wie Buffer Overflows und Out-of-Bounds-Lese- und Schreibzugriffe
  • Memory-safe-Sprachen wie Rust eliminieren solche Klassen bereits zur Compile-Zeit
  • In Projekten, die in speicherunsicheren Sprachen geschrieben sind, traten konsistent mehr False Positives auf

• Modell-Bias

  • Gute menschliche Forscher sagen, was sie gefunden haben und wie sicher sie sich sind; Modelle neigen hingegen dazu, Ergebnisse zu produzieren, unabhängig davon, ob im Code wirklich ein Bug steckt oder nicht
  • Die Ergebnisse werden mit Formulierungen wie „possibly“, „potentially“ oder „could in theory“ abgeschwächt, und solche spekulativen Ergebnisse waren deutlich häufiger als belastbare Befunde
  • Für ein Explorationstool ist das ein sinnvoller Bias, doch in einer Triage-Queue verbraucht jedes spekulative Ergebnis menschliche Aufmerksamkeit und Tokens, und in Tausenderzahl wird das teuer
  • Mythos Preview zeigte eine deutliche Verbesserung bei der Fähigkeit zur Verkettung von Primitiven, indem es mehrere Schwachstellen nicht getrennt meldete, sondern zu einem funktionierenden PoC verband
  • Ergebnisse mit PoC lagen deutlich näher an unmittelbar umsetzbaren Findings und verkürzten die Zeit zur Klärung von „Ist das echt?“ erheblich
  • Cloudflares Harness ist bewusst so abgestimmt, mehr zu melden, um weniger zu übersehen, und erzeugt daher viel Rauschen; die Ausgaben von Mythos Preview enthielten aber weniger abgeschwächte Formulierungen und klarere Reproduktionsschritte, was den Aufwand für die Entscheidung über Fix oder Verwerfung reduzierte

Grenzen des direkten Einsatzes allgemeiner Coding-Agenten auf Repositories

• In der Frühphase AI-gestützter Schwachstellenforschung war es ein naheliegender Ausgangspunkt, einem allgemeinen Coding-Agenten ein beliebiges Repository zu geben und ihn nach Schwachstellen suchen zu lassen
• Dieser Ansatz erzeugt zwar Ergebnisse, eignete sich aber nicht dafür, reale Codebasen sinnvoll abzudecken und wertvolle Findings zu liefern

• Kontext

  • Coding-Agenten sind auf einen einzelnen fokussierten Arbeitsfluss wie Feature-Implementierung, Bugfixing oder Refactoring zugeschnitten
  • Schwachstellenforschung ähnelt eher engen, parallelen Aufgaben: ein einzelnes komplexes Feature, einen Wechsel der Sicherheitsgrenze oder eine Command Injection tief untersuchen und das dann tausendfach über die gesamte Codebasis wiederholen
  • Selbst mit Sub-Agenten kann eine einzelne Agentensitzung für ein Repository mit 100.000 Zeilen nur etwa 0,1 % der Angriffsfläche sinnvoll abdecken, bevor das Kontextfenster des Modells voll ist und die Kompression beginnt
  • Beim Komprimieren können frühere Ergebnisse verloren gehen, die wichtig gewesen wären

• Durchsatz

  • Ein Single-Stream-Agent kann immer nur eine Aufgabe gleichzeitig ausführen
  • Reale Codebasen verlangen die Fähigkeit, viele Hypothesen gleichzeitig auf unterschiedliche Komponenten anzuwenden und bei interessanten Stellen breiter zu verzweigen
  • Wenn ein Forscher bereits einen Hinweis hat und einen zweiten Prüfer braucht, eignen sich Coding-Agenten für manuelle Untersuchungen
  • Als Werkzeug für hohe Abdeckung sind sie jedoch ungeeignet, weshalb Cloudflare dazu überging, ein Harness um Mythos Preview herum aufzubauen

Welche Probleme das Harness gelöst hat

• Die Erfahrung im großen Maßstab führte zu dem Schluss, dass ein Harness nötig ist, das den gesamten Lauf steuert

• Ein enger Rahmen liefert bessere Ergebnisse

  • Die Aufforderung „Finde Schwachstellen in diesem Repository“ lässt das Modell ziellos werden
  • Eine Aufforderung wie „Prüfe diese konkrete Funktion auf Command Injection, hier ist die Trust Boundary darüber, hier sind die Architekturdokumente und die bisherige Abdeckung dieses Bereichs“ führt zu Ergebnissen, die näher an der Arbeitsweise realer Forscher liegen

• Adversarial Review reduziert Rauschen

  • Wenn zwischen erste Ergebnisse und Queue ein zweiter Agent geschaltet wird, fängt dieser viel Rauschen ab, das der erste Agent bei der Selbstprüfung übersehen würde
  • Der zweite Agent verwendet einen anderen Prompt und ein anderes Modell, darf aber keine eigenen Ergebnisse erzeugen
  • Zwei Agenten absichtlich in einen Zustand der Nichtübereinstimmung zu versetzen, erwies sich als deutlich wirksamer, als einem einzelnen Agenten bloß zu sagen, er solle vorsichtig sein

• Ketten auf Agenten aufzuteilen verbessert das Schlussfolgern

  • „Enthält dieser Code einen Bug?“ und „Kann ein Angreifer diesen Bug von außerhalb des Systems tatsächlich erreichen?“ sind unterschiedliche Fragen
  • Werden sie getrennt, werden beide Fragen enger gefasst, und das Modell liefert bei jeder von ihnen bessere Leistung

• Parallele enge Aufgaben schlagen einen umfassenden Agenten

  • Die Abdeckung verbessert sich, wenn viele Agenten eng definierte Fragen bearbeiten und die Ergebnisse anschließend dedupliziert werden
  • Das war wirksamer, als von einem einzelnen Agenten Vollständigkeit zu verlangen
  • Cloudflare erweiterte, justierte und verbesserte sein bestehendes Harness mit Mythos Preview passend zu dessen Stärken

Cloudflares Harness zur Schwachstellenfindung

• Dieses Harness wird genutzt, um echten Code in Cloudflares Runtime, im Edge-Datenpfad, in Protokoll-Stacks, in der Control Plane sowie in abhängigen Open-Source-Projekten zu scannen

• Recon

  • Ein Agent liest das Repository von oben nach unten und verzweigt in Sub-Agenten, die jeweils einzelne Subsysteme übernehmen
  • Es erzeugt Architekturdokumente mit Build-Befehlen, Trust Boundaries, Entry Points und erwarteter Angriffsfläche
  • Außerdem erstellt es eine anfängliche Arbeits-Queue für die nächste Phase und liefert allen nachfolgenden Agenten gemeinsamen Kontext, damit das Modell weniger leicht die Orientierung verliert

• Hunt

  • Jede Aufgabe besteht aus einer Angriffsklasse und einem Hinweis auf den Umfang
  • Hunter-Agenten, die die realen Bugs finden, laufen typischerweise in Gruppen von etwa 50 parallel, und jeder Hunter verzweigt sich weiter in einige explorative Sub-Agenten
  • Jeder Hunter hat Zugriff auf Werkzeuge, mit denen er PoC-Code in einem temporären Arbeitsverzeichnis kompilieren und ausführen kann
  • Der Großteil der Arbeit erfolgt nicht durch einen einzigen umfassenden Agenten, sondern durch parallele Ausführung vieler enger Aufgaben

• Validate

  • Ein unabhängiger Agent liest den Code erneut und versucht, das ursprüngliche Ergebnis zu widerlegen
  • Er verwendet andere Prompts und kann selbst keine neuen Ergebnisse erzeugen
  • Dadurch wird ein bedeutender Teil des Rauschens abgefangen, den Hunter bei der Prüfung der eigenen Arbeit übersehen würden

• Gapfill

  • Bereiche, die Hunter berührt, aber nicht ausreichend abgedeckt haben, werden markiert
  • Diese Bereiche gehen für einen weiteren Durchlauf zurück in die Queue
  • Das gleicht die Tendenz des Modells aus, sich zu Angriffsklassen hin zu bewegen, in denen es bereits erfolgreich war

• Dedupe

  • Ergebnisse mit derselben Grundursache werden zu einem einzigen Datensatz zusammengeführt
  • Variantenanalyse ist eine Funktion und kein Mittel, die Queue mit Duplikaten aufzublähen

• Trace

  • Für jedes bestätigte Ergebnis in einer Shared Library verzweigt ein Tracer-Agent einmal pro Consumer-Repository
  • Mithilfe eines repository-übergreifenden Symbolindex entscheidet er, ob vom Angreifer kontrollierte Eingaben den Bug tatsächlich von außerhalb des Systems erreichen können
  • Das war der wichtigste Schritt, um „es gibt einen Defekt“ in „es gibt eine erreichbare Schwachstelle“ zu verwandeln

• Feedback

  • Erreichbare Tracing-Ergebnisse werden zu neuen Hunt-Aufgaben für die Consumer-Repositories, in denen der Bug tatsächlich exponiert ist
  • Dadurch schließt sich eine Schleife, in der die Pipeline mit jedem Lauf besser wird

• Report

  • Ein Agent verfasst strukturierte Berichte nach einem vordefinierten Schema
  • Fehler bei der Schemavalidierung korrigiert er selbst und übermittelt die Berichte an die Ingest-API
  • Die Ausgabe ist keine freie Prosa, sondern abfragbare Daten

Was das für Security-Teams bedeutet

• Andere Security-Leader, die Mythos Preview sahen, wollten ihre Reaktionszyklen durch schnelleres Scannen und Patchen verkürzen
• Mindestens eines der Teams, mit denen Cloudflare sprach, arbeitete vom CVE-Disclosure bis zum Production-Patch mit einer SLA von 2 Stunden
• Wenn die Timeline der Angreifer kürzer wird, muss auch die Timeline der Verteidiger kürzer werden, aber Geschwindigkeit allein reicht nicht aus
• Schnelleres Patchen verändert nicht die Form der Pipeline, die Patches hervorbringt
  • Wenn Regressionstests einen Tag dauern, lässt sich eine SLA von 2 Stunden nicht erreichen, ohne sie zu überspringen
  • Bugs, die mit übersprungenen Regressionstests ausgerollt werden, können schlimmer sein als der Bug, den man eigentlich beheben wollte
  • Als Modelle direkt Patches schreiben durften, wurden einige Patches ausgerollt, die zwar den ursprünglichen Bug behoben, aber still andere Teile beschädigten, auf die der Code angewiesen war
• Die schwierigere Frage ist, wie die Architektur rund um Schwachstellen entworfen werden sollte
  • Selbst wenn ein Bug existiert, muss er für Angreifer schwer auszunutzen sein
  • Die Zeitspanne zwischen Offenlegung einer Schwachstelle und Patch sollte weniger wichtig werden
  • Es braucht Schutzmechanismen vor der Anwendung, die das Erreichen des Bugs blockieren
  • Anwendungen müssen so entworfen werden, dass ein Defekt in einem Teil dem Angreifer keinen Zugang zu anderen Teilen verschafft
  • Korrekturen müssen gleichzeitig an allen Orten ausgerollt werden können, an denen Code ausgeführt wird, ohne auf Deployments einzelner Teams zu warten
• Dieselbe Fähigkeit hat zwei Seiten
  • Die Fähigkeit, Bugs im eigenen Code zu finden, kann in falschen Händen auch Angriffe auf jede Anwendung im Internet beschleunigen
  • Cloudflare erklärt, dass es vor Millionen Anwendungen sitzt und dass die oben genannten Architekturprinzipien genau die Prinzipien sind, nach denen seine Produkte zum Schutz der Kunden entwickelt wurden
• Die Forschung zu Mythos Preview wurde in einer kontrollierten Umgebung auf Cloudflares eigenen Code angewandt; alle entdeckten Schwachstellen wurden nach Cloudflares offiziellem Schwachstellenmanagement-Prozess triagiert und validiert und bei Bedarf behoben

[crawler]

Ich dachte, das wäre wie bei curl ein Analysebericht darüber, welcher Fehler behoben wurde, aber es ist einfach nur ein unverhohlener Werbetext, oder?
Cloudflare hat auch erst Hype gemacht, indem es eine eigene Paywall oder einen Zusammenfassungs-Endpunkt speziell für AI-Agenten gebaut hat, und jetzt ist es völlig auf den falschen Weg geraten.

[GN⁺]

Hacker-News-Kommentare

• Ich verstehe nicht, was mit „Es ist eine andere Art von Tool für eine andere Art von Arbeit, daher ist ein sauberer Vergleich mit früheren Modellen von Äpfeln zu Äpfeln schwierig“ gemeint ist.
  Von einer anderen Art von Tool zu sprechen, aber dann die tatsächliche Nutzung genauso zu beschreiben wie bei anderen Modellen, passt nicht zusammen. Es war deutlich schwächer als ein durchschnittlicher Cloudflare-Blogpost und wirkte stark wie eine Wiederholung der Mythos-Präsentation, die Chaining und die Erstellung von Beispielen als Kernpunkte hervorgehoben hat.

  • Ich denke, gemeint ist, dass es qualitativ andere Fähigkeiten hat und es sich daher mehr lohnt, bestimmte Sicherheitsaufgaben mit diesem Modell auszuprobieren, nicht dass sich das Mensch-KI-Interaktionsmodell verändert hätte.
    Es stimmt, dass alle so etwas mit einem Harness nutzen, und die übliche Art, einem Modell ein Harness zu geben, wird sich wohl auch künftig nicht grundlegend ändern. Menschen brauchen für manche Aufgaben schließlich auch ein Harness.
  • Ich habe auch versucht, das so zu deuten.
    Wohlwollend gelesen könnte es sein, dass sie wegen NDA absichtlich vage bleiben, was genau anders ist.
  • „Deutlich schwächer als ein durchschnittlicher Cloudflare-Blogpost“ – ich würde gern wissen, wann dieser Durchschnitt berechnet wurde.
    In letzter Zeit riechen fast alle Cloudflare-Outputs stark nach AI.
  • Es klingt wohl deshalb anders, weil es kein normaler Blogpost, sondern versteckte Werbung ist.
  • Der Abschnitt „Das Modell selbst hat neue Guardrails, die sich gelegentlich selbst gegen legitime Security-Research-Anfragen sperren. Nach allem, was wir beobachtet haben, sind solche spontanen Verweigerungen jedoch nicht konsistent. Schon wenn man dieselbe Aufgabe anders formuliert oder in einen anderen Kontext stellt, kann das zu völlig anderen Ergebnissen führen, wie die folgenden Beispiele zeigen“ war neu für mich.
    Es überrascht mich, dass ein für Sicherheitsforschung entwickeltes und nur für Experten zugängliches Modell legitime Anfragen ablehnt.

• Ich hatte konkretere Zahlen und überraschendere Ergebnisse erwartet, aber es wirkt eher wie ein ausgewogener Werbebeitrag und vermutlich so, als wäre er mit einem LLM geschrieben worden.

  • Ich habe in den letzten Tagen empfohlen, die Einblicke des Konkurrenten XBOW zu lesen; das trägt mehr Information zur Diskussion bei.
    [1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...

• Die eigentliche Frage ist, ob dieser Text von Mythos oder von Opus geschrieben wurde.
  Formulierungen wie „Warum das wichtig ist“ sind in Wahrheit nicht wichtig. Unternehmensblogs wurden zwar schon immer selten mit der Stimme eines einzelnen Autors geschrieben, aber es ist interessant zu sehen, wie selbst große Organisationen ihre Blogs an LLMs auslagern.

  • Satzkonstruktionen wie „Als Explorationswerkzeug ist das ein vernünftiger Bias. Für eine Klassifizierungs-Queue ist es ein destruktiver Bias ...“ wirken eindeutig wie AI-Stil.
    „Warum das wichtig ist“ würde ich inzwischen zu „AI-Output wird Teil der Trainingsdaten“ hochstufen. Irgendwann wird dieser geglättete, künstlich weitschweifige AI-Stil zum Standard, und wer nicht aus einer früheren Generation kommt, wird ihn kaum noch unterscheiden können. So ähnlich wie die Wehmut über manche Aspekte von Usenet.
  • Ich finde es bemerkenswert, wie manche zu glauben scheinen, dass genug Spott über etwas auch dessen sachlichen Gehalt verschwinden lässt.
    Es ist, als würde man in den Lauf einer Waffe schauen und Witze darüber machen, auf welchem Papier die Waffenwerbung gedruckt wurde.
  • Es ist nicht einfach irgendeine große Organisation, sondern Anthropic. Die Kernbotschaft dieses Unternehmens lautet, dass AI jetzt echte Arbeit leisten kann, also wäre es seltsam, wenn sie selbst nicht entsprechend handeln würden.
    Deshalb gibt es bei Claude Code offenbar so viele merkwürdige Bugs, und es kommt vor, dass der Support sagt, eine Rückerstattung sei bearbeitet worden, obwohl das tatsächlich nicht passiert.
  • Der Cloudflare-Blog war schon viele Jahre lang hervorragend, lange bevor Transformer auftauchten.
  • Es sieht weniger nach vollständig von AI geschrieben aus als nach einem Text, der von AI redigiert wurde. Oder sie nutzen im zweiten Durchgang ein ziemlich gutes Vermenschlichungs-Tool.

• Diese „vier Lektionen“, die angeblich aus der Ausführung dieser Arbeit im großen Maßstab gewonnen wurden, fand ich ziemlich lustig. Drei von vieren sind im Grunde dasselbe und viel zu offensichtlich.
  Zusammengefasst heißt es nur, dass konkrete und eng gefasste Anfragen besser funktionieren als „Finde Schwachstellen“, was nun wirklich keine Überraschung ist. Trotzdem ist adversariales Review zwar überhaupt nicht neu und wurde auch auf HN oft diskutiert, aber es ist zumindest ein interessanter und unterscheidbarer Punkt. Ich sollte das stärker in meinen Workflow aufnehmen; vielleicht hilft es auch bei nicht-programmierbezogenen Aufgaben.
  https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

• Der Teil „Die stärkste Reaktion von Security-Leitern auf Mythos Preview war die Geschwindigkeit: schneller scannen, schneller patchen, die Reaktionszyklen komprimieren. Mindestens zwei der Teams, mit denen wir gesprochen haben, arbeiten vom CVE-Disclosure bis zum Patch in Produktion mit einer 2-Stunden-SLA [...] Wenn Regressionstests einen Tag dauern, kommt man ohne ihr Überspringen nicht auf eine 2-Stunden-SLA, und wenn man Regressionstests überspringt, deployt man leicht Bugs, die schlimmer sind als der, den man eigentlich patchen wollte“ fand ich eindrucksvoll.
  Ich frage mich, ob solche Modelle mit der Zeit Exploitability-Tests ausführen könnten, bevor Code gemergt wird, und dadurch standardmäßig sichereren Code erzeugen.

  • Ich weiß nicht, aber ich finde es immer seltsam, wenn man sieht, dass AI etwas nicht besonders gut kann, und dann zu dem Schluss kommt, die Lösung sei, noch mehr AI einzusetzen.
  • Oder es läuft nicht so, und stattdessen verkaufen sie* den Zugang zu Mythos und Nachfolgemodellen über Service-Unternehmen oder Partnernetzwerke zu Premiumpreisen.
    *Mit „sie“ sind hier alle Anbieter von Foundation Models gemeint, da auch OpenAI offenbar in dieselbe Richtung geht.

• Schön und gut, aber ich würde gern wissen, wie schwerwiegend die schlimmste gefundene Schwachstelle tatsächlich war.
  Vermutlich wollen sie das nicht offenlegen, aber genau das ist der interessanteste und wichtigste Teil.

  • Ich würde mich gern dem Skeptizismus anschließen, aber sie sagen es gleich am Anfang sehr deutlich: Das ist eine stufenweise Veränderung.
    Viele sehen Mythos als eine Art psychologische Operation, aber diesen Skeptizismus kann ich nicht gut nachvollziehen. Er scheint meist aus einem allgemeinen Misstrauen gegenüber Dingen zu kommen, die nicht öffentlich nutzbar sind. Einige Anthropic-Mitarbeiter haben Mythos zwar als Verbesserung eines allgemeinen Modells beschrieben, aber das ist bislang nicht breit belegt, und nur in diesem Punkt bleibe ich skeptisch. Für den Bereich Sicherheitsforschung kann ich diese Erzählung akzeptieren.
  • Es wird konkret erklärt, dass Exploits in der Regel durch Chaining mehrerer kleiner Schwachstellen entstehen.
    In diesem Sinne ist das Schließen von Schwachstellen nicht dasselbe wie das Finden eines Exploits. Es geht eher darum, weniger kleine Lücken offenzulassen, sodass es zunehmend schwerer wird, daraus einen funktionierenden Exploit zusammenzubauen.
  • Inzwischen denke ich, dass dieses Modell deutlich kreativer ist und viel länger agentisch ausführen kann.
    Deshalb kann es, selbst wenn die „Hard Skills“ nicht überwältigend besser geworden sind, diese viel wirksamer kombinieren. Schon jetzt lassen sich viele dieser Schwachstellen mit Opus identifizieren, aber um daraus einen komplexen Exploit abzuleiten, braucht es bislang meist noch einen Menschen, und zwar einen erfahrenen. Wenn kein Mensch mehr dazwischengeschaltet werden muss, wird es für Durchschnittsnutzer sehr viel einfacher, Exploits zu finden und auszunutzen.
  • Palo Alto Networks hat letzte Woche mehrere CVE-Patches für Firewalls veröffentlicht, und fast alle stammten aus dem Zugang zu Frontier-Modellen einschließlich Mythos.
    https://security.paloaltonetworks.com
  • Da die meisten neuen Produkte von Anthropic AI-Tools sind, die niemand nutzt, werden sie wohl weiter solche minderwertigen Texte veröffentlichen. Außerdem haben sie zuletzt viele Leute entlassen, daher haben sie womöglich gar keine guten Autoren mehr.

• Nett, aber ich verstehe nicht, warum sie keine Daten dazu teilen, wie viele Sicherheitslücken sie tatsächlich gefunden haben, wie viele davon echt waren und wie viele Fehlalarme.

  • Darauf warte ich auch.
    Ich verstehe, dass man das vor einer Veröffentlichung erst abarbeiten möchte, aber wenn man immer wieder Behauptungen mit kaum Daten dazu sieht, weiß ich nicht, wie man erwarten kann, dass Leute nicht skeptisch sind. Sicherheitsfachleute werden buchstäblich dafür bezahlt, skeptisch zu sein.

• Ich würde gern wissen, ob sie es mit anderen Modellen verglichen haben. Vieles in diesem Text klingt so, als hätten sie zum ersten Mal AI auf Sicherheit angewendet und seien von der absurden Leistungsfähigkeit einer Pattern-Matching-Maschine überrascht.
  Letztlich ist es eben eine Maschine zum Erkennen von Mustern, also ist das nicht überraschend.

• Der widerwillige Teil ist ziemlich lustig. Als ich es selbst benutzt habe, wollte es vor dem Fortfahren einen Nachweis, dass ich legitimen Zugriff auf diese Codebasis habe.

• Die Aussage „Was sich mit Mythos Preview geändert hat, ist, dass das Modell Low-Severity-Bugs, die traditionell unsichtbar im Backlog geblieben wären, zu einem schwerwiegenderen Exploit chainen kann“ scheint auch einigermaßen zu anderen unabhängigen Tests von Mythos zu passen.
  Es war bei langen agentischen Aufgaben sehr stark und wurde vermutlich genau dafür trainiert. Dafür muss es in der Lage sein, lose Zusammenhänge zwischen nur am Rand verbundenen Themen innerhalb des Kontextfensters zu erkennen.
  [1] Gemeint ist vor allem https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...