Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Die KI ist dabei, die Art und Weise, wie Software-Schwachstellen entdeckt werden, zu überholen – nicht jedoch die Art und Weise, wie sie behoben werden.
Im April 2026 kündigte Anthropic an das Projekt Glasswing zusammen mit elf bedeutenden Partnern, darunter AWS, Apple, Cisco, Google, JPMorgan Chase, die Linux Foundation, Microsoft und Palo Alto Networks.
Im Mittelpunkt der Initiative steht „Claude Mythos Preview“, ein bahnbrechendes Modell, das bereits Tausende von Sicherheitslücken mit hohem Schweregrad aufgedeckt hat, darunter Fehler in allen gängigen Betriebssystemen und Webbrowsern. Einige dieser Schwachstellen hatten jahrzehntelange manuelle Prüfungen überstanden – was die Lage für alle, die Software mit Open-Source-Komponenten vertreiben, grundlegend verändert.
Auch wenn der Zugang derzeit noch eingeschränkt ist, ist die Richtung klar: Die Erkennung von Sicherheitslücken wird schneller, kostengünstiger und zunehmend automatisiert – und sie wird nicht auf eine kleine Gruppe von Sicherheitsfachleuten beschränkt bleiben.
Bei der Sicherheit von Open-Source-Lieferketten dreht sich alles um eine Frage: Wer ist für welche Fehlerbehebung zuständig – und wie schnell wird diese durchgeführt? Seit Glasswing verläuft die Erkennung von Schwachstellen durch KI mit maschineller Geschwindigkeit, während das Patchen nach wie vor im Kalendertakt erfolgt.
Dieser Druck wirkt sich auf zwei verschiedene Aspekte des Open-Source-Risikos aus: zum einen darauf, was man installiert, und zum anderen darauf, was danach geschieht. Beim einen geht es um das Vertrauen in das Paket selbst, beim anderen darum, ob Sicherheitslücken überhaupt behoben werden. Beide Aspekte werden in unterschiedlicher Weise auf die Probe gestellt werden.
Und die Aufsichtsbehörden haben sich klar ausgedrückt: Wer die Binärdatei ausliefert, ist für den Fehler verantwortlich.
Das Projekt Glasswing und die CVE-Flut, die auf Ihre Abhängigkeiten zukommt
Mythos Preview ist kein schnellerer Scanner. Es analysiert komplexe Codebasen und generiert funktionierende Exploits, keine theoretischen Erkenntnisse. Anthropic hat den Zugriff auf Glasswing-Partner eingeschränkt, gerade weil dieselbe Fähigkeit letztendlich in die Hände von Angreifern gelangen würde. Das Zeitfenster für Verteidiger ist eng, und die meisten Teams haben ihre Annahmen noch nicht angepasst.
Für Unternehmen, die auf Open-Source-Pakete angewiesen sind, sind zwei konkrete Konsequenzen von Bedeutung.
Zunächst einmal wird die Zahl der CVEs steigen. Mythos hat bereits Tausende von Fehlern in gründlich geprüften Codes aufgedeckt. Die Open-Source-Bibliotheken für den produktiven Einsatz, die noch nie einer derart gründlichen Prüfung unterzogen wurden, werden ebenso behandelt werden, sobald vergleichbare Modelle auf den breiteren Markt kommen. Die meisten Sicherheitsteams hinken bereits bei der Bearbeitung des bestehenden CVE-Rückstands hinterher.
Zweitens verkürzt sich die Zeitspanne zwischen Bekanntgabe und Ausnutzung erheblich. Ein 30-Tage-SLA für Patches basierte auf der Verzögerung zwischen der Veröffentlichung einer CVE und dem Vorhandensein eines funktionierenden Exploits dafür. Mythos schließt diese Lücke in nur einer Sitzung.
Wenn Ihre Patching-Strategie von einem gleichmäßigen, überschaubaren Strom von CVEs in aktiv gepflegten Paketen ausgeht, werden beide Teile dieser Annahme bald nicht mehr zutreffen.
Kurz gesagt:
- Die Aufdeckung von Sicherheitslücken nimmt zu
- Die Entwicklung von Exploits nimmt zu
- Die Patching-Geschwindigkeit ist nicht
Genau in dieser Lücke häufen sich die Risiken.
Du bist für jede von dir ausgelieferte Abhängigkeit verantwortlich
Die regulatorische Wende verlief zwar weniger spektakulär als die Ankündigung zur KI, ist aber ebenso folgenreich.
Gemäß dem EU-Gesetz zur Cyber-Resilienzsind Hersteller für die Sicherheit von Produkten mit digitalen Elementen während ihrer gesamten Supportdauer verantwortlich, einschließlich aller integrierten Open-Source-Komponenten. Die Strafen betragen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Als Hersteller gilt das Unternehmen, das das Produkt auf den Markt bringt. Es spielt keine Rolle, wer die Abhängigkeit geschrieben hat, ob der Betreuer bezahlt wird oder ob das Upstream-Projekt aufgegeben wurde. Wer es ausliefert, trägt die Verantwortung.
FedRAMP Die FedRAMP-Richtlinien haben sich in die gleiche Richtung entwickelt. Von Cloud-Dienstleistern wird erwartet, dass sie die Sicherheit jeder Komponente innerhalb ihres Autorisierungsbereichs gewährleisten, wobei dokumentierte Patch-Prozesse und Software am Ende der Lebensdauer (EOL) als bekanntes Autorisierungsproblem gekennzeichnet werden. Unter FedRAMP 20xwerden SBOMs, die mit den tatsächlich ausgeführten Komponenten übereinstimmen, zu einer Grundvoraussetzung.
Auch die Kundenverträge haben aufgeholt. Die Beschaffungsteams verlangen nun SBOMs, VEX -Dokumente und Patch-SLAs als Standardpositionen. „Wir nutzen eine Bibliothek eines Drittanbieters“ ist keine Antwort, wenn ein Exploit die Produktion erreicht.
Das Rechtsmodell lässt sich einfach zusammenfassen: Die Haftung richtet sich nach dem Binärcode, nicht nach der Lizenz des Quellcodes. Die „Many-Eyes“-Verteidigung war rechtlich nie stichhaltig, und seit dem Fall Glasswing ist sie auch technisch nicht mehr tragfähig.
Open Source birgt zwei unterschiedliche Risiken
Die Integration von Open-Source-Software in Ihre Infrastruktur birgt zwei unterschiedliche Risiken. Das erste betrifft die Integrität der Lieferkette: Was befindet sich tatsächlich in dem Paket, wenn Sie es installieren? Das zweite betrifft die Patching-Prozesse: Wie schnell wird eine bekannte Sicherheitslücke behoben, und was passiert, wenn kein Patch verfügbar ist?
Es handelt sich um unterschiedliche Probleme mit unterschiedlichen Bedrohungsmodellen. Angriffe auf die Lieferkette sind ein Problem im Zusammenhang mit Zugangsdaten und Vertrauen. Glasswing hat damit nichts zu tun, und diese Angriffe nehmen seit Jahren auf eigene Faust zu. Im Bereich der Patches verändert Glasswing die Situation grundlegend, sowohl während der aktiven Wartung als auch nach dem Ende des Lebenszyklus (EOL). Diese Kombination ist das Neue daran. Dasselbe Sicherheitsteam, das bereits eine konstante Rate an Angriffen auf die Lieferkette bewältigte, muss nun eine schnellere und umfangreichere Flut von CVEs über den gesamten Abhängigkeitsbaum hinweg bewältigen.
Die Haftung kümmert sich nicht darum, welches Problem Sie getroffen hat. Gehen wir nun nacheinander auf jedes einzelne ein.
Die Gefahr vom ersten Tag an: Kompromittierte Pakete
Das größte Risiko bei jeder Abhängigkeit ist der Inhalt, der zum Zeitpunkt der Installation vorhanden ist. Manipulierte Artefakte, gehackte Konten von Betreuern und durch Typosquatting entstandene Fälschungen gelangen seit Jahren über vertrauenswürdig erscheinende Registry-Installationen in die Produktionsumgebung.
März 2026 Axios-Hack ist das prominenteste Beispiel aus jüngster Zeit: Anmeldedaten wurden vom Hauptbetreuer des Projekts gestohlen, und ein bösartiger Postinstall-Hook wurde drei Stunden lang an rund 100 Millionen wöchentliche Downloader verteilt.
Zu den weiteren Fällen der letzten Zeit gehört der Shai-Hulud-Wurm sowie den Bitwarden-CLI-Vorfall , der auf Anmeldedaten für KI-Programmierwerkzeuge abzielte.
Diese Kategorie ist ein Sonderfall. Glasswing macht Angriffe auf die npm-Lieferkette weder einfacher noch schwieriger, und Mythos kann einem Angreifer nicht dabei helfen, das Konto eines Betreuers zu kompromittieren. Doch die Bedrohung eskaliert seit Jahren allein aufgrund der Anreize für Angreifer, und im Rahmen der CRA fällt sie unter dieselbe Haftungskategorie wie alles andere, was Sie ausliefern. Die Erkennung erfolgt erst Stunden nach dem Vorfall.
Zur Vorbeugung ist eine Paketquelle erforderlich, die verifiziert und signiert ist und aus überprüfbaren Quellen neu erstellt wurde, anstatt direkt aus einem öffentlichen Repository bezogen zu werden.
Die Gefahr durch Sicherheitslücken: Aktive und EOL-Software
Bei Angriffen auf die Lieferkette geht es darum, wer die Kontrolle über das Artefakt hat. Bei der Patch-Lücke geht es um etwas anderes: darum, wie schnell ein bekannter Fehler in einem vertrauenswürdigen, unverfälschten Paket in dem von Ihnen ausgeführten Code behoben wird.
Es zeigt sich in zwei Formen – langsame Patches für gepflegte Bibliotheken und gar keine Patches für solche, deren Lebensdauer abgelaufen ist (EOL). Glasswing verschlimmert beides.
Wenn nach Sicherheitslücken Patches veröffentlicht werden
Die Zeit bis zur Veröffentlichung eines Patches variiert innerhalb des Ökosystems stark. Führende Projekte mit koordinierter Offenlegung veröffentlichen den Patch, sobald die CVE-Nummer veröffentlicht wird. Der Rest des Feldes bewegt sich langsamer: Stunden für geringfügige Korrekturen, Wochen oder länger, wenn der Betreuer Backports vornehmen, die API-Kompatibilität wahren oder die Arbeit neben seinem Hauptberuf erledigen muss.
Durch die Bereitstellung in Ihrer Umgebung verlängert sich die Dauer zusätzlich zu dem ursprünglich vorgesehenen Zeitfenster.
Früher war dieses Zeitfenster noch erträglich. Die Entwicklung von Exploits verlief so langsam, dass die Verteidiger einen echten Vorsprung gegenüber den Angreifern hatten.
Mythos macht diesen Vorsprung zunichte. Die Erkennung und Ausnutzung von Schwachstellen erfolgt nun in einem einzigen Schritt, und diese Fähigkeit bleibt nicht mehr nur den Verteidigern vorbehalten. Sobald vergleichbare Modelle in die Hände von Angreifern gelangen, wird das Zeitfenster für die Bereitstellung von Patches zu einem Zeitfenster, in dem die Schwachstelle offenliegt. Bis der Patch verfügbar ist, ist der Exploit bereits seit Tagen im Umlauf.
Das Paket wird aktiv gepflegt und der Betreuer reagiert schnell. All das nützt jedoch nichts, wenn ein System bereits am dritten Tag eines vierzehntägigen Patch-Zyklus kompromittiert wurde.
EOL-Bibliotheken nach Glasswing
Der Zeitraum nach dem EOL-Datum ist die Patch-Lücke, in der keine Patches mehr veröffentlicht werden – und das für immer.
Log4Shell (CVE-2021-44228) gehört auch mehr als vier Jahre nach seiner Bekanntgabe noch immer zu den zehn am häufigsten ausgenutzten Sicherheitslücken, da Log4j nach wie vor in Altanwendungen eingebettet ist, die niemand migrieren möchte. Das gleiche Muster zeigt sich bei der Vielzahl nicht mehr gepflegter Bibliotheken: bekannte Fehler, öffentlich zugängliche Exploits und eine Installationsbasis, deren Aktualisierung mit zu großen Umstellungen verbunden wäre. Datadogs „State of DevSecOps 2026“ ergab, dass Dienste, die auf EOL-Sprachversionen laufen, eine Rate an ausnutzbaren Schwachstellen von 50 % aufweisen, verglichen mit 31 % bei unterstützten Versionen, wobei die mediane Abhängigkeit 278 Tage hinter der neuesten Version zurückliegt.
Wende nun die Erkennung der Glasswing-Klasse auf diese Population an.
Ein Patch für eine gepflegte Bibliothek wird irgendwann veröffentlicht, wenn auch langsam. Wenn Mythos eine Zero-Day-Sicherheitslücke in Python 3.7, einer EOL-Version des Spring Frameworks oder einem der Tausenden von npm-Paketen entdeckt, deren Betreuer zuletzt vor zwei Jahren einen Kommentar hinterlassen hat, ist der Fehler öffentlich bekannt und bleibt für immer ungepatcht. Zwangs-Upgrades sind die Lösung, nach der jeder als Erstes greift. In der Praxis erfordern sie Migrationen mit grundlegenden Änderungen im Anwendungscode, der seit Jahren nicht mehr angefasst wurde, verbunden mit Regressionsrisiken und technischen Kosten, die Compliance-Teams nicht tragen können.
An diesem Punkt hört EOL auf, ein Wartungsproblem zu sein, und wird zu einem dauerhaften Sicherheitsrisiko.
In einer Welt nach Glasswing ist nicht mehr gepflegte Software nicht nur riskant – sie ist vorhersehbar und immer wieder ausnutzbar, ohne dass jemals ein Patch erscheinen wird.
Wie SecureChain für Open-Source-Software die Lücke schließt
SecureChain für Open-Source-Software ersetzt Ihre öffentlichen Paket-Registerstellen durch eine kontrollierte, kontinuierlich gesicherte Quelle. Ihre Entwickler arbeiten weiterhin so, wie sie es bereits tun.
Hinter einer einzigen Registrierungs-URL ändern sich drei Dinge:
- Jedes Paket wird aus geprüften Quelltexten neu kompiliert
Jedes Paket wird in einer gehärteten, isolierten Umgebung aus überprüfbarem Quellcode neu erstellt. Keine übernommenen Binärdateien, keine undurchsichtigen Upstream-Artefakte.
- Malware wird blockiert, bevor sie Ihren Stack erreicht
Jedes Paket wird auf Quellcodeebene auf schädlichen Code, verdächtige Installationshaken und bekannte Bedrohungssignaturen überprüft, bevor es in die Registrierungsdatenbank gelangt.
- Patches werden fortlaufend bereitgestellt – auch nach Ablauf der Lebensdauer
SecureChain stellt im Rahmen des SLA Patches bereit, sobald neue CVEs bekannt werden, einschließlich solcher, die unser Team beisteuert, wenn der Upstream-Entwickler dies nicht tut. Der Support wird auch nach Ablauf der Wartungsphase für die von Ihnen bereits genutzte Version fortgesetzt, ohne erzwungene Upgrades oder Code-Neuprogrammierungen.
Vom ersten Tag an auditfähig
Was die Compliance-Aspekte dieses Problems betrifft, so gibt es hierfür eigene Vorgaben. Jedes von SecureChain versandte Paket enthält SLSA Level 3 Build-Herkunft, eine signierte SBOM, die mit der von Ihnen erhaltenen Binärdatei übereinstimmt, sowie VEX-Dokumente, die jede für das Paket gemeldete CVE entweder als in der von Ihnen verwendeten Version gepatcht oder als nicht zutreffend kennzeichnen.
Diese drei Dokumente sind genau das, was Audit- und Beschaffungsteams tatsächlich benötigen. Die SLSA-Provenienz der Stufe 3 belegt, dass das Paket aus einer von Ihnen überprüfbaren Quelle in einer gesicherten Build-Umgebung erstellt wurde und während der Übertragung nicht manipuliert wurde. Die SBOM teilt Ihrem Auditor genau mit, was sich in der Produktion befindet. Das VEX-Dokument teilt Ihrem Scanner mit, welche Patches bereits installiert wurden und welche für diese Version nicht relevant sind, sodass Ihr Team keine CVEs nachverfolgen muss, die bereits behoben wurden.
Wenn man eine durch eine SLA abgesicherte Verpflichtung zur Fehlerbehebung hinzufügt, führt ein Anstieg der CVE-Zahlen nicht automatisch zu mehr Beanstandungen bei Audits. Die von Ihrem Compliance-Team benötigten Nachweise entstehen als Nebeneffekt der Patches selbst.
Was Ihre Teams davon haben
Open Source ist nach wie vor der richtige Weg, um Software zu entwickeln. Unter Druck geht man oft davon aus, dass die Einführung eines Pakets eine einmalige Entscheidung ist, die keine laufenden Sicherheitskosten verursacht.
SecureChain bietet Ihnen die Geschwindigkeit und Flexibilität von Open Source ohne das damit verbundene Risiko.
Ihr Team konzentriert sich auf die Entwicklung von Produkten, anstatt Sicherheitslücken hinterherzujagen. Ihre Entwickler installieren weiterhin die Pakete, die sie bereits nutzen. Ihre Build-Pipeline greift auf SecureChain statt auf das öffentliche Register zurück. Für die wichtigen Komponenten werden kontinuierlich Patches bereitgestellt, auch für solche, von denen sich die Open-Source-Community bereits verabschiedet hat. Herkunftsdaten und SBOMs werden automatisch erstellt. Wenn die nächste Sicherheitslücke vom Typ „Glasswing“ bekannt wird, ist die Reaktion ein Versionssprung und kein sechswöchiger Vorfall.
Sie müssen Ihren Stack nicht ersetzen, um dieses Risiko zu verringern – aber Sie müssen die Art und Weise ändern, wie er gewartet wird.
Die Verantwortung für das, was du versendest, bleibt bestehen. Nur der Transport selbst ändert sich.
