Die neue Grenze der AI-Cybersicherheit: Die Realität nach Mythos

• Nachdem Anthropics Claude Mythos Zero-Day-Schwachstellen in großem Maßstab automatisch erkannt hatte, konnten auch kleine Open-Modelle dieselben Schwachstellen erfolgreich finden
• Modelle mit 3,6B bis 5,1B Parametern reproduzierten FreeBSD- und OpenBSD-Bugs, einige zeigten sogar kreative Exploit-Pfade, die sich von Mythos unterschieden
• Die Experimente zeigen, dass Modellgröße und Leistung nicht linear zusammenhängen und bei bestimmten Aufgaben kleine Modelle genauer als große Modelle sind
• Die Sicherheitsfähigkeiten von AI skalieren nicht glatt, sondern sind „zackig“, und der eigentliche Wettbewerbsvorteil liegt nicht im Modell, sondern im Systemdesign und in der Verifizierungs-Pipeline
• Daher liegt der Burggraben in der Sicherheit nicht im Modell, sondern im System, und eine Orchestrierungsstruktur mit eingebettetem Expertenwissen ist der Kern von AI-Sicherheit

---

Das System ist der Burggraben, nicht das Modell

• Am 7. April 2026 stellte Anthropic Claude Mythos Preview und Project Glasswing vor und bildete ein Konsortium, das mithilfe des Mythos-Modells Sicherheitslücken in wichtiger Software automatisch erkennt und patcht
  • Es wurden Nutzungsguthaben im Wert von 100 Millionen US-Dollar und 4 Millionen US-Dollar an Spenden für Open-Source-Sicherheitsorganisationen zugesagt
  • Mythos fand tausende Zero-Day-Schwachstellen und erkannte autonom unter anderem einen 27 Jahre alten Bug in OpenBSD, einen 16 Jahre alten Bug in FFmpeg sowie eine Remote-Code-Execution-Schwachstelle in FreeBSD und erzeugte passende Exploits
• AISLE reproduzierte dieselben Schwachstellen mit kleinen, günstigen Modellen mit offenen Gewichten
  • 8 von 8 Modellen erkannten den FreeBSD-Exploit
  • Auch ein Modell mit 3,6B Parametern (0,11 US-Dollar pro Token) war erfolgreich
  • Ein 5,1B-Modell rekonstruierte die zentrale Kette des OpenBSD-Bugs
  • Bei einigen Aufgaben waren kleine Open-Modelle großen Modellen überlegen
• Insgesamt sind die Sicherheitsfähigkeiten von AI nicht linear, sondern zackig (jagged)
  • Kein einzelnes Modell ist bei allen Aufgaben überlegen
  • Der Kern der Sicherheitswettbewerbsfähigkeit ist nicht das Modell, sondern das System, mit einer Orchestrierungsstruktur, in die Expertenwissen eingebettet ist

Wo AI-Sicherheit aktuell steht

• AISLE setzt seit Mitte 2025 AI-basierte Systeme zur Erkennung und zum Patchen von Schwachstellen auf reale Ziele an
  • In OpenSSL wurden 15 CVEs, in curl 5 CVEs und insgesamt mehr als 180 extern verifizierte CVEs gefunden
  • Der CTO von OpenSSL bewertete „die Qualität der Berichte und den Kooperationsprozess“ als hervorragend
• Es wurden verschiedene Modelle eingesetzt, aber Anthropic-Modelle waren nicht immer die besten
  • Da sich das optimale Modell je nach Aufgabe unterscheidet, wurde ein modellagnostischer Ansatz gewählt

Zerlegung der AI-Sicherheits-Pipeline

• Reale AI-Sicherheit besteht nicht aus einem einzelnen Modell, sondern aus einer mehrstufigen Pipeline
  • Breit angelegtes Scanning, Schwachstellenerkennung, Verifizierung und Klassifizierung, Patch-Erzeugung und Exploit-Konstruktion haben jeweils unterschiedliche Skalierungseigenschaften
• Anthropic maximiert den ersten Inputfaktor (Modellintelligenz), während AISLE verschiedene Faktoren wie Kosten pro Token, Geschwindigkeit und Security-Expertise gleich stark gewichtet

Fazit: Der Burggraben ist das System

