Software-Lieferkette unter Beschuss: Wie GlassWorm 400+ Entwickler-Tools kompromittierte

5 Min. Lesezeit

454.648 neue Schadpakete in Open-Source-Registries allein in 2025. 75 Prozent mehr als im Vorjahr. Und im März 2026 zeigt die GlassWorm-Kampagne, wie industrialisiert Software-Supply-Chain-Angriffe mittlerweile ablaufen: 433 kompromittierte Komponenten in einer Woche, getarnt durch unsichtbare Unicode-Zeichen und KI-generierte Cover-Commits. Für Unternehmen, die Open-Source-Abhängigkeiten nicht systematisch überwachen, wird die eigene Entwicklungsumgebung zum Einfallstor.

Das Wichtigste in Kürze

454.648 neue Schadpakete in Open-Source-Registries 2025 identifiziert, kumulativ über 1,2 Millionen bekannte Malware-Pakete (Sonatype, Januar 2026).
GlassWorm kompromittierte im März 2026 über 433 Komponenten: 72 VS-Code-Extensions, 88 npm-Pakete, 151+ GitHub-Repos (Aikido Security / BleepingComputer).
75 Prozent Wachstum bei Open-Source-Malware, Downloads auf 9.800 Mrd. gestiegen (Sonatype 2026 Report).
65 Prozent aller Open-Source-CVEs haben keinen CVSS-Score vom NVD erhalten – massive Bewertungslücke (Sonatype 2026).
NIS-2 fordert explizit Supply-Chain-Risikomanagement. Das BSI hat mit TR-03183-2 die SBOM-Pflicht als Basis definiert.

GlassWorm: Anatomie eines industrialisierten Angriffs

Im März 2026 deckten Sicherheitsforscher von Aikido Security eine der bislang ausgereiftesten Supply-Chain-Kampagnen auf. Die als GlassWorm bezeichnete Operation kompromittierte in weniger als zwei Wochen über 433 Software-Komponenten: 72 Visual-Studio-Code-Extensions im Open VSX Marketplace, 88 npm-Pakete und mehr als 151 GitHub-Repositories.

Das Besondere an GlassWorm war nicht die Masse, sondern die Methode. Die Angreifer nutzten unsichtbare Unicode-Zeichen – sogenannte Variation Selectors und Private-Use-Area-Codes – um schadhaften Code im Quelltext zu verstecken. Für menschliche Reviewer sah der Code sauber aus. Erst eine automatisierte Analyse der Byte-Sequenzen enthüllte die versteckten Payloads.

Dazu kamen KI-generierte „Cover Commits“: harmlos aussehende Code-Änderungen, die den eigentlichen Schadcode in der Commit-Historie tarnen sollten. Die Kommunikation mit den Command-and-Control-Servern lief über die Solana-Blockchain – mit Google Calendar als Fallback-Kanal. Klassische Netzwerk-Monitoring-Tools erkennen diese Kommunikationswege nicht, weil sie über legitime Dienste laufen.

454.648

neue Schadpakete in Open-Source-Registries (2025)

Quelle: Sonatype, State of the Software Supply Chain Report 2026

Die Ziele: Credentials für npm, GitHub und Git-Konfigurationen abgreifen, Krypto-Wallets leeren und persistente Backdoors in Entwicklerumgebungen installieren. Wer eine kompromittierte VS-Code-Extension installiert hatte, gab den Angreifern Zugriff auf seinen gesamten Arbeitsplatzrechner – inklusive aller dort gespeicherten Zugangsdaten.

Die Industrialisierung der Software-Lieferkette als Angriffsfläche

GlassWorm ist kein Einzelfall. Laut dem Sonatype „State of the Software Supply Chain Report 2026“ wurden allein 2025 über 454.648 neue Schadpakete in Open-Source-Registries wie npm, PyPI und Maven Central identifiziert. Das entspricht einem Wachstum von 75 Prozent gegenüber dem Vorjahr. Kumulativ sind mittlerweile über 1,2 Millionen bekannte Malware-Pakete dokumentiert.

Die Angriffsmethoden haben sich dabei fundamental verändert. Waren Supply-Chain-Angriffe vor wenigen Jahren noch das Werk einzelner Akteure, die Tippfehler in Paketnamen ausnutzten (Typosquatting), so operieren heute staatlich unterstützte Gruppen mit industriellen Mitteln. Die Lazarus Group (Nordkorea) setzte 2025 mehrstufige Payload-Ketten ein, bei denen ein einzelnes manipuliertes Paket eine Kaskade von fünf weiteren Schadkomponenten nachlud.

