Anthropic Mythos: KI-Code-Scanner findet nur, was Menschen ihn gelehrt haben

Anthropics KI-basiertes Code-Sicherheitsmodell Mythos hat ein Namensproblem — und das ist kein Zufall. Der Begriff "Mythos" sollte ursprünglich göttliche, fast übernatürliche Fähigkeiten suggerieren. Die Realität, die sich seit dem kontrollierten Rollout unter Project Glasswing abzeichnet, liefert eine nüchternere Botschaft: Mythos ist ein solides Automatisierungswerkzeug für das, was erfahrene Security-Analysten ohnehin können. Es findet Schwachstellen, die Menschen ihm beigebracht haben zu finden — und eben keine anderen. Das ist kein Zufall der Implementierung. Es ist ein strukturelles Trainingsproblem, das jedes LLM-basierte Sicherheitsmodell betrifft. Wer KI-Sicherheitstools ernsthaft evaluiert, kommt an dieser Grenze nicht vorbei.

Der konkreteste Beleg dafür: Bei einem Test mit Firefox-Code fand Mythos 271 Schwachstellen. Klingt nach viel — ist es auch. Aber laut The Register war darunter keine einzige Lücke, die ein erfahrener menschlicher Prüfer nicht ebenfalls identifiziert hätte. Der Haken liegt nicht in der Quantität, sondern in der Qualität der Entdeckungen: Mythos erkennt bekannte Klassen von Schwachstellen zuverlässig und skalierbar. Unbekannte Muster, neuartige Angriffsvektoren, Zero-Days jenseits des Trainingsdatenbestands — da zieht das Modell blank. Das ist die ehrliche Bilanz nach dem frühen Rollout, und es lohnt sich, diese Grenze präzise zu verstehen, bevor du Mythos oder ähnliche Tools in deinen Security-Workflow integrierst.

Gleichzeitig wäre es falsch, Mythos deshalb abzuschreiben. Anthropics Entscheidung, den Zugang unter Project Glasswing auf vertrauenswürdige Partner mit echtem Bedarf zu beschränken, ist kein Marketing-Manöver — es ist eine ernsthafte Einschätzung der eigenen Grenzen. Und die Plattform, auf der Mythos operiert, ist technisch aufwendiger als ein einfacher Prompt-Wrapper: Claude Code, Anthropics Agenten-Codiersystem, basiert auf einem komplexen Software-Harness, der die KI orchestriert und ihre Interaktionen mit externen Tools reguliert. Wer das unterschätzt, wird von den Betriebskosten und der Integrationstiefe überrascht.

Was Mythos wirklich kann — und was nicht

Das Grundprinzip von Mythos ist einfach: Das Modell wurde auf bekannten Schwachstellenklassen trainiert, erkennt diese Muster im Code und skaliert diese Erkennung auf eine Geschwindigkeit und Breite, die menschliche Analysten nicht erreichen. Für Security-Teams, die regelmäßig große Codebasen auf bekannte Schwachstellen scannen müssen — Buffer Overflows, SQL-Injection-Muster, unsichere Deserialisierung, klassische Race Conditions — ist das ein echter Effizienzgewinn. Die manuelle Arbeit sinkt, die Abdeckungstiefe steigt.

Das Trainingsproblem tritt dort auf, wo keine Beispiele existieren. Wenn eine neue Klasse von Schwachstellen auftaucht — ein neues Protokoll, ein unbekanntes Framework, eine bisher nicht dokumentierte Angriffstechnik — fehlt Mythos schlicht die Musterbasis. Das ist keine Schwäche, die Anthropic durch weitere Skalierung beheben kann. Es ist eine fundamentale Eigenschaft von Supervised Learning: Das Modell generalisiert auf Basis des Trainingsdatenbestands. Was darin nicht vorkommt, findet es nicht.

Laut Anthropics eigenem Red-Team-Bericht zu Mythos Preview zeigen sich jedoch auch beunruhigende Fähigkeiten in die andere Richtung: Mitarbeiter ohne formale Sicherheitsausbildung konnten Mythos Preview über Nacht auffordern, Remote-Code-Execution-Schwachstellen zu suchen — und wachten am nächsten Morgen mit vollständigen, funktionsfähigen Exploits auf. Forscher entwickelten zudem Scaffolds, die Mythos Preview erlaubten, Schwachstellen ohne menschliche Intervention direkt in Exploits umzuwandeln. Das ist der Grund für den restriktiven Rollout unter Project Glasswing. Mythos ist kein harmloses Audit-Tool — es ist ein zweischneidiges Werkzeug, das in den falschen Händen erheblichen Schaden anrichten kann.

