Project Glasswing ist nicht für euch. Diese Strategien sind es.

Am 7. April 2026 hat Anthropic Claude Mythos Preview angekündigt und gleichzeitig mitgeteilt, dass es für die breite Öffentlichkeit nicht verfügbar sein wird. Die Begründung: Mythos kann autonome Zero-Day-Exploits entwickeln, die alle außer den fähigsten menschlichen Security-Forschern übertreffen — und das über Nacht, ohne menschliche Steuerung. In wenigen Wochen Interner Testing fand das Modell tausende kritische Lücken in jedem großen Betriebssystem und Browser. Ein 27 Jahre altes OpenBSD-Bug, 16 Jahre alt in FFmpeg, eine Privilege-Escalation-Chain im Linux-Kernel. Bugs die Millionen automatisierter Tests überlebt hatten.

Gut 40 Unternehmen haben Zugang, der Rest nicht. Die Frage die seitdem in Security-Channels kursiert: Was machen wir, während Mythos tausende ungepatchter Zero-Days in unserem Stack kennt — und wir nicht?

Was Mythos über euren Stack weiß, den ihr vielleicht nicht kennt

Über 99 % der von Mythos gefundenen Vulnerabilities sind laut Anthropic noch ungepacht. Anthropic hat für alle bekannten Patches kryptographische Hashes der Details veröffentlicht — die Spezifika kommen nach dem Fix. Für alles andere läuft die Uhr. Was das konkret bedeutet: Wenn euer Stack Linux, glibc, OpenSSL, FFmpeg, einen der großen Browser, irgendeinen der populären Open-Source-Parser oder Netzwerkbibliotheken enthält — und das tut er —, dann sind mit hoher Wahrscheinlichkeit Vulnerabilities bekannt, die ihr nicht kennt.

Das ist keine abstrakte Bedrohung. Auf CyberGym, einem Benchmark für Vulnerability Reproduction, erzielt Mythos Preview 83,1 %. Zum Vergleich: Claude Opus 4.6 erreicht 66,6 %. Das heißt: Das beste öffentlich zugängliche Modell ist deutlich unter Mythos — aber weit über null. Die Capability-Entwicklung zeigt eindeutig wohin es geht. Was Mythos heute kann, werden günstigere Modelle in 12–24 Monaten zumindest annähernd können. Angreifer warten nicht auf ethische Zugangsprozesse.

Architektur: Systeme die standhalten wenn Lücken gefunden werden

Der wichtigste Schritt ist kein Tool. Es ist die Akzeptanz der Prämisse: Vulnerabilities existieren in eurem System, ihr wisst nur noch nicht welche. Security-Architektur bedeutet dann, Systeme so zu bauen dass eine gefundene und ausgenutzte Lücke minimalen Schaden anrichtet.

Least Privilege konsequent umsetzen. Jeder Prozess, jeder Service, jeder User hat nur die Rechte die er für seine konkrete Funktion braucht — und nicht einen Scope mehr. Das klingt banal, weil es in fast jedem Security-Dokument steht. Es ist in den meisten Produktionssystemen trotzdem nicht konsequent umgesetzt. Ein kompromittierter Service der nur Read-Zugriff auf eine spezifische Datenbank hat, ist ein anderes Problem als einer der als Root läuft. Least Privilege ist die wichtigste Single-Maßnahme bei Privilege-Escalation-Chains — der Klasse die Mythos besonders zuverlässig ausnutzt.

Netzwerksegmentierung. Services kommunizieren nur mit den anderen Services die sie direkt brauchen, auf spezifischen Ports, über explizit definierte Channels. Kein „flat network" wo ein kompromittierter Web-Server direkten Zugriff auf alle Datenbanken hat. Zero-Trust-Netzwerk-Architektur ist 2026 keine theoretische Übung mehr, sie ist Mindeststandard.

Attack Surface aktiv reduzieren. Was nicht läuft, kann nicht kompromittiert werden. Ungenutzte Services abschalten. Alte Dependencies entfernen. Exponierte Admin-Endpoints hinter Auth. API-Gateways vor alle externen Endpoints. Die Angriffsfläche die Mythos durchsucht ist proportional zu dem was ihr exponiert.