• Die in Mythos’ technischem Post erwähnten Strukturen wie Container-Ausführung, File-Scanning, ASan-Verifizierung und Priorisierung ähneln dem AISLE-System
• Der Wertschwerpunkt liegt nicht im Modell, sondern im Prozess aus Targeting, Verifizierung und Vertrauensaufbau
• Durch den massiv parallelen Einsatz kleiner Modelle zur breiten Erkundung des gesamten Codes lassen sich Wirtschaftlichkeit und Erkennungseffizienz zugleich erreichen
• Mythos hat die Kategorie bewiesen, aber operative Skalierung und belastbare Zuverlässigkeit bleiben weiterhin offene Aufgaben

Experimentelle Ergebnisse: Zackige Sicherheitsfähigkeiten

• Anhand der repräsentativen Schwachstellen aus der Mythos-Ankündigung wurden Experimente mit kleinen, günstigen Modellen durchgeführt

  • FreeBSD-NFS-Bug, OpenBSD-SACK-Bug, OWASP-Test auf False Positives

    • Das Ergebnis: Modellgröße, Generation, Preis und Leistung verhalten sich nicht linear
    • Bei FreeBSD waren alle Modelle erfolgreich, bei OpenBSD nur einige, und bei OWASP waren kleine Modelle präziser als große
    • FreeBSD-Erkennung: Alle 8 Modelle erkannten den Buffer Overflow
    • Selbst ein 3,6B-Modell rechnete korrekt und bewertete die Möglichkeit einer RCE
    • DeepSeek R1 führte Berechnungen durch, die mit der tatsächlichen Stack-Struktur übereinstimmten
    • Auch bei der Exploit-Logik schlugen alle Modelle eine ROP-Chain-Strategie vor
    • Einige Modelle präsentierten kreative Lösungen, die sich von Mythos unterschieden (z. B. Privilege Escalation im User-Mode statt im Kernel-Mode)
    • OpenBSD-SACK-Bug: Ein 5,1B-Modell rekonstruierte die gesamte Kette und schlug den korrekten Patch vor
    • Qwen3 32B war bei FreeBSD perfekt, urteilte hier jedoch fälschlich, es sei „sicher“
    • Die Leistungsrangfolge der Modelle kehrte sich je nach Aufgabe vollständig um

• OWASP-Test auf False Positives: Kleine Modelle sind bei einfachem Java-Code genauer als große

  • GPT-OSS-20b, DeepSeek R1 und OpenAI o3 bewerteten korrekt: „derzeit sicher, aber potenziell verwundbar“
  • Viele Modelle aus den Reihen Anthropic und GPT-4.x meldeten fälschlicherweise eine SQL-Injection

Test zur Patch-Erkennung (Update vom 9. April 2026)

• Für den gepatchten FreeBSD-Code wurde die Fähigkeit zur Bug-Erkennung und zur Erkennung der Korrektur verglichen
  • Alle Modelle erkannten den ungepatchten Bug, aber im gepatchten Code traten viele False Positives auf
  • Nur GPT-OSS-120b war in beide Richtungen korrekt
  • Die meisten Modelle behaupteten fälschlich eine Schwachstelle aufgrund eines Fehlers bei der Vorzeicheninterpretation von oa_length
• Das zeigt eine hohe Sensitivität (Erkennungsstärke), aber niedrige Spezifität (Genauigkeit) und unterstreicht,
  dass Verifizierungs- und Triage-Systeme außerhalb des Modells unverzichtbar sind

Die Grenzen der Exploit-Konstruktion

• Mythos’ mehrstufiger Browser-Sandbox-Escape und Kernel-ROP-Chain sind sehr hochentwickelte Beispiele
• Open-Modelle können Exploitierbarkeit, Techniken und Umgehungsstrategien logisch erläutern,
  aber bei kreativen Delivery-Mechanismen unter eingeschränkten Bedingungen bestehen noch Defizite
• In defensiven Workflows ist jedoch die Zuverlässigkeit von Erkennung und Patching wichtiger als ein vollständiger Exploit

Makroperspektive

• Die Mythos-Ankündigung belegt die Realitätsnähe und industrielle Relevanz von AI-Sicherheit
  • Finanzierung und Aufmerksamkeit für Open-Source-Sicherheit nehmen zu
• Die Behauptung, „diese Fähigkeit existiere nur in einem bestimmten geschlossenen Modell“, ist jedoch übertrieben
  • Tatsächlich sind Erkennungs- und Analysephasen bereits breit zugänglich
  • Security-Expertise, Systemdesign und Vertrauensaufbau sind die eigentlichen Engpässe

• Was jetzt gebraucht wird, sind nicht Modelle, sondern Systemaufbau

  • Scaffolds, Pipelines, Kollaborationsstrukturen und die Integration in Entwicklungs-Workflows
  • Die Modelle selbst sind bereits ausreichend weit

