Project Glasswing nach 30 Tagen: Mythos Preview findet schneller, als die Welt patchen kann

Was ist passiert

Anthropic hat am 22. Mai 2026 den ersten Initial Update zu Project Glasswing veröffentlicht, der im April mit AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, der Linux Foundation, Microsoft, NVIDIA und Palo Alto Networks gestarteten Allianz. Nach rund vier Wochen Lauf-Zeit nennen die Partner Zahlen: Cloudflare meldet 2.000 gefundene Bugs, davon 400 hoch oder kritisch. Mozilla hat in Firefox 150 insgesamt 271 Lücken behoben, über das Zehnfache des Vorjahres-Zyklus. Anthropic selbst hat mehr als 1.000 Open-Source-Projekte mit Mythos Preview gescannt, 6.202 hoch- und kritisch-bewertete Treffer notiert und davon bisher 1.752 von externen Security-Firmen oder intern verifiziert, mit einer True-Positive-Rate von 90,6 Prozent. wolfSSL ist mit CVE-2026-5194, einer Zertifikats-Forgery, das erste namentlich genannte Beispiel.

Einordnung

Methodisch ist Glasswing eine Inversion der bisherigen Engpass-Topologie. Bisher lautete die Frage, wie schnell jemand eine Lücke findet. Ab jetzt lautet sie, wie schnell jemand einen Patch schreibt und wie schnell Sie ihn ausrollen. Microsoft kündigt für die kommenden Patch Tuesdays ein dauerhaftes Anwachsen der Patch-Volumina an, Palo Alto Networks hat im letzten Release-Zyklus die fünffache Patch-Anzahl ausgeliefert, Oracle bewegt sich nach eigenen Angaben mehrfach schneller. Anthropic schreibt offen, dass einzelne Open-Source-Maintainer bereits um langsamere Disclosure-Raten gebeten haben, weil die Patch-Kapazität nicht mitkommt. Die operative Last sitzt nicht mehr beim Scanner, sie wandert in die Verifikation, ins Maintaining und in die Auslieferung.

Bedeutung für den Mittelstand

Sie sitzen flussabwärts. Die Glasswing-Partner härten die Software, die Sie betreiben: Cloudflare-Worker, Cisco-Stacks, Windows-Builds, Linux-Kernel-Pfade, npm- und Composer-Abhängigkeiten. Sobald die 90-Tage-Coordinated-Disclosure-Fenster auslaufen, kommen die Patches in Tranchen, die einen monatlichen Wartungs-Rhythmus überfordern. Ein zweiwöchiges Fenster pro Release-Zug ist die neue Untergrenze, nicht der ambitionierte Stretch.

Beim Datenschutz und der Compliance schlägt das doppelt zu. Erstens: Wer Mythos-Klasse-Tools wie Claude Security an eigenen Code lässt, exportiert Quellcode in einen US-Endpunkt, mit allem, was an personenbezogenen Daten in Tests, Fixtures, Seeds und Logs steckt — DSFA, AVV und Drittland-Transfer-Position müssen vorher stehen. Zweitens: NIS-2 verlangt nach § 30 NIS2UmsuCG-Entwurf und Art. 21 ein dokumentiertes Risikomanagement der IKT-Lieferkette. Wer implizit verkürzte Patch-Zyklen fährt, ohne das Verfahren zu beschreiben, hat im Audit eine Lücke zwischen Soll und Praxis.

Für regulierte Branchen kommt DORA Art. 28 ff. dazu. Finanzunternehmen, die Open-Source-Komponenten in produktiven Pfaden tragen, mappen die ICT-Third-Party-Risk-Disziplin auf den Glasswing-Disclosure-Strom; der Strom wartet nicht, bis das interne Verfahren steht.

Bedeutung für die technische Entwicklung

Architektonisch ist die Bauweise interessanter als die Marke. Die Harness, die Mythos Preview als Code-Mapper, Scanning-Subagent, Triage-Stufe und Report-Writer orchestriert, geht in eine On-Request-Verteilung an qualifizierte Security-Teams. Cisco hat parallel sein Foundry Security Spec quelloffen gestellt. Das schreibt ein Pattern fest, das in den nächsten Monaten Referenz wird: ein Haupt-Agent baut das Threat Model, Sub-Agenten ziehen gegen Code-Sektoren los, ein Skill-Layer trägt die wiederkehrenden Such-Muster, eine Triage-Schicht filtert False Positives, ein Report-Writer schliesst den Zug. Wer später eigene Agenten für interne Code-Basen baut, liest den Glasswing-Stack als Referenz.

Parallel verankert Anthropic ExploitBench und ExploitGym als offene Benchmarks für Exploit-Capabilities und finanziert die OpenSSF-Alpha-Omega-Pipeline mit. Das verschiebt die Mess-Disziplin der Modell-Fähigkeiten von der Hersteller-Folie in reproduzierbare Track-Records.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, holen Sie sich eine ehrliche Bestandsaufnahme Ihres Patch-Zyklus: wie lange braucht ein Hochrisiko-Patch von Vendor-Release bis Produktion, welche Schritte laufen manuell. Zweitens, planen Sie einen Halbierungs-Schritt; wenn der heutige Soll-Wert bei vier Wochen liegt, gehen Sie auf zwei. Drittens, schliessen Sie die manuellen Lücken über eine CI/CD-Pipeline, die täglich baut, testet und ausrollt; einmal pro Monat deployen reicht nicht mehr, wenn die Patch-Welle wöchentlich kommt. Viertens, wenn dieser Umbau nicht in den nächsten Wochen aus eigener Kraft läuft, sprechen Sie mit mir: meine DevSecOps-Praxis macht Bestandssysteme durchsatzfähig für grosse, regelmässige Patch-Wellen — Pipeline-Hardening, automatisches Patch-Rollout, deklarative Stacks, gelebte Daily-Releases. Eigene Glasswing-artige Scans lohnen sich, aber später; jetzt zählt erst, die Wellen zu überstehen, die kommen. Die spannende Frage lautet nicht, ob die Patch-Welle Sie erreicht. Sie lautet, ob Ihre Pipeline morgen einen Hochrisiko-Patch in einem Tag deployt.

Dieser Beitrag spiegelt meine technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• Anthropic — Project Glasswing: An initial update (22.05.2026)
• Cloudflare Blog — Project Glasswing: what Mythos showed us, Grant Bourzikas (18.05.2026, zuletzt aktualisiert 20.05.2026)
• Microsoft MSRC — A note on Patch Tuesday (Mai 2026)
• Palo Alto Networks — Defender's Guide: Frontier AI Impact on Cybersecurity, May 2026 Update (Stand 22.05.2026)