Memory-Safe Languages für kritischen Neucode. Microsoft plant, bis 2030 allen C/C++-Code mit AI-Unterstützung in Rust zu migrieren. Google und Mozilla fahren denselben Kurs inkrementell. Der Grund: Memory-Corruption-Bugs — Buffer Overflow, Use-after-free, Heap-Spray — sind die Klasse die Mythos am zuverlässigsten findet und ausnutzt, und Rust eliminiert sie durch das Typsystem zur Compile-Zeit. Für neuen kritischen Code (Netzwerk-Parser, Auth-Logic, Input-Handling) ist Rust 2026 keine akademische Präferenz mehr.

Kostenlose Tools die ihr morgen in die Pipeline einbauen könnt

Semgrep OSS. Kostenloser Static Analysis Scanner, sehr schnell, CI/CD-nativ, unterstützt Python, Java, Go, JavaScript/TypeScript, Ruby, C/C++, Rust und weitere. Die entscheidende Neuerung für 2026: Semgrep hat einen Open-Source-MCP-Server veröffentlicht, der sich direkt in Claude Code und Cursor integriert. Das bedeutet: Claude scannt beim Code schreiben automatisch auf Injection-Flaws, hardcodierte Secrets und unsichere Patterns — und meldet sie inline, ohne manuellen CLI-Aufruf. Für Teams bis 10 Contributor ist die Pro-Engine inklusive.

CodeQL / GitHub Advanced Security. CodeQL ist für Open-Source-Projekte kostenlos und direkt in GitHub Actions integrierbar. Copilot Autofix schlägt für 90 % der erkannten Alert-Typen automatisch Code-Korrekturen vor. Für Enterprise-Repos kostet GitHub Advanced Security $19 pro Seat und Monat — das ist der einfachste Weg zu einer durchgehenden Scan-Pipeline wenn ihr schon in GitHub seid.

OSV-Scanner + Dependabot / Renovate. Supply-Chain-Angriffe sind die zweithäufigste Angriffsvektoren hinter direkten Code-Vulnerabilities. OSV-Scanner (Google, kostenlos) matched Dependencies gegen die Open Source Vulnerability Database. Dependabot oder Renovate automatisieren Pull Requests für veraltete Dependencies. Beides in unter einer Stunde eingerichtet, beides kostenlos.

Trivy. Kostenloser Container-Scanner der Images, Filesystems, Git-Repos und IaC-Konfigurationen scannt. Findet bekannte CVEs in Base-Images und Dependencies, Secrets in Configs, und Fehlkonfigurationen in Kubernetes- und Terraform-Files. In CI/CD als Step ergänzt, blockiert Deployments mit kritischen Findings.

Services die ihr buchen könnt für tiefere Abdeckung

Aikido Security. Das Produkt das 2026 am häufigsten als „Semgrep/Snyk-Alternative für Teams ohne dedicated Security-Engineer" genannt wird. Aikido kombiniert SAST, SCA, Secrets Detection, Container Scanning, DAST und IaC-Checks in einem Single-Pane-of-Glass mit deutlich weniger False Positives als die Einzeltools. Freemium-Einstieg verfügbar, bezahlte Tiers skalieren mit Repos und Entwicklerzahl. Für Teams die fünf verschiedene Scan-Kategorien brauchen aber keine fünf verschiedenen Tools verwalten wollen, ist Aikido aktuell die pragmatischste Wahl.

Snyk Team. Marktführer für Developer-First-Security, besonders stark bei Dependency-Scanning und Container-Sicherheit. Ab $25 pro Entwickler und Monat. Die Stärke von Snyk liegt in der Remediation-Guidance: nicht nur finden, sondern priorisierter Fix-Pfad mit Exploit-Likelihood-Einschätzung. Für Teams mit vielen Third-Party-Dependencies oder komplexen Container-Stacks nach wie vor die erste Wahl.

GitHub Advanced Security. Wenn ihr auf GitHub seid und noch kein GHAS-Abo habt, ist das die niedrigschwelligste kostenpflichtige Option. CodeQL, Secret Scanning, Dependency Review und Copilot Autofix in einem — $19/Seat/Monat für nicht-Enterprise. Die Integration in den Pull-Request-Workflow ist besser als bei jedem anderen Tool.