Für den Alltag im Security-Team bedeutet das: Mythos beschleunigt die bekannte Arbeit massiv, ersetzt aber nicht die Expertise für unbekannte Angriffsflächen. Der größte Nutzen entsteht bei erfahrenen Analysten, die das Tool als Multiplier einsetzen — nicht als Ersatz.

Das Swiss-Cheese-Modell: Warum einzelne Fixes trotzdem zählen

Ein Einwand, der häufig kommt: Wenn Mythos nur bekannte Schwachstellen findet, was ändert das wirklich? Komplexe Angriffsketten nutzen doch ohnehin mehrere Lücken gleichzeitig. Die Antwort liegt im Swiss-Cheese-Modell der Fehleranalyse — und Mythos greift es direkt auf. In diesem Modell wird Sicherheit als Stapel löchriger Käsescheiben dargestellt: Ein Angriff gelingt nur dann, wenn alle Löcher in allen Scheiben exakt übereinander liegen. Entferne eine Scheibe — oder schließe auch nur ein Loch — und der Angriffspfad kollabiert.

Genau das macht Mythos: Es schließt bekannte Löcher systematisch und in großem Maßstab. Bei einem Exploit, der auf einer Kette von fünf bekannten Schwachstellen beruht, reicht es oft, eine einzige zu eliminieren, um den gesamten Angriff zu stoppen. Die Metapher aus dem Originaltext trifft es gut: Je mehr die Käsescheiben Richtung Cheddar tendieren — also je dichter und konsistenter das Material wird — desto weniger funktioniert das Swiss-Cheese-Modell als Angriffsbeschreibung.

Das Pendant aus der Luftfahrt ist lehrreich. Zu Beginn des Jet-Zeitalters hatten neue Flugzeuge strukturelle und mechanische Mängel, die sie aus dem Himmel fallen ließen. Über Jahrzehnte verbesserten sich Material, Design und regulatorische Disziplin gemeinsam. Heute sind Abstürze fast ausnahmslos auf Faktoren zurückzuführen, die hätten verhindert werden können — nicht auf unbekannte Materialfehler. Die These lautet: Code-Sicherheit könnte denselben Weg gehen. Wir entwickeln Software seit ungefähr so langer Zeit, wie wir Düsenflugzeuge bauen. Die Reife kommt — aber sie braucht Zeit und die richtigen Werkzeuge.

Was bleibt, sind die Schwachstellen außerhalb des Codes selbst: Supply-Chain-Exploits, Insider-Sabotage, fehlerhafte Konfigurationen. Mythos löst diese nicht. Aber auch hier gilt die Logik: Soweit diese Angriffsmuster kodierbar, modellierbar und trainierbar sind, werden KI-Systeme langfristig auch dort angreifen. Die vollständige Lösung liegt nicht im Tool allein — sie liegt im Zusammenspiel von KI-gestützter Automatisierung und menschlicher Expertise.

So setzt du Mythos-ähnliche Tools im Workflow ein

Solange Mythos unter Project Glasswing auf vertrauenswürdige Partner beschränkt bleibt, ist der direkte Zugang für die meisten Teams nicht verfügbar. Aber die Klasse von Tools, die Mythos repräsentiert, ist bereits breiter zugänglich — und die Frage, wie du solche KI-gestützten Vulnerability-Scanner sinnvoll in deinen Entwicklungsworkflow integrierst, ist jetzt relevant. Hier ist eine praxisnahe Schritt-für-Schritt-Struktur:

1. Schritt 1 — Trainingsdaten-Audit des Tools: Bevor du ein KI-Sicherheitstool einsetzt, frage den Anbieter explizit: Auf welchen Schwachstellenklassen wurde trainiert? Welche CVE-Jahrgänge sind im Trainingsset? Erwartetes Ergebnis: Eine ehrliche Antwort schränkt den Einsatzbereich sinnvoll ein. Pfad: Vendor Documentation → Training Data Disclosure.
2. Schritt 2 — Scope-Definition für bekannte vs. unbekannte Schwachstellen: Teile deine Security-Roadmap in zwei Spuren. Spur A (bekannte Klassen, hohe Automatisierung) eignet sich für KI-Tools. Spur B (Novel Threats, Zero-Days, kontextspezifische Logikfehler) bleibt beim menschlichen Analysten. Das verhindert false Confidence.
3. Schritt 3 — Integration in CI/CD-Pipeline: Binde das Tool als Gate in deinen Build-Prozess ein. Repository → CI/CD Settings → Security Scan → Fail on Critical. Erwartetes Ergebnis: Bekannte Schwachstellenklassen werden vor dem Merge blockiert, nicht erst im Prod-Deployment.
4. Schritt 4 — False-Positive-Kalibrierung: Sammle in den ersten vier Wochen alle False Positives und False Negatives. Kalibriere den Schwellenwert des Tools entsprechend. Ohne diese Feedback-Schleife läuft das Tool im Rauschen. Pfad: Tool Settings → Threshold → Custom Ruleset → Feedback Loop.
5. Schritt 5 — Menschliche Review für High-Stakes-Code: Definiere eine Liste von Code-Bereichen mit hohem Schadenspotenzial (Auth-Layer, Payment-Integration, API-Gateways). Hier gilt: KI-Scan als erster Filter, menschliche Expertise als zweiter. Keines der beiden allein reicht.
6. Schritt 6 — Regelmäßiges Retraining-Check: Prüfe vierteljährlich, ob der Anbieter neue Schwachstellenklassen ins Modell aufgenommen hat. KI-Sicherheitsmodelle ohne Update-Zyklus veralten schneller als traditionelle Signatur-Scanner.

Was sich rechnet — und was nicht

Die ROI-Rechnung für KI-gestützte Vulnerability-Scanner hängt stark vom Ausgangs-Setup ab. Ein realistisches Szenario für ein mittelgroßes Entwicklerteam mit einer Codebasis von rund 500.000 Zeilen:

Manueller Ansatz: Ein erfahrener Security-Analyst benötigt für einen vollständigen Code-Review etwa 40 Stunden bei einem Tagessatz von 1.200 Euro — Gesamtkosten rund 6.000 Euro pro Review-Zyklus, typischerweise quartalsweise. Dazu kommt: Bei manueller Arbeit wird selektiv geprüft, nicht die gesamte Codebasis. Bekannte Schwachstellenklassen in wenig frequentiertem Legacy-Code werden oft übersehen.

Mit KI-gestütztem Tool: Kontinuierlicher Scan im CI/CD-Prozess. API-Kosten je nach Anbieter im Bereich von wenigen Hundert Euro monatlich — konservativ geschätzt 300 bis 500 Euro für eine Codebasis dieser Größe. Menschliche Expertise wird auf die verbleibenden Spur-B-Bereiche konzentriert: Novel Threats, Architektur-Reviews, Kontextprüfungen. Hier reichen 8 bis 10 Stunden pro Quartal statt 40.

Im Klartext: Der manuelle Aufwand für bekannte Schwachstellenklassen sinkt um rund 75 Prozent. Die gesparte Zeit fließt in Bereiche, wo KI-Tools strukturell versagen. Das ist kein Effizienzgewinn auf dem Papier — es ist eine Neuallokation von knapprarer menschlicher Expertise auf die Probleme, die wirklich menschliches Urteil erfordern.

Der Haken: Diese Rechnung funktioniert nur, wenn du die Grenzen des Tools kennst und nicht fälschlich annimmst, dass der KI-Scan "alles abgedeckt" hat. False Confidence ist in Security tödlicher als kein Tool.

Die typischen Fallstricke beim Einsatz von KI-Sicherheitsscannern

Drei Fehler tauchen in der Praxis immer wieder auf — mit konkreten Lösungsansätzen:

• Fallstrick 1 — Vollständigkeitsilusion: Teams gehen davon aus, dass ein "sauberer" KI-Scan bedeutet, der Code sei sicher. Das ist falsch. KI-Sicherheitstools erkennen nur, was sie gelernt haben. Lösung: Interne Kommunikation klar halten — der Scan-Bericht heißt "Keine bekannten Schwachstellenklassen gefunden", nicht "Sicher".
• Fallstrick 2 — Kein Update-Zyklus: Ein einmal eingebundenes Tool wird nicht mehr hinterfragt. Neue Schwachstellenklassen, die nach dem Trainings-Cutoff des Modells entdeckt wurden, bleiben unsichtbar. Lösung: Quartalsweiser Check der Anbieter-Release-Notes und explizite Frage: "Welche neuen Klassen wurden seit letztem Quartal aufgenommen?"
• Fallstrick 3 — Datenschutz und EU AI Act: KI-Sicherheitsscanner, die Code-Snippets an externe APIs senden, übertragen unter Umständen personenbezogene Daten oder Geschäftsgeheimnisse. Das berührt Art. 28 DSGVO (Auftragsverarbeitung) und je nach Klassifikation des Systems auch den EU AI Act. Seit August 2025 gelten die GPAI-Regeln und Governance-Anforderungen. Ab August 2026 greift der Hauptteil des AI Act für Hochrisiko-KI. Security-Tools, die in kritische Infrastruktur eingebettet sind, könnten als Hochrisiko eingestuft werden. Lösung: Vor dem Einsatz prüfen, ob der Anbieter eine EU-konforme Datenverarbeitung nachweisen kann, und einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abschließen.