Grenzen und Hinweise

• Begrenzter Testrahmen: Den Modellen wurden die verwundbare Funktion und Hinweise direkt gegeben, es handelte sich nicht um eine vollständig autonome Suche
• Kein Tool-Zugriff: Es wurden weder Code-Ausführung noch Schleifen oder Sandbox-Umgebungen verwendet
• Berücksichtigung von Modell-Updates: Einige neuere Anthropic-Modelle wurden später verbessert
• Klarstellung des Geltungsbereichs: Die Fähigkeiten von Mythos werden nicht bestritten,
  vielmehr wird darauf hingewiesen, dass die Exklusivität der Erkennungsfähigkeit übertrieben dargestellt wurde

Zusammenfassung des Anhangs

• Zitate zur FreeBSD-Erkennung

  • Kimi K2: „oa_length wird ohne Validierung kopiert, wodurch ein Overflow möglich ist“
  • Gemma 4: „Ein 128-Byte-Stack-Buffer kann überschritten werden“

• Vergleichstabelle der Leistung je Aufgabe

  • Bei FreeBSD waren alle Modelle erfolgreich, bei OpenBSD nur einige, bei OWASP lagen kleine Modelle vorne

• Test mit gepatchtem Code

  • Die meisten Modelle erzeugten wegen eines Vorzeichenfehlers bei oa_length False Positives
  • Nur GPT-OSS-120b war vollständig korrekt
  • Fazit:
  • Der zentrale Wettbewerbsvorteil in der AI-Sicherheit liegt nicht in Größe oder Exklusivität des Modells,
  • sondern in systemischem Design mit eingebettetem Expertenwissen und einer vertrauenswürdigen Betriebsstruktur.
  • Auch kleine Modelle sind stark genug, und der Aufbau groß angelegter automatisierter Verteidigungssysteme auf ihrer Basis ist bereits möglich.

[GN⁺]

Hacker-News-Kommentare

• Im Artikel zu Anthropic Mythos Preview heißt es, man habe in OpenBSD die kritischste Schwachstelle gefunden
  Die Gesamtkosten für tausend Ausführungen lagen unter 20.000 Dollar, und in einem dieser Läufe wurde der Bug für weniger als 50 Dollar gefunden
  Es wird aber betont, dass diese Zahl nur rückblickend sinnvoll ist, weil man im Vorfeld nicht wissen kann, welcher Lauf erfolgreich sein wird
  Mit der Metapher, Mythos habe einen ganzen Kontinent wie eine Goldmine durchsucht, wird vermutet, dass bei demselben Experiment auf der gesamten FreeBSD-Codebasis zu viel Rauschen entstehen würde

  • Das Scaffolding von Mythos war im Grunde eine bash-Schleife, die alle Dateien durchlief und das Modell nach Schwachstellen suchen ließ
    Man fragt sich, ob Anthropic die False-Positive-Rate veröffentlicht hat
    Auf Xitter habe man Berichte von Leuten gesehen, die den Versuch mit anderen offenen Modellen nachstellten und nur einen Teil der von Mythos gefundenen Ergebnisse reproduzieren konnten
    Mythos habe gegenüber bestehenden Modellen eine inkrementelle, aber große Verbesserung gezeigt, zugleich sei aber auch die Komplexität gestiegen
    Marketing nach dem Motto „zu mächtig, um es zu veröffentlichen“ wirke in Wahrheit wie eine Verpackung für die Realität, dass „ein Durchlauf über die gesamte Codebasis 20.000 Dollar kostet“
    Auch in Nicholas Carlinis Vortrag wurde Opus verwendet; Security ist ohnehin seit Langem ein Bereich, auf den sich Anthropic konzentriert
  • Auch Mythos hat viele halluzinierte Schwachstellen erzeugt, aber einige davon wurden tatsächlich durch Tests verifiziert
    Die Kernfrage ist, ob auch kleine Modelle solche Verifizierungsschritte ausführen können und ob das günstiger möglich ist
  • Umgekehrt wird anderen Forschungsarbeiten vorgeworfen, zu extrem vorzugehen
    Dort wurde dem Modell nur die verwundbare Funktion separat gegeben und es wurde darauf bewertet, was so sei, als hätte man „direkt den Raum genannt, in dem das Gold versteckt ist“
    In der Praxis ist es viel schwieriger, diesen Raum erst auf dem ganzen Kontinent zu finden
  • 20.000 Dollar auszugeben, um eine DoS-Schwachstelle in OpenBSD zu finden, wirke ineffizient
    Obwohl Mythos wie eine Trophäe behandelt werde, sei eine Spende an die OpenBSD Foundation vermutlich sinnvoller
  • Wenn sich dieselbe Schwachstelle auch mit kleinen Modellen finden lässt, stellt sich die Frage, warum die betreffende Firma das nicht schon vorher gefunden hat