Armorcode / ASPM für größere Teams. Ab ~20 Entwicklern mit mehreren Scan-Tools entsteht ein neues Problem: zu viele Findings aus zu vielen Quellen ohne gemeinsame Priorisierung. Application Security Posture Management-Plattformen wie Armorcode aggregieren Outputs aus SAST, SCA, DAST, Container-Scanning und Cloud-Security in einem Risk Graph. Das ist keine Scan-Erweiterung, sondern Triage-Infrastruktur. Relevant wenn Teams an Findings-Overload leiden, nicht an Findings-Mangel.

Was ihr mit dem KI-Tooling habt, das ihr schon bezahlt

Claude Opus 4.6 ist kein Mythos. Auf CyberGym liegt Opus bei 66,6 % — 16,5 Prozentpunkte unter Mythos, aber deutlich über dem was die meisten Teams heute ohne dedizierten Security-Engineer machen. Konkret nutzbar:

STRIDE-Threat-Modeling per Conversation. Ein Systemdiagramm beschreiben (Services, Datenpfade, externe Schnittstellen, Trust Boundaries), dann Claude durch die sechs STRIDE-Kategorien führen: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Das Ergebnis ist kein Penetration-Test-Report, aber es deckt systematisch Klassen auf die ohne strukturiertes Threat Modeling übersehen werden. Eine 90-minütige STRIDE-Session mit Claude ist für die meisten Teams besser als gar keine.

Code-Review mit Security-Fokus. Claude reviewt Pull Requests auf konkrete Vulnerability-Klassen: Auth-Bypasses, IDOR-Potenzial, fehlende Input-Validation, unsichere Deserialization, Secrets in Code, unsichere Kryptographie-Verwendung. Kein autonomes Vuln-Finding auf Mythos-Niveau — aber ein zweites Paar Augen das systematisch sucht. In Kombination mit dem Semgrep-MCP-Plugin ergibt sich ein CI/CD-nativ laufender, AI-gestützter Scan-Layer der für kleine Teams einen echten Unterschied macht.

Dependency-Audit per Prompt. Eine package-lock.json oder pom.xml einpassen und fragen: "Welche dieser Dependencies haben bekannte kritische CVEs, welche haben Security-Historien die Aufmerksamkeit verdienen?" Claude kennt Vulnerability-Historien bis zu seinem Knowledge-Cutoff und kann priorisieren was für manuelles OSV-Scanner-Aufholen wichtig ist.

Der Prozess ist die Härtung

Tools die einmal laufen und dann vergessen werden, schützen nicht. Was nachhaltigen Unterschied macht:

Ein Software Bill of Materials aufbauen und aktuell halten. SBOM ist 2026 in Procurement-Anforderungen auf dem Weg zur Pflicht. Aber unabhängig davon: wer weiß was in seinem Stack steckt, kann auf eine CVE-Disclosure innerhalb von Stunden reagieren statt innerhalb von Wochen. Das ist der entscheidende Unterschied wenn Mythos-Klasse-Capability mehr Akteuren zugänglich wird.

Patch Velocity messen. Zeit von Disclosure bis Deployment ist die Security-Metrik die 2026 am meisten zählt. CrowdStrike-CTO Elia Zaitsev hat bei der Glasswing-Ankündigung formuliert: "Das Fenster zwischen Entdeckung einer Vulnerability und Ausnutzung durch Angreifer ist kollabiert — was früher Monate dauerte, passiert jetzt in Minuten mit KI." Wer drei Wochen für Security-Patches braucht, ist in diesem Umfeld verwundbar. Wer das als automatisierten PR mit Dependabot + Staging-Pipeline löst, ist es weniger.

Eine Vulnerability Disclosure Policy veröffentlichen. Wenn externe Researcher in euren Systemen Lücken finden, brauchen sie eine definierte Anlaufstelle und ein kommuniziertes SLA. Ohne das werden Findings entweder gar nicht gemeldet oder öffentlich gemacht bevor ihr reagieren konntet. Das kostet keine Security-Engineers — nur einen security.txt-Eintrag und eine Policy-Seite.

Quellen: Anthropic Project Glasswing (April 2026). Claude Mythos Preview — red.anthropic.com. Help Net Security. Semgrep. CyberGym-Benchmark-Daten aus dem Glasswing-Announcement.