So What? Die strategische Einordnung für DACH-Teams

Für Security-Teams in Deutschland, Österreich und der Schweiz ist Mythos zunächst ein Signal, kein Produkt. Project Glasswing ist restriktiv, der direkte Zugang bleibt vorerst auf vertrauenswürdige Partner beschränkt. Die eigentliche Frage ist eine andere: Wie positionierst du dein Team für die Phase, in der solche Tools breit verfügbar werden?

Der DACH-Mittelstand hat hier ein spezifisches Problem. Laut aktuellen Daten haben 94 Prozent der deutschen Mittelstandsfirmen noch keine KI implementiert. Wer jetzt wartet, bis KI-Sicherheitstools den Mainstream erreichen, wird in einer Übergangsphase operieren, in der Angreifer dieselben Tools bereits nutzen — aber auf eine Legacy-Infrastruktur treffen, die im Pre-Industrial-Age der Vulnerability-Detection entwickelt wurde. Das ist die Asymmetrie, die gefährlich wird.

Konkret heißt das: Investiere jetzt in die Trainingsbasis deines Teams. Nicht in Mythos selbst, sondern in das Verständnis, wie KI-gestützte Vulnerability-Scanner arbeiten, wo sie versagen und wie man False-Positive-Raten kalibriert. Teams, die diese Kompetenz aufgebaut haben, wenn die Tools breit verfügbar werden, werden den Übergang deutlich besser meistern als Teams, die dann von null anfangen.

Für den EU AI Act gilt: Security-Tools mit Entscheidungsautonomie — etwa solche, die automatisch Pull-Requests blockieren oder Deployments stoppen — könnten je nach Risikoklassifikation unter die Hochrisiko-Anforderungen des AI Act fallen, die ab August 2026 greifen. Das betrifft besonders Teams in regulierten Branchen: Finanzdienstleistungen, Gesundheitswesen, kritische Infrastruktur. Hier ist es ratsam, bereits jetzt eine interne KI-Risikoklassifikation durchzuführen und Dokumentationspflichten vorzubereiten.

Der Vergleich zur Luftfahrt, den der Originaltext zieht, hat eine unbequeme Implikation für den DACH-Raum: Es gibt kein IT-Äquivalent der Luftfahrtbehörde, das veraltete, ungepatchte Systeme vom Netz nehmen kann. Solange große Teile der Unternehmens-IT auf alten, schlecht konfigurierten Systemen laufen, bleibt das Potenzial von Tools wie Mythos begrenzt — unabhängig davon, wie gut die Modelle werden.

Fazit: Nützliches Werkzeug, überhöhte Erwartungen

Mythos ist kein Mythos im Sinne göttlicher Fähigkeiten. Es ist ein gut durchdachtes, verantwortungsvoll eingeführtes KI-Werkzeug mit einer klaren Stärke und einer ebenso klaren Grenze. Die Stärke: Bekannte Schwachstellenklassen in großem Maßstab und hoher Geschwindigkeit zu erkennen. Die Grenze: Was das Modell nicht gelernt hat, findet es nicht — und dieser blinde Fleck ist strukturell, nicht behebbar durch mehr Rechenleistung allein.

Der kontrollierte Rollout unter Project Glasswing ist kein Zeichen von Schwäche. Er ist ein seltenes Beispiel dafür, dass ein KI-Unternehmen die eigenen Limitierungen ernst nimmt und nicht mit unrealistischen Versprechen in den Markt geht. Das verdient Anerkennung — auch wenn es den Zugang für die meisten Teams vorerst versperrt.

Für dich als DACH-Praktiker ist die Handlungsempfehlung klar: Bau jetzt die Kompetenz auf, solche Tools zu evaluieren, zu kalibrieren und in sichere Workflows zu integrieren. Wenn Mythos oder vergleichbare Tools den Mainstream erreichen, wird der Wettbewerbsvorteil nicht beim Zugang liegen — er liegt im Know-how, das Tool richtig einzusetzen. Und unterschätze nie den menschlichen Faktor: Die Luftfahrt hat ihren Sicherheitsgewinn nicht durch bessere Flugzeuge allein erreicht, sondern durch das Zusammenspiel von Technik, Regulierung und menschlicher Expertise. Code-Sicherheit wird genauso funktionieren.