• Es gab eine Studie, laut der kleine offene Modelle 8 von 8 Mythos-FreeBSD-Schwachstellen erkannt haben
  Da aber nur der relevante Code separat herausgelöst getestet wurde, sei das nicht mit einem realen Einsatzszenario vergleichbar
  Der eigentliche Wert liege darin, die gesamte Codebasis hineinzuworfen und scannen zu lassen

  • Das Forschungsteam habe die Grenzen selbst eingeräumt
    Weil dem Modell die verwundbare Funktion und Hinweise direkt gegeben wurden, sei das nur eine Obergrenze für vollständig autonome Suche
    Gut konstruierte Scaffolds erzeugen diesen Kontext jedoch automatisch, daher sei das System (der Moat) entscheidend, nicht das Modell
  • Laut dem technischen Post von Anthropic startet die Struktur Container, lässt das Modell Dateien scannen, Hypothesen aufstellen und sie mit ASan verifizieren
    Das heißt, das Framework (das Harness) erledigt den Großteil der Arbeit, und das Modell sei austauschbar
  • Auch mit kleinen Modellen könne man ein automatisches Harness bauen, das wiederholt Prompts für alle Dateien oder Funktionen abschickt
    Anschließend müssten nur die konsistent als Schwachstellen markierten Stellen mit einem großen Modell erneut validiert werden
    Am Ende sei nicht das Modell entscheidend, sondern das Harness
  • Letztlich sei der Unterschied nur das Harness. Man könne selbst ein Harness bauen, das Code in Funktionen zerlegt und in einen Analyse-Agenten einspeist

• Wie beim Heartbleed-Beispiel gilt: Wenn man nur den verwundbaren Code zeigt, kann jeder den Bug finden
  Die eigentliche Schwierigkeit besteht darin, diesen Teil in einer großen Codebasis überhaupt zu entdecken
  Dass Aisle so einen Artikel geschrieben hat, sei überraschend

  • Es sei zwar ein werblicher Beitrag, aber dass er auf HN weit oben landete, liege wohl daran, dass er den Reflex „Das neue Modell ist also auch nichts Besonderes“ bedient habe
  • Bei großen Projekten komme es oft vor, dass man nach einer Pause auf den eigenen Code zurückblickt und er chaotisch wirkt
    Schwierigkeiten bei der Aufrechterhaltung von Kontext seien eine der Grundursachen für Bugs
  • Menschen seien schwach bei repetitiver und detailreicher Arbeit
    Maschinen dagegen können Code ohne Ermüdung immer weiter durchsehen
    Das Sprichwort „Given enough eyeballs, all bugs are shallow“ entspreche nicht der Realität
  • Dann müsse man eben das „nahe Hinsehen“ automatisieren
    Man könne ein Tool bauen, das eine Codebasis durchläuft und ein LLM wiederholt mit „Finde Schwachstellen in diesem Code, falls es welche gibt“ promptet
    Anders gesagt: das Tool (das Harness) ist der Schlüssel, der das LLM klüger macht
  • Das sei so, als würde man Problemlösung und Verifikation verwechseln
    Eine Analogie wäre: „Wenn dir jemand die Primfaktorzerlegung schon verrät, ist es leicht, PKI zu brechen“

• Die Methodik dieses Artikels sei ein völlig falscher Vergleich
  Die verwundbare Funktion samt Hinweisen direkt zu geben, sei eine ganz andere Aufgabe
  In der Praxis glaube man nicht, dass sich durch Aufteilen von Code und Füttern kleiner Modelle Ergebnisse auf dem Niveau großer Modelle erzielen lassen
  Man habe mit einer einfachen Shell-Skript-Pipeline viele Redis-Bugs gefunden
  Mit schwächeren Modellen habe das nicht funktioniert; wer es selbst ausprobiert, sehe den Unterschied
  Selbst wenn kleine Modelle 80 % finden, brauche man für die restlichen 20 % ein stärkeres Modell

  • Anthropic habe gesagt, dass weniger als 1 % der gefundenen Schwachstellen veröffentlicht wurden
    Es wäre interessant, offenen Modellen eine alte Linux-Umgebung zu geben und zu testen, wie viel sie finden
  • Andere halten diesen Ansatz jedoch für vernünftig
    Kleine Modelle hätten False Positives gut herausgefiltert, und mit einem geeigneten Harness ließen sich ähnliche Ergebnisse wie mit großen Modellen erreichen
    Kleine Modelle seien schnell und günstig und für erfahrene Nutzer deshalb deutlich effizienter
    Künftig werde diese Kombination aus leichtgewichtigem Modell und Harness wohl zum Mainstream
  • Jemand reagierte auch sarkastisch mit „Thanks Dario, very cool!“

