Drei Angriffswellen, ein Monat, ein gemeinsamer Nenner: die Lieferkette von Open-Source-Software. Zwischen Ende August und dem 9. Oktober 2026 meldeten Sicherheitsfirmen gleich drei getrennte, aber verwandte Supply-Chain-Angriffe, die Entwickler weltweit trafen. GhostAction kaperte GitHub-Workflows und erbeutete tausende Zugangsdaten. Shai-Hulud verbreitete sich als sich selbst replizierender Wurm über npm-Pakete. Und ChainDrop kompromittierte mit dem Tensorlake-SDK ein Paket, das direkt in KI-Infrastruktur läuft. Für Entwicklerteams in Deutschland, Österreich und der Schweiz ist das kein abstraktes Risiko mehr, sondern ein Muster, das sich seit 2025 wiederholt und an Tempo zunimmt.
Dieser Vergleich ordnet die drei Kampagnen nach Technik, Reichweite, Erkennungsgeschwindigkeit und Schutzkosten ein. Er stützt sich auf Berichte von GitGuardian, Socket, StepSecurity und Sonatype sowie auf die neue OWASP-Top-10-Liste von 2025, die Supply-Chain-Angriffe erstmals auf Platz drei der kritischsten Websicherheitsrisiken setzt. Am Ende steht eine klare Priorisierung: Welche Schutzmaßnahme zahlt sich für wen zuerst aus.
Was die drei Fälle verbindet, ist die Verschiebung des Angriffsziels. Früher investierten Angreifer vor allem in das Auffinden von Lücken im eigenen Code eines Unternehmens. Heute reicht es oft, eine einzige Stelle in der Lieferkette zu kompromittieren, einen Maintainer-Account, ein Build-System oder ein weit verbreitetes Paket, um Zugriff auf hunderte oder tausende nachgelagerte Projekte zu erhalten. Das verändert, wie Sicherheitsteams ihre Prioritäten setzen müssen, und es erklärt, warum ausgerechnet dieser Themenbereich 2025 erstmals einen eigenen Spitzenplatz in der OWASP-Rangliste bekam.
Der Zeitpunkt ist kein Zufall. Seit dem 6. Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungsgesetz, das rund 29.000 Unternehmen aus 18 Sektoren verpflichtet, Risiken in ihrer Software-Lieferkette systematisch zu steuern. Wer GhostAction, Shai-Hulud und ChainDrop bislang als reines Entwicklerproblem abgetan hat, bekommt damit auch eine regulatorische Komponente dazu.
GhostAction: Wie gekaperte GitHub-Konten zehntausende Secrets abgriffen
GhostAction ist kein neues Phänomen. Die Kampagne wurde erstmals 2025 dokumentiert und kehrte 2026 in verschärfter Form zurück. Zwischen dem 31. August und dem 30. September 2026 registrierte GitGuardian eine Welle, die 772 öffentliche GitHub-Repositories traf, verteilt auf 373 Nutzerkonten und Organisationen. Die Angreifer zielten dabei auf 2.577 Secrets, also auf API-Schlüssel, Cloud-Zugangsdaten und Deploy-Token, die in CI/CD-Pipelines gespeichert waren.
Bezeichnend für GhostAction ist die Wiederholbarkeit. Statt eines einmaligen Vorfalls handelt es sich um eine Methode, die immer wieder reaktiviert wird, sobald neue verwundbare Konten gefunden werden. Für Entwicklerteams bedeutet das: Ein einmaliges Aufräumen nach einem Vorfall reicht nicht, weil dieselbe Angriffsmethode Monate später erneut auftauchen kann, oft gegen vollständig andere Repositories als beim ersten Mal.
Technik: Ein Workflow, der wie eine Sicherheitsprüfung aussieht
Der Trick ist simpel und genau deshalb wirksam. Die Angreifer übernehmen ein GitHub-Konto mit Schreibrechten auf ein Repository, meist über gestohlene Zugangsdaten oder Phishing, und committen dort eine GitHub-Actions-Workflow-Datei namens security-audit.yml. Der Name suggeriert eine harmlose Routineprüfung. Tatsächlich sammelt der Workflow alle Repository-Secrets ein und schickt sie an attacker-kontrollierte Infrastruktur. Eine Variante vom 8. Oktober 2026 ging noch weiter: Sie durchsuchte den gesamten Git-Verlauf nach Cloud-, KI-, SaaS-, SSH-, Registry- und Datenbank-Zugangsdaten und übertrug die Funde unverschlüsselt per HTTP an eine fest codierte IP-Adresse, wie StepSecurity dokumentierte.
Zeitlinie: Von 772 auf zehntausende Repositories in einer Woche
Am 8. Oktober 2026 identifizierte das Sicherheitsunternehmen Socket einen zusätzlichen, separaten Ausbruch: Zwei kompromittierte Maintainer-Konten, darunter die Accounts henrywoo und kitao, verteilten den bösartigen Workflow binnen Minuten auf 346 weitere Repositories. Nur einen Tag später, am 9. Oktober 2026, meldete Socket laut The Hacker News bereits mehr als 500 betroffene GitHub-Konten und eine Ausbreitung auf zehntausende Repositories seit dem 7. Oktober. Die Zahlen von GitGuardian und Socket beziehen sich auf unterschiedliche Zeitfenster und Teilmengen der Kampagne, zeigen aber denselben Trend: GhostAction wächst schneller, als Verteidiger patchen können.
Shai-Hulud und Shai-Hulud 2.0: Der npm-Wurm, der sich selbst verbreitet
Während GhostAction auf GitHub-Konten abzielt, operiert Shai-Hulud auf einer anderen Ebene der Lieferkette: dem npm-Registry selbst. Der Wurm verbreitet sich über kompromittierte npm-Pakete mit bösartigen Pre- oder Postinstall-Hooks, die beim Installieren automatisch ausgeführt werden. Das macht ihn besonders gefährlich, weil Entwickler die Infektion oft nicht bemerken, bevor der Schaden längst entstanden ist.
Shai-Hulud zielt auf Cloud-Zugangsdaten, GitHub-Secrets, Service-Account-Token, Kryptowährungs-Wallets und im Browser gespeicherte Passwörter. Das Besondere: Der Wurm ist selbstreplizierend. Gestohlene npm- oder Entwicklerzugangsdaten nutzt er automatisch, um weitere Pakete zu kompromittieren oder neue bösartige Versionen unter dem Namen des Opfers zu veröffentlichen. Laut dem aktuellen OWASP-Top-10-Katalog von 2025 erreichte Shai-Hulud dabei mehr als 500 Paketversionen, die mit gestohlenen npm-Token veröffentlicht wurden.
Das Ausmaß wird erst im Kontext klar: Laut dem Bericht State of the Software Supply Chain von Sonatype fügten selbstreplizierende npm-Kampagnen wie Shai-Hulud und seine Varianten im Jahr 2025 binnen wenigen Monaten 171.740 bösartige Pakete allein zum npm-Registry hinzu. Das ist mehr als ein Drittel aller von Sonatype im gesamten Jahr 2025 identifizierten 454.600 neuen Schadpakete über alle Ökosysteme hinweg.
Warum sich der Wurm so schnell verbreitet
Der entscheidende Unterschied zu einem klassischen Einzelpaket-Angriff liegt im Netzwerkeffekt. Sobald der Wurm auf dem Rechner eines Maintainers aktiv ist, sucht er gezielt nach dessen npm-Publish-Token und nutzt diese automatisch, um weitere Pakete zu infizieren, für die derselbe Maintainer Schreibrechte besitzt. Jedes neu infizierte Paket wird dadurch selbst zur Infektionsquelle für die nächste Generation von Betroffenen. Dieser Mechanismus erklärt, warum die Zahl von 171.740 bösartigen Paketen in so kurzer Zeit erreicht wurde: Es handelt sich nicht um 171.740 unabhängige Angriffe, sondern um eine Kettenreaktion, die mit vergleichsweise wenigen initial kompromittierten Konten begann.
ChainDrop und der Tensorlake-Vorfall: Wenn KI-Infrastruktur zur Zielscheibe wird
Der dritte Fall ist konkreter und zeigt, wie die beiden anderen Muster in der Praxis zusammenlaufen. Am 8. Oktober 2026 meldete Socket in einem eigenen Bericht, dass das npm-Paket tensorlake, ein TypeScript-SDK für die KI-Agenten- und Sandbox-Infrastruktur des Anbieters Tensorlake, kompromittiert wurde. Die betroffene Version trug die Nummer 0.5.144. Die Angreifer nutzten einen Preinstall-Hook, um bei der Installation einen verschleierten Loader zu starten, der wiederum den Shai-Hulud-Wurm im Rahmen einer sogenannten ChainDrop-Operation nachlud.
Die Payload zielte auf Cloud-Zugangsschlüssel, GitHub-Actions-Secrets, Service-Account-Token, Krypto-Wallet-Daten und gespeicherte Browser-Passwörter, exakt das Beuteschema, das auch bei der breiteren Shai-Hulud-Familie beobachtet wurde. Bemerkenswert ist die Reaktionszeit: Laut einem Sekundärbericht wurde die bösartige Version rund elf Minuten nach der Veröffentlichung von Sicherheits-Tooling markiert. Das ist deutlich schneller als bei GhostAction, wo Angreifer teils Wochen unentdeckt blieben, zeigt aber auch, wie knapp das Zeitfenster für Downstream-Nutzer ist, die ein Paket automatisiert über CI/CD-Pipelines beziehen.
Der Tensorlake-Vorfall steht nicht allein. Sicherheitsforscher von OX Security analysierten im Oktober 2026 nach einem Bericht zur IT-Bedrohungslage mehr als 15.000 öffentlich indexierte Model-Context-Protocol-Server und fanden dabei grundlegende Sicherheitslücken in der KI-Lieferkette. Das deckt sich mit dem Muster bei ChainDrop: Je schneller sich KI-Infrastruktur verbreitet, desto größer wird die Angriffsfläche, bevor etablierte Sicherheitsstandards nachziehen können.
Tensorlake ist damit kein Einzelfall, sondern ein Symptom: KI-Startups und ihre SDKs werden zunehmend zum Ziel, weil sie oft schneller wachsen, als ihre Sicherheitsprozesse reifen können. Ein KI-Agenten-SDK bringt in der Regel weitreichendere Berechtigungen mit als ein klassisches Utility-Paket: Es braucht Zugriff auf Cloud-Rechenleistung, API-Schlüssel für Modell-Endpunkte und oft auch auf Kundendaten, die durch die Agenten-Pipeline fließen. Genau dieses breitere Berechtigungsprofil macht kompromittierte KI-Infrastruktur-Pakete für Angreifer so attraktiv, denn ein einziger erfolgreicher Einbruch liefert potenziell mehr verwertbare Zugangsdaten als zehn kompromittierte Nischenbibliotheken zusammen.
Wie Angreifer heute typischerweise an den ersten Zugang kommen
Alle drei Kampagnen brauchen einen Startpunkt, bevor Workflows injiziert oder Pakete ausgetauscht werden können. In der Praxis wiederholen sich dabei immer dieselben drei Einstiegspunkte, unabhängig davon, ob am Ende GhostAction, Shai-Hulud oder eine noch unbenannte Variante steht.
Erstens: wiederverwendete oder durch Phishing erbeutete Zugangsdaten. Maintainer, die dasselbe Passwort für GitHub, npm und private E-Mail-Konten nutzen, bieten Angreifern den einfachsten Weg hinein, besonders wenn kein Hardware-Zweitfaktor erzwungen wird. Zweitens: gestohlene oder ausgelaufene Zugangstoken, die versehentlich in öffentlichen Repositories, CI-Logs oder alten Commits landen und dort von automatisierten Scannern der Angreifer gefunden werden, oft innerhalb von Minuten nach der Veröffentlichung. Drittens: Social Engineering gegenüber einzelnen Maintainern, etwa über gefälschte Jobangebote, vermeintliche Sicherheitsmeldungen oder manipulierte Pull-Requests, die im Erfolgsfall direkt Schreibrechte auf das Zielrepository verschaffen. Die beiden kompromittierten Konten hinter der GhostAction-Welle vom 8. Oktober 2026, henrywoo und kitao, passen in dieses Muster: Beide waren etablierte, vertrauenswürdige Maintainer-Identitäten, keine frisch angelegten Fake-Accounts.
Diese drei Einstiegspunkte erklären auch, warum rein technische Lösungen allein selten ausreichen. Ein Scanner, der erst nach dem Commit ansetzt, kommt zu spät, wenn der eigentliche Fehler schon beim Zugang zum Konto passiert ist. Wirksamer Schutz muss deshalb an der Identität ansetzen, bevor überhaupt ein Workflow oder ein Paket verändert werden kann, und erst danach technische Kontrollen wie Secret-Scanning als zweite Verteidigungslinie ergänzen.
Die drei Kampagnen im direkten Vergleich
Die folgende Tabelle fasst die technischen Eckdaten aller drei Kampagnen zusammen. Sie zeigt, dass es sich trotz ähnlicher Beuteziele um strukturell unterschiedliche Angriffe handelt, die unterschiedliche Verteidigungsmaßnahmen erfordern.
| Merkmal | GhostAction | Shai-Hulud / 2.0 | ChainDrop (Tensorlake) |
|---|---|---|---|
| Ziel-Plattform | GitHub Actions / CI-CD | npm-Registry | npm-Registry (KI-SDK) |
| Erstmals dokumentiert | 2025, Welle 2026 | 2025 | Oktober 2026 |
| Entdeckt von | GitGuardian, Socket, StepSecurity | Mehrere Firmen, OWASP erfasst | Socket |
| Angriffsvektor | Gekaperte Maintainer-Konten | Kompromittierte Pakete / Hooks | Preinstall-Hook in SDK-Release |
| Ausbreitungsmechanismus | Manuelles Nachladen pro Repo | Selbstreplizierend | Teil der Shai-Hulud-Familie |
| Betroffene Einheiten (Hauptwelle) | 772 Repos, 373 Konten | 171.740 Pakete (Monate) | 1 SDK, Version 0.5.144 |
| Zusatzwelle Oktober 2026 | 500+ Konten, zehntausende Repos | 500+ Paketversionen (OWASP) | Teil der Oktober-Welle |
| Payload-Fokus | CI/CD-Secrets, Git-History-Scan | Cloud-, Wallet-, Browser-Daten | Cloud-, GitHub-, Wallet-Daten |
| Exfiltrationskanal | Fest codierte IP, Klartext-HTTP | Attacker-Infrastruktur, variabel | Nachgeladener Loader |
| Erkennungsgeschwindigkeit | Teils Wochen | Variiert je Welle | Rund 11 Minuten (Einzelfall) |
| Status Oktober 2026 | Aktiv | Aktiv, mehrere Varianten | Paketversion entfernt |
Die Tabelle macht einen Punkt deutlich, der in der öffentlichen Berichterstattung oft untergeht: GhostAction und Shai-Hulud sind keine konkurrierenden Namen für dasselbe Problem, sondern zwei Angriffe auf unterschiedlichen Ebenen desselben Software-Lebenszyklus. GhostAction greift dort an, wo Code gebaut und ausgeliefert wird, Shai-Hulud dort, wo Code als Abhängigkeit konsumiert wird. ChainDrop zeigt, wie beide Ebenen in einem konkreten Vorfall zusammenfallen können, sobald ein kompromittiertes Paket selbst wieder zum Werkzeug für die nächste Infektion wird.
Erkennungsgeschwindigkeit im Vergleich: Was die Berichte wirklich zeigen
Ein Vergleich dieser Art braucht belastbare Zahlen aus mehreren unabhängigen Quellen, nicht nur aus einem einzigen Blogpost. GitGuardian, Socket, StepSecurity und Sonatype liefern dafür vier Datenpunkte, die sich ergänzen, aber nicht einfach addieren lassen, weil sie unterschiedliche Zeitfenster und Zählmethoden verwenden. Für Sicherheitsteams, die ihre eigene Erkennungsgeschwindigkeit einordnen wollen, bietet diese Übersicht trotzdem einen brauchbaren Außenmaßstab: Wer bei einem ähnlichen Vorfall deutlich langsamer reagiert als die im Folgenden genannten Werte, hat vermutlich eine Lücke im eigenen Monitoring.
| Quelle | Kennzahl | Wert | Zeitraum |
|---|---|---|---|
| GitGuardian | Betroffene Repositories (GhostAction) | 772 | 31. Aug. – 30. Sep. 2026 |
| GitGuardian | Betroffene Secrets | 2.577 | 31. Aug. – 30. Sep. 2026 |
| Socket / StepSecurity | Zusatzwelle Repositories | 346 | 8. Okt. 2026 |
| Socket (laut The Hacker News) | Betroffene GitHub-Konten | 500+ | Seit 7. Okt. 2026 |
| Sonatype | Neue Schadpakete gesamt 2025 | 454.600+ | Kalenderjahr 2025 |
| Sonatype | Davon durch npm-Wurmkampagnen | 171.740 | Mehrere Monate 2025 |
| Sonatype | Zuwachs ggü. Vorjahr | ca. 75 % | 2024 auf 2025 |
| OWASP Top 10:2025 | Rang Supply-Chain-Kategorie (A03) | Platz 3 von 10 | Veröffentlicht 2025 |
Bemerkenswert ist, dass die neue OWASP-Top-10-Liste die Kategorie Software Supply Chain Failures erstmals als eigenständigen Punkt A03 führt und sie damit von einem Unterpunkt der alten Liste (dort noch unter Vulnerable and Outdated Components) auf Platz drei hochstuft. In der begleitenden Community-Umfrage stuften 50 Prozent der Befragten diese Kategorie sogar als ihr persönliches Risiko Nummer eins ein, ein stärkeres Signal als jede Einzelstatistik.
Für Sicherheitsteams, die ihre Prioritäten an der OWASP-Liste ausrichten, bedeutet das einen klaren Auftrag: Code-Reviews und klassische Schwachstellen-Scans allein reichen nicht mehr aus. Die Kategorie A03 deckt explizit Kompromittierungen von Abhängigkeiten, Build-Systemen und Verteilungsinfrastruktur ab, also genau die drei Ebenen, auf denen GhostAction, Shai-Hulud und ChainDrop jeweils ansetzen. Wer sein Sicherheitsbudget noch nach der alten Rangliste von 2021 verteilt, arbeitet faktisch mit einer veralteten Bedrohungslandkarte.
Reale Vorfälle: Sieben Beispiele aus den Kampagnen 2026
Abstrakte Kampagnennamen werden erst greifbar, wenn man die konkreten Opfer kennt. Diese sieben dokumentierten Fälle zeigen die Bandbreite der Angriffe im Herbst 2026, von Konzern-Repositories über populäre Hobby-Projekte bis zu spezialisierter KI-Infrastruktur.
- uber/athenadriver: Das öffentliche Repository des Uber-Projekts athenadriver gehörte zu den 346 Repositories, die in der GhostAction-Welle vom 8. Oktober 2026 kompromittiert wurden.
- kitao/pyxel: Die beliebte Spiele-Engine pyxel mit rund 18.420 GitHub-Sternen war ebenfalls betroffen, nachdem das Maintainer-Konto kitao übernommen wurde.
- Kompromittiertes Konto henrywoo: Eines von zwei hochrangigen Open-Source-Maintainer-Konten, die Angreifer nutzten, um den bösartigen Workflow in Dutzende weitere Repositories zu committen.
- [email protected]: Die kompromittierte npm-Paketversion des Tensorlake-SDKs, die über einen Preinstall-Hook den Shai-Hulud-Loader nachlud.
- 373 Konten in der GhostAction-Hauptwelle: GitGuardian dokumentierte, dass die Angriffe nicht isolierte Einzelfälle waren, sondern über hunderte unabhängige Entwickler-Accounts verteilt liefen.
- Ein in DevOpsGPT versteckter Cryptominer: GitGuardian fand im Rahmen der GhostAction-Recherche einen zusätzlichen, separat eingeschleusten Cryptominer in einem verwandten Projekt, ein Hinweis darauf, dass kompromittierte CI/CD-Pipelines mehrfach monetarisiert werden.
- Über 500 bösartige npm-Paketversionen: Laut OWASP erreichte allein die Shai-Hulud-Linie diese Marke an eigenständig veröffentlichten Schadversionen, verbreitet über gestohlene npm-Publish-Token.
- Elf Minuten Reaktionsfenster bei Tensorlake: Die kurze Zeitspanne zwischen Veröffentlichung und Erkennung der kompromittierten Version 0.5.144 zeigt, dass selbst gut überwachte Registries nicht verhindern können, dass ein Paket zumindest kurz produktiv in Downstream-Projekten landet.
- 346 Repositories in einer einzigen Oktoberwelle: Socket dokumentierte, dass die Angreifer am 8. Oktober 2026 binnen Minuten in zwei automatisierten Durchläufen hunderte Projekte erreichten, ein Tempo, das manuelle Reaktionsprozesse bei den betroffenen Maintainern kaum einholen können.
Gemeinsam ist allen sieben Fällen, dass die Opfer nicht durch eigene Nachlässigkeit bei der Code-Qualität betroffen waren, sondern durch Vertrauen in fremde Infrastruktur, Konten und Pakete, die sie selbst nicht vollständig kontrollieren konnten. Das ist der Kern des Problems, das die neue OWASP-Kategorie A03 beschreibt: Sicherheit lässt sich nicht mehr allein am eigenen Quellcode festmachen, sondern muss die gesamte Kette der Abhängigkeiten einschließen, von der ersten Zeile importiertem Fremdcode bis zur letzten Build-Stufe vor der Veröffentlichung.
Wer ist am stärksten betroffen? Fünf Einsatzszenarien und Empfehlungen
Nicht jedes Team braucht dieselbe Priorität. Die folgenden fünf Szenarien ordnen die Risiken nach Zielgruppe ein und nennen jeweils die naheliegendste erste Maßnahme.
- Open-Source-Maintainer mit Schreibrechten auf viele Repos: Höchstes Risiko für GhostAction-ähnliche Kontoübernahmen. Erste Maßnahme: Hardware-Token-basierte Zwei-Faktor-Authentifizierung für GitHub und npm erzwingen, ohne Ausnahmen.
- Teams mit intensiver npm-Nutzung in Produktions-Builds: Höchstes Risiko für Shai-Hulud-Infektionen über automatische Installationen. Erste Maßnahme: Lockfiles strikt pinnen und Install-Skripte in CI-Umgebungen standardmäßig deaktivieren.
- KI-Infrastruktur- und SDK-Anbieter wie Tensorlake: Höchstes Risiko für ChainDrop-artige Downstream-Angriffe auf Kunden. Erste Maßnahme: Signierte Releases mit Provenienz-Nachweisen nach dem npm-Provenance-Standard veröffentlichen.
- Unternehmen mit eigenen GitHub-Actions-Workflows: Höchstes Risiko für Secret-Diebstahl über injizierte Workflow-Dateien. Erste Maßnahme: Von langlebigen Secrets auf kurzlebige OIDC-Token umstellen und Workflow-Änderungen per Pull-Request-Pflicht absichern.
- Security- und SOC-Teams in mittelständischen Unternehmen: Höchstes Risiko ist verzögerte Erkennung, weil klassische Endpoint-Tools CI/CD-Pipelines oft nicht abdecken. Erste Maßnahme: Egress-Traffic aus Build-Umgebungen überwachen und ungewöhnliche Ziel-IPs blockieren.
Diese Einordnung ersetzt keine individuelle Risikoanalyse, sie zeigt aber, dass die Reihenfolge der Maßnahmen von der eigenen Rolle in der Lieferkette abhängt. Ein Unternehmen, das selbst keine Pakete veröffentlicht, aber tausende Abhängigkeiten konsumiert, braucht andere Prioritäten als ein Anbieter, dessen SDK direkt bei Kunden installiert wird. Wer unsicher ist, wo das eigene Unternehmen in dieser Kette steht, sollte mit einer einfachen Übung beginnen: alle ausgehenden Vertrauensbeziehungen auflisten, von genutzten Open-Source-Paketen bis zu eigenen veröffentlichten Artefakten, und erst danach Budget priorisieren.
Gerade für die rund 29.000 Unternehmen, die seit Dezember 2025 unter das deutsche NIS-2-Umsetzungsgesetz fallen, viele davon mittelständisch und ohne große dedizierte Sicherheitsabteilung, ist diese Priorisierung keine akademische Übung, sondern eine Budgetfrage mit Fristen. Wer die fünf Szenarien oben durchgeht und sich selbst klar zuordnet, kann die Investition in Secret-Scanning, OIDC-Token oder Provenienz-Attestierung gezielt dort ansetzen, wo der eigene Beitrag zum Gesamtrisiko am größten ist, statt das verfügbare Budget gleichmäßig und damit wenig wirksam zu verteilen.
Schutz-Tools im Preisvergleich: Was kostet Supply-Chain-Sicherheit wirklich?
Vier Werkzeuge taugen für die akute Verteidigung gegen Angriffe wie GhostAction, Shai-Hulud und ChainDrop: GitHub Advanced Security für die CI/CD-Ebene, Snyk und Socket.dev für die Paketebene sowie JFrog Xray für Unternehmen mit eigener Artefakt-Infrastruktur. Die folgenden Preisangaben sind Richtwerte aus veröffentlichten Markt- und Vertragsdaten, keine garantierten Listenpreise, da Hersteller zunehmend auf individuelle Verträge setzen, die sich nach Teamgröße, Anzahl der Repositories und gewählten Zusatzmodulen richten. Für ein belastbares Angebot bleibt daher in jedem Fall eine direkte Anfrage beim Hersteller nötig.
| Tool | Einsatzebene | Typisches Preismodell | Kostenrichtwert |
|---|---|---|---|
| GitHub Advanced Security | CI/CD, Secret-Scanning | Pro aktivem Committer / Monat | Historisch rund 49 $ pro Committer |
| Snyk | Paket- und Code-Scanning | Kostenloses Einzeltier, dann pro Entwickler | Team: niedrige zweistellige $-Beträge/Monat, Enterprise: 5- bis 6-stellig/Jahr |
| Socket.dev | npm-Paket-Risikoanalyse | Pro Entwickler / Monat | Niedrige zweistellige $-Beträge/Monat, Enterprise auf Anfrage |
| JFrog Xray | Artefakt-Repository-Scanning | Teil der JFrog-Plattform | 5- bis 6-stellig/Jahr je nach Volumen |
Wichtig für die Einordnung: Keines dieser Tools hätte den initialen Diebstahl eines Maintainer-Kontos verhindert. Sie verkürzen aber die Zeit bis zur Erkennung erheblich, wie der Tensorlake-Fall mit einer Reaktionszeit von rund elf Minuten zeigt. Das ist der entscheidende Hebel, denn je kürzer das Zeitfenster, desto weniger Downstream-Projekte laden die kompromittierte Version überhaupt herunter.
Die Investition relativiert sich außerdem, wenn man sie gegen das Wachstum des Problems stellt. Sonatype beobachtete für 2025 einen Zuwachs neuer Schadpakete von rund 75 Prozent gegenüber dem Vorjahr. Ein Lizenzpreis im niedrigen zweistelligen Dollarbereich pro Entwickler und Monat wirkt angesichts dieser Wachstumsrate weniger wie eine Zusatzausgabe und mehr wie eine Versicherungsprämie gegen ein Risiko, das sich nachweislich nicht von selbst verlangsamt.
Migrationsleitfaden: In neun Schritten zu einer gehärteten Lieferkette
Wer heute noch mit langlebigen Secrets, ungepinnten Dependencies und offenen Maintainer-Rechten arbeitet, sollte die Migration nicht aufschieben. Der folgende Ablauf eignet sich für Teams, die von einem ungehärteten auf ein nach aktuellem Stand abgesichertes CI/CD- und Dependency-Setup wechseln wollen. Er orientiert sich an den Angriffsmustern, die GhostAction, Shai-Hulud und ChainDrop tatsächlich genutzt haben, nicht an einer generischen Checkliste.
- Bestandsaufnahme aller aktiven GitHub-Actions-Workflows und ihrer Berechtigungen erstellen, inklusive Workflows, die seit Monaten nicht mehr geprüft wurden.
- Hardware-basierte Zwei-Faktor-Authentifizierung für alle Konten mit Schreibzugriff auf Repositories und npm-Publish-Rechte verpflichtend einführen.
- Langlebige API-Schlüssel und Cloud-Zugangsdaten in Workflows durch kurzlebige OIDC-Token ersetzen, wie in der GitHub-Dokumentation zur Workflow-Härtung beschrieben.
- Alle Dependency-Installationen in CI-Umgebungen auf feste Lockfile-Versionen umstellen und automatische Install-Skripte, wo möglich, deaktivieren.
- Ein Secret-Scanning-Tool wie GitHub Advanced Security oder GitGuardian in jede Pull-Request-Pipeline einbinden, nicht nur in den Hauptzweig.
- Für eigene npm-Veröffentlichungen Provenienz-Attestierungen aktivieren, wie in der npm-Dokumentation zu Provenance-Statements erläutert.
- Egress-Filterregeln für Build-Runner einrichten, damit unbekannte Ziel-IPs und Klartext-HTTP-Verbindungen aus der Pipeline blockiert werden.
- Ein Incident-Response-Playbook speziell für kompromittierte Maintainer-Konten und Paketregistries erstellen und mindestens einmal jährlich testen.
- Nach jeder Migrationsphase einen externen Audit gegen ein anerkanntes Framework wie SLSA durchführen, um den tatsächlichen Härtungsgrad zu messen statt ihn nur anzunehmen.
In der Praxis verteilen die meisten Teams diese neun Schritte auf zwei bis drei Phasen über mehrere Monate, statt alles gleichzeitig umzusetzen. Das verhindert, dass Build-Pipelines durch zu viele parallele Änderungen unkontrolliert ausfallen, und schafft zugleich Nachweise, die im Rahmen der NIS2-Meldepflichten gegenüber Aufsichtsbehörden oder der eigenen Geschäftsleitung dokumentiert werden können. Eine sinnvolle erste Phase umfasst meist die Schritte eins bis vier, weil sie die größten Lücken bei vergleichsweise geringem Umbauaufwand schließen, während die Schritte zu Egress-Filterung und externem SLSA-Audit oft erst in einer zweiten oder dritten Phase folgen, sobald die Grundlagen stehen.
Vor- und Nachteile der wichtigsten Schutzmaßnahmen
Keine einzelne Maßnahme deckt alle drei Kampagnentypen ab. Die folgende Übersicht zeigt, wo jede Maßnahme stark ist und wo Lücken bleiben. Wer nur eine davon umsetzt und die anderen aufschiebt, verschiebt das Risiko lediglich auf den nächsten Angriffsvektor, statt es tatsächlich zu senken.
| Maßnahme | Vorteil | Nachteil |
|---|---|---|
| Kurzlebige OIDC-Token statt Secrets | Entwertet gestohlene Zugangsdaten binnen Minuten | Erfordert Umbau bestehender Pipelines |
| Lockfile-Pinning und Install-Skripte deaktivieren | Blockiert einen Großteil der Wurm-Ausbreitung | Kann Build-Prozesse verlangsamen oder brechen |
| Erzwungene Hardware-2FA | Verhindert die häufigste Ursache für Kontoübernahmen | Zusätzlicher Verwaltungsaufwand für Maintainer-Teams |
| Secret-Scanning in jeder Pull-Request-Pipeline | Erkennt Leaks vor dem Merge, nicht erst danach | Erzeugt bei schlechter Konfiguration viele Fehlalarme |
| Provenienz-Attestierung für eigene Pakete | Macht Downstream-Nutzern Manipulationen sichtbar | Schützt nicht vor Kompromittierung der eigenen Quelle |
| Egress-Filterung in Build-Runnern | Stoppt Exfiltration selbst nach erfolgreichem Einbruch | Benötigt laufende Pflege der Allow-Listen |
In der Summe ergibt sich ein Bild, das sich mit keiner Einzelmaßnahme auflösen lässt: Jede Zeile der Tabelle schließt eine Lücke, die eine andere Maßnahme offen lässt. Erst die Kombination aus identitätsbasiertem Schutz, gehärteten Build-Prozessen und laufender Überwachung bildet ein Verteidigungsnetz, das auch eine bislang unbekannte Variante der nächsten Kampagne auffangen kann.
Historischer Vergleich: Von SolarWinds über xz-utils bis zur heutigen Angriffswelle
GhostAction, Shai-Hulud und ChainDrop wirken neu, folgen aber einer Entwicklung, die sich seit Jahren abzeichnet. Zwei frühere Vorfälle zeigen, wie sich die Angriffsform seitdem verändert hat: von einem einzelnen, hochprofessionellen Implantat zu einer automatisierten, massenhaft wiederholbaren Technik.
Der SolarWinds-Angriff von 2020 gilt bis heute als Referenzfall für staatlich zugeordnete Supply-Chain-Operationen. Angreifer manipulierten die Build-Pipeline der Orion-Netzwerkmanagement-Software so, dass eine signierte, offiziell verteilte Updatedatei eine Hintertür enthielt. Nach der konventionell zitierten Zahl luden rund 18.000 Organisationen das kompromittierte Update herunter, wobei die Angreifer nur eine deutlich kleinere Zahl tatsächlich gezielt weiter kompromittierten. Der Aufwand war enorm, die Kampagne blieb über Monate unentdeckt, und sie traf vor allem hochrangige Regierungs- und Unternehmensziele.
Der xz-utils-Vorfall von 2024 zeigt die Gegenrichtung: Im März 2024 bemerkte der Microsoft-Ingenieur Andres Freund ungewöhnliche Verzögerungen bei SSH-Logins auf einem System, während er eigentlich ein Performance-Problem untersuchte. Diese Beobachtung führte zur Entdeckung einer Hintertür in den xz-utils-Bibliotheksversionen 5.6.0 und 5.6.1, katalogisiert als CVE-2024-3094 mit dem höchsten CVSS-Wert von 10.0. Der Code war über Jahre hinweg von einem Angreifer eingeschleust worden, der sich schrittweise das Vertrauen der Maintainer-Community erarbeitet hatte. Die Hintertür wurde entdeckt, bevor sie breite Produktionsumgebungen über stabile Linux-Distributionen erreichte, vor allem durch Zufall und die Aufmerksamkeit eines einzelnen Entwicklers.
Beide Fälle zusammen zeigen, wie viel Zufall und individuelles Engagement früher nötig waren, um einen Supply-Chain-Angriff aufzudecken. Weder ein automatisierter Scanner noch ein Standardprozess deckte die xz-utils-Hintertür auf, sondern die Neugier eines einzelnen Ingenieurs bei einer eigentlich unabhängigen Fehlersuche. Diese Abhängigkeit von Zufallsfunden ist genau das Risiko, das moderne Sicherheits-Tooling heute systematisch ersetzen soll.
GhostAction, Shai-Hulud und ChainDrop markieren eine dritte Phase. Statt eines einzelnen, über Jahre vorbereiteten Implantats wie bei xz-utils oder einer einzelnen hochkomplexen Operation wie bei SolarWinds, laufen diese Kampagnen automatisiert, wiederholbar und in hoher Frequenz. Ein kompromittiertes Konto reicht, um binnen Minuten hunderte Repositories zu treffen, und ein einziger bösartiger Preinstall-Hook reicht, um einen sich selbst replizierenden Wurm in Gang zu setzen. Die Angreifer brauchen keine jahrelange Tarnung mehr, sie brauchen Automatisierung und Tempo.
Diese Verschiebung hat eine direkte Konsequenz für die Verteidigung. Gegen einen SolarWinds- oder xz-utils-artigen Angriff hilft vor allem geduldige, tiefgehende Code-Prüfung über lange Zeiträume. Gegen GhostAction, Shai-Hulud und ChainDrop hilft das kaum, weil die Angreifer gar nicht versuchen, sich über Jahre unentdeckt einzunisten. Stattdessen zählt Geschwindigkeit der Erkennung in Minuten und Stunden, nicht in Monaten, und genau das verschiebt den Fokus von aufwendigen Einzel-Audits zu kontinuierlichem, automatisiertem Monitoring jeder einzelnen Pipeline.
Rechtlicher Rahmen: Was NIS2 und das BSI von Unternehmen in Deutschland verlangen
Für Unternehmen in Deutschland ist der Umgang mit Supply-Chain-Risiken längst keine freiwillige Best Practice mehr. Artikel 21 der EU-Richtlinie NIS2 verpflichtet wesentliche und wichtige Einrichtungen ausdrücklich dazu, Maßnahmen zur Sicherheit der Lieferkette umzusetzen, einschließlich sicherheitsrelevanter Aspekte der Beziehungen zu unmittelbaren Lieferanten und Diensteanbietern. Artikel 21 Absatz 3 verlangt zusätzlich, dass Unternehmen lieferantenspezifische Schwachstellen sowie die Sicherheitspraktiken und Entwicklungsverfahren ihrer Zulieferer berücksichtigen.
In Deutschland ist diese Pflicht seit dem 6. Dezember 2025 unmittelbar relevant: An diesem Tag trat das NIS-2-Umsetzungsgesetz in Kraft, nachdem es am 13. November 2025 den Bundestag passiert hatte. Das Gesetz erfasst nach Berichten rund 29.000 Unternehmen aus 18 Sektoren, die ihre Cyberrisiken systematisch steuern, Sicherheitsvorfälle innerhalb enger Fristen melden und ihre Geschäftsleitung unmittelbar einbinden müssen. Genau in diese Meldepflicht fallen Vorfälle wie eine kompromittierte CI/CD-Pipeline oder ein infiziertes npm-Paket in der eigenen Produktions-Lieferkette.
Das Bundesamt für Sicherheit in der Informationstechnik stuft die allgemeine IT-Sicherheitslage in seinem Bericht Die Lage der IT-Sicherheit in Deutschland 2025 vom 11. November 2025 als dauerhaft angespannt ein. Für Sicherheitsverantwortliche in deutschen Unternehmen ergibt sich daraus ein doppelter Druck: technisch, weil Kampagnen wie GhostAction und Shai-Hulud nachweislich aktiv sind, und regulatorisch, weil NIS2 Lieferketten-Sicherheit nicht mehr als Kür, sondern als Pflicht behandelt.
Für die praktische Umsetzung bedeutet das, Lieferketten-Sicherheit nicht länger isoliert im Entwicklerteam zu behandeln, sondern als Teil des unternehmensweiten Risikomanagements, das NIS2 verlangt. Dazu zählt, Verträge mit Software-Lieferanten um Sicherheitsklauseln zu ergänzen, ein Inventar aller kritischen Abhängigkeiten zu führen und Meldewege für Vorfälle wie einen kompromittierten Dependency-Baum vorab festzulegen, statt sie erst im akuten Vorfall zu improvisieren. Unternehmen, die bereits ein Informationssicherheits-Managementsystem nach ISO 27001 betreiben, können diese Anforderungen meist in bestehende Prozesse integrieren, statt komplett neue Strukturen aufzubauen.
Einordnung: Warum OWASP Supply-Chain-Angriffe jetzt auf Platz drei setzt
Die OWASP Top 10 ist die am häufigsten zitierte Referenz für Websicherheitsrisiken, und ihre Ausgabe 2025 markiert einen klaren Bruch mit der Vergangenheit. Bis 2021 liefen Lieferketten-Probleme unter dem allgemeinen Punkt Vulnerable and Outdated Components, eher ein Nebenschauplatz. 2025 bekommt die Kategorie einen eigenen Platz als A03, Software Supply Chain Failures, und landet direkt auf Rang drei von zehn. Parallel bleibt die verwandte Kategorie A08, Software or Data Integrity Failures, auf Platz acht bestehen.
Diese Neueinstufung ist kein bürokratisches Update. Sie spiegelt direkt die Art von Vorfällen wider, die GhostAction, Shai-Hulud und ChainDrop liefern: Kompromittierungen entstehen nicht mehr primär durch Code-Schwachstellen im eigenen Produkt, sondern durch Vertrauen in Drittkomponenten, Build-Systeme und Verteilungsinfrastruktur. Sonatypes Zahl von über 1,233 Millionen kumulierten Schadpaketen seit Beginn der Erfassung unterstreicht, dass dieses Vertrauen in großem Stil ausgenutzt wird.
Das Urteil: Welche Kampagne ist am gefährlichsten, und was zuerst absichern?
Gemessen an der reinen Opferzahl liegt Shai-Hulud vorn: 171.740 bösartige Pakete allein durch Wurm-Kampagnen in wenigen Monaten übertreffen die 772 bis zehntausende Repositories von GhostAction deutlich. Gemessen an der potenziellen Schadenstiefe pro Vorfall liegt dagegen ChainDrop vorn, weil ein einziges kompromittiertes SDK wie tensorlake direkt in produktive KI-Infrastruktur bei Kunden läuft und dort weit mehr Berechtigungen mitbringt als ein durchschnittliches npm-Paket.
Für die Praxis heißt das: Teams ohne jede Härtung sollten zuerst bei GhostAction ansetzen, weil die Gegenmaßnahme, erzwungene Hardware-2FA plus OIDC-Token, am schnellsten umsetzbar ist und bereits den größten Teil der Angriffsfläche schließt. Teams mit starker npm-Abhängigkeit müssen parallel Lockfile-Pinning und deaktivierte Install-Skripte priorisieren, um Shai-Hulud-Varianten die automatische Ausführung zu entziehen. SDK-Anbieter wie Konkurrenten von Tensorlake oder vergleichbare KI-Infrastrukturfirmen kommen an Provenienz-Attestierung nicht mehr vorbei, denn ihre Kunden können eine Kompromittierung sonst erst erkennen, wenn der Schaden bereits downstream entstanden ist. Keine dieser drei Kampagnen lässt sich mit einer einzigen Maßnahme abwehren, aber die Kombination aus kurzlebigen Token, gepinnten Dependencies und Provenienz-Nachweisen deckt nach aktuellem Kenntnisstand den größten Teil aller drei Angriffspfade ab.
Langfristig verschiebt sich der Maßstab weiter in Richtung Automatisierung auf beiden Seiten. Verteidiger, die Secret-Scanning, Egress-Filterung und Provenienz-Prüfung manuell und punktuell betreiben, werden gegen selbstreplizierende Kampagnen wie Shai-Hulud strukturell unterlegen bleiben. Nur wenn Schutzmaßnahmen genauso automatisiert und in jede Pull-Request-Pipeline eingebaut sind, wie die Angriffe selbst ablaufen, sinkt das Risiko auf ein Niveau, das sich mit vertretbarem Aufwand dauerhaft halten lässt. Die rechtliche Flankierung durch NIS2 verschafft genau dieser Automatisierung jetzt auch in Deutschland den nötigen Rückhalt im Budget-Gespräch.
Häufig gestellte Fragen zu GhostAction, Shai-Hulud und ChainDrop
Was unterscheidet GhostAction von einem klassischen Phishing-Angriff?
GhostAction nutzt zwar oft gestohlene Zugangsdaten als Einstieg, geht aber darüber hinaus: Der eigentliche Schaden entsteht erst durch die eingeschleuste GitHub-Actions-Workflow-Datei, die automatisiert und dauerhaft Secrets abgreift, bis sie entdeckt wird. Ein klassischer Phishing-Angriff endet meist mit dem einmaligen Diebstahl eines Passworts, GhostAction baut sich dagegen eine wiederholt nutzbare Hintertür in die Build-Infrastruktur selbst.
Ist Shai-Hulud 2.0 eine neue Schadsoftware oder eine Weiterentwicklung?
Nach aktuellem Berichtsstand handelt es sich um eine Weiterentwicklung derselben Wurm-Familie, die ihre Verbreitungs- und Diebstahlmechanismen über mehrere Wellen seit 2025 verfeinert hat, unter anderem durch den Einsatz in der ChainDrop-Operation gegen Tensorlake.
Reicht ein Antivirenprogramm auf dem Entwicklerrechner als Schutz?
Nein. Alle drei Kampagnen setzen auf CI/CD-Pipelines und automatisierte Build-Umgebungen, die von klassischer Endpoint-Software in der Regel nicht abgedeckt werden. Secret-Scanning und Egress-Filterung auf Pipeline-Ebene sind wirksamer, weil sie genau an der Stelle ansetzen, an der die Angriffe tatsächlich ausgeführt werden, nicht am Arbeitsplatzrechner des einzelnen Entwicklers.
Wie schnell lassen sich kompromittierte npm-Pakete erkennen?
Das variiert stark. Im Tensorlake-Fall markierte Sicherheits-Tooling die bösartige Version laut Sekundärbericht nach rund elf Minuten, während andere GhostAction-Wellen laut GitGuardian teils Wochen unentdeckt blieben, bevor sie öffentlich gemeldet wurden.
Betreffen diese Angriffe auch private oder kleine Open-Source-Projekte?
Ja. GhostAction traf laut GitGuardian 373 unterschiedliche Konten und Organisationen, von Einzelentwicklern bis zu Projekten mit tausenden Nutzern wie pyxel. Projektgröße ist kein verlässlicher Schutzfaktor.
Welche Rolle spielt die neue OWASP-Top-10-Liste für Unternehmen in Deutschland?
Die Einstufung von Supply-Chain-Angriffen auf Platz drei liefert Sicherheitsteams eine anerkannte Referenz, um Budget für Maßnahmen wie Secret-Scanning oder Provenienz-Attestierung gegenüber der Geschäftsführung zu begründen.
Was kostet die Umsetzung der empfohlenen Schutzmaßnahmen ungefähr?
Je nach Teamgröße und gewähltem Tool bewegen sich die Kosten zwischen einem niedrigen zweistelligen Dollarbetrag pro Entwickler und Monat für Tools wie Socket.dev und fünf- bis sechsstelligen Jahresbeträgen für Enterprise-Lösungen wie JFrog Xray oder umfassende Snyk-Verträge.
Ist es realistisch, alle neun Migrationsschritte gleichzeitig umzusetzen?
Selten. Die meisten Teams setzen die Schritte in zwei bis drei Phasen über mehrere Monate um, wobei Zwei-Faktor-Authentifizierung und OIDC-Token wegen ihres hohen Schutzgewinns bei geringem Aufwand meist zuerst kommen.
Müssen deutsche Unternehmen Vorfälle wie ChainDrop offiziell melden?
Unternehmen, die unter das seit 6. Dezember 2025 geltende NIS-2-Umsetzungsgesetz fallen, rund 29.000 Organisationen aus 18 Sektoren, müssen Sicherheitsvorfälle innerhalb enger gesetzlicher Fristen melden, wenn diese ihre Netz- und Informationssysteme betreffen. Eine kompromittierte Abhängigkeit in der eigenen Produktions-Pipeline kann darunterfallen.
Wie unterscheiden sich diese Angriffe von historischen Fällen wie SolarWinds?
SolarWinds 2020 war eine einzelne, über Monate vorbereitete und sehr gezielte Operation mit rund 18.000 betroffenen Update-Empfängern. GhostAction, Shai-Hulud und ChainDrop sind dagegen automatisiert, wiederholbar und laufen in deutlich höherer Frequenz, mit geringerem Vorbereitungsaufwand pro Einzelfall.