Der „Shai-Hulud“ Vorfall markiert einen weiteren Wendepunkt: der erste sich selbst reproduzierende npm-Wurm, der innerhalb weniger Tage über 500 neue Pakete im Registry erstellte. 55,9 Prozent aller dokumentierten Schadpakete nutzen mittlerweile Repository-Missbrauch als primäre Verteilungsmethode – die Registries werden systematisch wie Werbeplattformen bespielt.

Brian Fox, CTO von Sonatype, fasst die Lage zusammen: Open Source sei längst Produktionsinfrastruktur, Angreifer wüssten das, und KI beschleunige das gesamte System. Vertrauen müsse mit der Maschinengeschwindigkeit von Software mithalten – das erfordere automatisierte Schutzmaßnahmen im Workflow, nicht nachträgliche Reports (Sonatype, State of the Software Supply Chain Report 2026).

Warum klassische Sicherheitskonzepte versagen

Drei strukturelle Probleme machen die Abwehr von Supply-Chain-Angriffen besonders schwierig:

Die NVD-Bewertungslücke: 65 Prozent aller Open-Source-CVEs haben laut Sonatype keinen CVSS-Score vom National Vulnerability Database erhalten. Vulnerability Scanner, die auf NVD-Daten basieren, sind damit systematisch blind für einen Großteil der bekannten Schwachstellen. Unternehmen, die sich ausschließlich auf automatisierte Scans verlassen, wiegen sich in falscher Sicherheit.

Entwickler-Workstations als blinder Fleck: IDE-Extensions werden in den meisten Unternehmen nicht durch die IT-Sicherheit überwacht. Die GlassWorm-Kampagne zielte genau auf diesen blinden Fleck: VS-Code-Extensions haben weitreichende Berechtigungen auf dem Hostsystem, werden aber selten wie Software-Installationen behandelt. Microsoft warnte im März 2026 zusätzlich vor KI-Assistenten-Extensions, die Chat-Historien aus Copilot und anderen LLM-Tools stehlen.

KI gegen manuelle Reviews: Wenn Angreifer KI-generierte Cover-Commits einsetzen, reichen manuelle Code-Reviews nicht mehr aus. Die Geschwindigkeit, mit der neue Schadpakete erstellt und verteilt werden, übersteigt die Kapazität menschlicher Analysten. Automatisierte Erkennung auf Basis von Verhaltensanalyse statt reiner Signaturprüfung wird zur Pflicht.

65 %

aller Open-Source-CVEs ohne CVSS-Score vom NVD

Quelle: Sonatype, State of the Software Supply Chain Report 2026

NIS-2 und die Lieferketten-Pflicht

Für Unternehmen in Deutschland ist die Absicherung der Software-Lieferkette nicht mehr optional. NIS-2 fordert in Artikel 21 explizit Sicherheitsmaßnahmen für die Lieferkette. Das BSI hat mit der Technischen Richtlinie TR-03183-2 die SBOM als Pflichtinstrument definiert.

Die Konsequenz: Unternehmen müssen dokumentieren, welche Open-Source-Komponenten in ihren Produkten und internen Tools stecken. Sie müssen Prozesse haben, um bei bekannt gewordenen Schwachstellen in diesen Komponenten schnell reagieren zu können. Und sie müssen Risikobewertungen für ihre kritischen Zulieferer durchführen, einschließlich der Software-Lieferanten.

Der IBM X-Force Threat Intelligence Index 2026 bestätigt die Dringlichkeit: Die Ausnutzung öffentlich zugänglicher Anwendungen stieg um 44 Prozent, größtenteils getrieben durch fehlende Authentifizierungskontrollen und KI-gestützte Schwachstellen-Erkennung durch Angreifer.

Sieben Maßnahmen gegen Supply-Chain-Angriffe

1. Extension-Whitelisting einführen. IDE-Extensions, Browser-Erweiterungen und CLI-Tools dürfen nur aus genehmigten Listen installiert werden. VS-Code bietet dafür die Einstellung „extensions.allowed“ in der Unternehmensrichtlinie.

2. SBOM für alle Produkte und internen Tools erstellen. CycloneDX oder SPDX als Format, automatisiert in der CI/CD-Pipeline generiert. Ohne SBOM kein Überblick über die eigenen Abhängigkeiten.