• Viele Kommentare sagen, das Ergebnis sei ungültig, weil der Code aufgetrennt wurde, aber Anthropic habe das Modell ebenfalls dateiweise laufen lassen
  Das Harness von Mythos vergab Wichtigkeitswerte an einzelne Dateien und erzeugte Claude-Code-Instanzen, die sich dann auf diese Dateien konzentrierten
  Daher entwerte die Aufteilung des Codes an sich das Ergebnis nicht

• Auch in Nicholas Carlinis Vortragsvideo wird dieselbe Technik vorgestellt
  Wenn man ein LLM jeweils nur eine Datei auf einmal intensiv prüfen lässt, ist das sehr effektiv
  Die eigentliche „Innovation“ von Mythos war also diese einfache Automatisierung dateiweiser Prompts
  Wegen dieser Methode könnten die Kosten bis auf 20.000 Dollar gestiegen sein
  Man habe dasselbe Verfahren mit Opus 4.6 und GPT 5.4 ausprobiert, und die Prüfung sei deutlich gründlicher gewesen
  Wenn sich eine Sitzung also auf eine einzelne Datei konzentriert, analysiert das Modell viel tiefer

  • Allerdings könnten auf diese Weise Schwachstellen übersehen werden, die durch Interaktionen zwischen Dateien entstehen

• Die Formulierung, „kleine Modelle hätten dieselbe Analyse rekonstruiert“, sei nicht quantifiziert und daher schwer vertrauenswürdig
  Schwachstellen lassen sich durch PoC klar messen, also brauche es dafür solche Belege
  Außerdem sei es kein fairer Vergleich, wenn „relevanter Code vorab bereitgestellt“ wurde

• Ohne veröffentlichte False-Positive-Rate sei die Analyse bedeutungslos
  Wenn man in jeder Zeile einen Bug behauptet, hat man zwar 100 % Erkennungsrate, aber keinen Nutzen
  Dass Anthropic und OpenAI solche Kennzahlen nicht offenlegen, mache ihre Aussagen schwer glaubwürdig

  • Dem wurde allerdings entgegengehalten, dass False Positives vernachlässigbar seien, wenn es einen verifizierbaren Oracle gibt
  • Tatsächlich hätten kleine Modelle im False-Positive-Test richtig gelegen, während Opus falsch lag
    An eine Exploit-Verifikation auf Mythos-Niveau reichte das jedoch nicht heran
    Die Ergebnisse von Deepseek R1 wirkten recht überzeugend, aber ob sie wirklich funktioniert haben, sei unklar
  • Mindestens die von Anthropic erreichte Abdeckung müsse identisch erzielt werden, damit der Vergleich aussagekräftig ist

• Der Kernpunkt sei, dass der relevante Code isoliert wurde
  Komplexe Zero-Days entstehen durch Interaktionen mehrerer Dateien, daher hat dieser Ansatz Grenzen

  • Manche behaupten jedoch, auch Mythos habe letztlich auf dieselbe Weise dateibasiert analysiert
  • Ob Mythos tatsächlich dateiübergreifende Schwachstellen gefunden hat, bleibt unklar

• Mythos bewertete die gesamte Codebasis, diese Studie testete dagegen nur den verwundbaren Code isoliert
  Das sei der Unterschied zwischen „einem Hund, der einen Ball im Dschungel findet“ und „einem Hund, dem man den Bereich mit dem Ball vorher zeigt“

  • Im Bild gesprochen habe man dem Ball sogar noch Geruch gegeben, den Hund daran riechen lassen und ihn dann nur in einem kleinen Gebiet laufen lassen
  • Da Mythos nicht die gesamte Codebasis auf einmal einspeisen kann, ist es wahrscheinlich, dass mehrere Sub-Agenten die Arbeit aufgeteilt haben
    Letztlich sei also nicht das Modell entscheidend, sondern das Harness (das Tooling-System)