3. Dependency-Scanning in der CI/CD-Pipeline aktivieren. Tools wie Snyk, Grype oder Dependabot prüfen bei jedem Build automatisch, ob bekannte Schwachstellen in den verwendeten Paketen vorhanden sind.

4. Sigstore-Verifizierung für kritische Pakete einsetzen. Sigstore ermöglicht die kryptografische Signierung und Verifizierung von Software-Artefakten. Manipulierte Pakete ohne gültige Signatur werden automatisch blockiert.

5. Zero Trust für die Entwicklungsumgebung. Entwickler-Workstations brauchen dasselbe Sicherheitsniveau wie Produktionsserver: EDR, Netzwerksegmentierung, privilegierte Zugriffskontrolle. Die Zeiten, in denen Entwickler-Rechner eine Sonderrolle hatten, sind vorbei.

6. NVD-Daten durch kommerzielle Threat Intelligence ergänzen. Angesichts der 65-Prozent-Lücke bei CVSS-Scores sind reine NVD-basierte Scanner unzureichend. Dienste wie Sonatype, Snyk oder Tidelift liefern zeitnähere und vollständigere Daten.

7. Incident-Response-Plan für Supply-Chain-Vorfälle definieren. Wer ist zuständig, wenn eine kompromittierte Bibliothek entdeckt wird? Wie schnell können betroffene Systeme identifiziert und gepatcht werden? Diese Prozesse müssen vor dem Vorfall stehen, nicht danach.

Fazit

Software-Supply-Chain-Angriffe sind 2026 industrialisiert. Die GlassWorm-Kampagne zeigt, wie Angreifer IDE-Extensions, npm-Pakete und GitHub-Repos gleichzeitig kompromittieren, getarnt durch unsichtbare Unicode-Zeichen und KI-generierte Commits. Für IT-Sicherheitsverantwortliche bedeutet das: Die eigene Entwicklungsumgebung ist nicht mehr vertrauenswürdig, solange sie nicht aktiv abgesichert wird. NIS-2 macht das Supply-Chain-Risikomanagement zur Pflicht, das BSI liefert mit der SBOM-Richtlinie das Instrument. Wer jetzt nicht handelt, wird beim nächsten GlassWorm unvorbereitet getroffen.

Häufige Fragen

Was genau ist ein Software-Supply-Chain-Angriff?

Ein Angriff, der nicht das Zielunternehmen direkt trifft, sondern eine Software-Komponente kompromittiert, die das Unternehmen nutzt. Das können Open-Source-Bibliotheken, IDE-Extensions, Build-Tools oder Pakete aus öffentlichen Registries wie npm oder PyPI sein. Der Schadcode wird mit dem nächsten Update oder der nächsten Installation automatisch verteilt.

Wie erkenne ich, ob mein Unternehmen betroffen ist?

Ohne SBOM und Dependency-Scanning ist die ehrliche Antwort: wahrscheinlich gar nicht. Der erste Schritt ist eine Bestandsaufnahme aller verwendeten Open-Source-Komponenten. Tools wie Grype oder Syft können automatisiert SBOMs erstellen und gegen bekannte Schwachstellen-Datenbanken abgleichen.

Schützt eine Web Application Firewall vor Supply-Chain-Angriffen?

Nein. Eine WAF schützt die Anwendung vor externen Angriffen auf Netzwerkebene. Supply-Chain-Angriffe kommen von innen – über kompromittierte Abhängigkeiten, die als vertrauenswürdig gelten. Hier helfen Dependency-Scanning, SBOM-Management und Extension-Whitelisting.

Was fordert NIS-2 konkret für die Software-Lieferkette?

Artikel 21 der NIS-2-Richtlinie fordert Maßnahmen zur Sicherheit der Lieferkette, einschließlich der Beziehungen zu direkten Zulieferern und Dienstleistern. Das BSI konkretisiert das in der TR-03183-2 mit der SBOM-Pflicht. Unternehmen müssen dokumentieren, welche Komponenten sie einsetzen, und Prozesse für die schnelle Reaktion bei Schwachstellen vorweisen.

Wie teuer ist die Absicherung der Software-Lieferkette?

Für KMU mit bestehender CI/CD-Pipeline liegt der Aufwand bei 10.000 bis 30.000 Euro einmalig (Tooling, SBOM-Einführung, Extension-Policies) plus laufende Kosten für kommerzielle Vulnerability-Datenbanken (2.000-10.000 Euro/Jahr). Ohne CI/CD-Pipeline steigen die Kosten auf 40.000 bis 80.000 Euro, weil zunächst die Infrastruktur aufgebaut werden muss.