Software-Lieferkette 2026: Wie ein einziger Einbruch hunderte Projekte infiziert

2026 begannen Angriffe auf die Software-Lieferkette, sich selbst zu verbreiten. Ein einziger kompromittierter Entwickleraccount infiziert den nächsten, dann den übernächsten — ohne dass der Angreifer noch einmal eingreift. Ein einziger Einbruch kann hunderte Projekte erreichen.

Drei Fälle prägten das Jahr: Shai-Hulud, ein Wurm, der sich über npm ausbreitet; GlassWorm, Schadsoftware, die Code-Reviews überlebt; und eine registrierungsübergreifende Kampagne, die sogar die Sicherheitsscanner traf, auf die Teams sich verlassen. Hier ist, wie jeder davon funktioniert, wer wahrscheinlich dahintersteckt und welche vier Schutzmaßnahmen den Schaden tatsächlich begrenzen.

Warum sich das Angriffsszenario verändert hat

Jahrelang wählte der Angreifer ein Ziel, fand eine schwache Abhängigkeit darin und nutzte diesen Weg aus. Die Welle von 2026 dreht den Aufwand um. Der Angreifer bricht in ein einziges Paket ein, lässt dieses Paket seine Nachbarn infizieren, und sammelt dabei alle Zugangsdaten ein, die er findet.

Build-Pipelines sind das eigentliche Ziel. Sie beherbergen Publish-Token, Registry-Zugangsdaten und Signing-Keys, und sie führen bei jeder Abhängigkeitsinstallation nicht verifizierten Code aus. Ein einziger gestohlener npm-Token verwandelt einen einzigen Einbruch in eine Veröffentlichung über alle Pakete, die dieser Token veröffentlichen darf. Der Schaden ist nicht mehr das eine Paket, das Sie installiert haben, sondern alle Pakete, von denen diese Pakete abhängen — bis ganz nach unten, was in einem modernen Projekt hunderte Bibliotheken bedeutet, die Sie nie selbst ausgewählt haben.

Shai-Hulud: Ein Paket, das seine eigenen Nachbarn kompromittiert

Shai-Hulud ist die bedeutendste npm-Geschichte des Jahres 2026 — ein sich selbst verbreitender Wurm.

Die Mechanik ist einfach. Ein Entwickler oder ein CI-Job installiert ein vergiftetes Paket. Während der Installation läuft ein Lifecycle-Skript (normalerweise postinstall) auf dieser Maschine. Das Skript sucht nach Zugangsdaten: Umgebungsvariablen im CI-Runner, den Inhalt von ~/.npmrc, Cloud-Metadata-Endpunkte, jeden gecachten Token, den es erreichen kann. Wenn es einen npm-Publish-Token findet, stiehlt es ihn nicht nur. Es verwendet ihn.

Mit diesem Token listet der Wurm alle Pakete auf, die der Maintainer veröffentlichen kann, schmuggelt seine Nutzlast in jedes davon, erhöht die Version und veröffentlicht neu. Jedes nachgelagerte Projekt, das einen Caret- oder Tilde-Versionsbereich akzeptiert, aktualisiert auf eine vergiftete Version, ohne dass jemand den Code angefasst hat. Einige dieser Maintainer haben eigene Publish-Token, also beginnt die Schleife von jedem neuen Account erneut. Der Wurm breitet sich weiter aus, nachdem der Angreifer längst weg ist — das macht Shai-Hulud selbstreplikant statt bloß weitverbreitet.

Lifecycle-Skripte erklären, warum npm so exponiert ist: npm install führt standardmäßig Code aus dem Paket aus, sodass der Angreifer Code ausführen kann, bevor jemand auch nur eine Zeile gelesen hat. Die gleiche Installation, die einen Fix herunterlädt, kann den Wurm mitbringen.

Das Paket zu prüfen, das Sie gerade hinzugefügt haben, reicht nicht mehr aus. Es war vielleicht letzte Woche noch sauber und wurde über Nacht zur Waffe — durch einen Maintainer drei Ebenen über Ihrem Abhängigkeitsbaum, von dem Sie noch nie gehört haben.

GlassWorm: Schadsoftware, die Code-Reviews überlebt

GlassWorm, im März 2026 gemeldet, trifft VS Code- und OpenVSX-Erweiterungen über einen anderen Vektor: die Lücke zwischen dem, was Ihr Bildschirm rendert, und dem, was der Interpreter liest.

Die Nutzlast ist in unsichtbaren Unicode-Zeichen mit Nullbreite geschrieben, die auf dem Bildschirm keinen Platz einnehmen. Bei einem Code-Review sieht das Diff sauber aus. Ein Reviewer, der den Pull Request liest, sieht gewöhnliches, harmloses JavaScript — denn die schädlichen Anweisungen erscheinen weder im Editor noch im Web-Diff-Viewer.

Deshalb überwindet GlassWorm manuelle Code-Reviews. Ein Review ist ein visueller Vorgang: Wir vertrauen darauf, dass das, was wir auf dem Bildschirm sehen, auch das ist, was ausgeführt wird. Nullbreite und bidirektionale Zeichen untergraben dieses Vertrauen. Der Interpreter liest jedes Byte, der Mensch liest nur die sichtbaren. Eine Erweiterung kann ein sorgfältiges Review bestehen, auf OpenVSX veröffentlicht werden und eine Nutzlast tragen, die niemand ohne einen Hex-Dump oder einen Unicode-Linter hätte erkennen können. Da OpenVSX mehrere VS Code-Forks und KI-gestützte Editoren speist, geht die Reichweite weit über Microsofts eigenen Marketplace hinaus.

Die Abhilfe ist Werkzeug, das nicht druckbare und bidirektionale Unicode-Zeichen im Quellcode markiert — und Editor-Erweiterungen als das zu behandeln, was sie sind: privilegierter Code, der sich automatisch aktualisiert. Eine Erweiterung hat vollen Zugriff auf Ihre Dateien und Token. Sie verdient dieselbe Sorgfalt wie eine Abhängigkeit und bekommt sie fast nie.

Die registrierungsübergreifende Welle 2026

Die Welle 2026 überquerte Paket-Registries und Container-Ökosysteme gleichzeitig.

Eine finanziell motivierte Gruppe, die als TeamPCP verfolgt wird, führte im ersten Halbjahr 2026 eine Kampagne durch, die eine Reihe weit verbreiteter Entwicklerwerkzeuge traf. Im März 2026 dokumentierte das Microsoft Defender Security Research-Team die Kompromittierung von Trivy, dem Container- und IaC-Scanner, nachdem die Angreifer eine unvollständige Behebung eines früheren Problems ausgenutzt und veränderliche Versions-Tags missbraucht hatten, um bösartige Commits in Trivys Release-Baum einzuschleusen. Die Kampagne setzte sich im April fort: Am 22. April wurden vergiftete Images in das Checkmarx kics Docker-Repository gepusht und ein schädlicher @bitwarden/cli-Build auf npm veröffentlicht. Früher im Verlauf wurde ein PyPI-SDK getroffen. Die Ziele umfassten Go-CLI-Werkzeuge, Docker Hub-Images, npm-Pakete und PyPI — die Angreifer waren keiner einzigen Registry treu.

Wenn der Scanner selbst vergiftet ist, wird das Werkzeug, das die Bedrohung finden soll, zu dem, das sie ausliefert. Die Bitwarden CLI verwaltet Geheimnisse per Design, sodass ein manipulierter Build ein schneller Weg zu Zugangsdaten ist — auch wenn dieses npm-Paket nur etwa neunzig Minuten online war, bevor es zurückgezogen wurde. Das kics-Image lag auf Docker Hub, einem Repository mit Millionen von Pulls, sodass die Infektion von Paket-Registries in die Container-Welt und in CI-Pipelines überging, die bei jedem Run Images ziehen.

Ein moderner Build zieht gleichzeitig aus vielen Quellen, und jede ist ein separater Kanal mit eigenen Veröffentlichungskontrollen. Ein Angreifer braucht nur den schwächsten. Die Angriffsfläche wächst schneller, als die meisten Teams aufzählen können, was sie überhaupt zur Build-Zeit beziehen.

Wer dahintersteckt — mit vorsichtiger Attribution

Attribution bei Lieferkettenangriffen ist selten eindeutig. Das Folgende sind Einschätzungen, keine Urteile.

Die Gruppe, die am direktesten mit der Wurmaktivität 2026 in Verbindung gebracht wird, ist TeamPCP, eine finanziell motivierte Gruppe, die Ende 2025 aufgetaucht ist. Forscher verknüpfen die Mini-Shai-Hulud-Wellen und die Kompromittierungen von Trivy, Checkmarx kics und Bitwarden CLI mit demselben Cluster. Im Mai 2026 veröffentlichte die Gruppe ihr Shai-Hulud-Framework als Open Source auf GitHub — ein modulares Werkzeugpaket zum Ernten von Zugangsdaten und zum Vergiften von Lieferketten. Forscher, die die Gruppe beobachten, beschreiben ihr Ziel als finanziell: ein wiederholbarer, automatisierter Weg, das Vertrauen von Entwicklern zu monetarisieren.

Der Group-IB-Bericht 2026 ordnet diese Aktivität in ein breiteres Feld von Lieferkettenakteuren ein. Lazarus, höchstwahrscheinlich mit Nordkorea verbunden, veröffentlicht bösartige npm-Pakete, die populäre Bibliotheken imitieren, und lockt Entwickler über gefälschte Vorstellungsgespräche mit Credential-Stealing-Malware. DragonForce betreibt Ransomware-as-a-Service, das auf Managed Service Provider abzielt, und nutzt dann deren Administratorzugang, um jeden ihrer Kunden nachgelagert zu erreichen. Eine als 888 verfolgte Gruppe verkauft Zugänge auf Basis gemeinsamer Anbieterverbindungen; in einem Fall kompromittierte sie einen einzelnen Auftragnehmer, der für mehrere Unternehmen tätig war, und zog deren Quellcode auf einmal ab.

Was diese Gruppen verbindet, ist eine gemeinsame Kalkulation: Einen vorgelagerten Lieferanten oder Auftragnehmer zu infiltrieren ist billiger und unauffälliger als jeden Angriff einzeln durchzuführen. Staatliche Akteure, Ransomware-Gruppen und Zugangsvermittler haben sich alle auf diesen Ansatz eingeschossen.

Vier Schutzmaßnahmen, die den Schaden tatsächlich begrenzen

Die meisten Empfehlungen zur Lieferkettensicherheit sind generisch. Diese vier Maßnahmen treffen direkt auf die beschriebenen Angriffe zu, mit der Begründung, warum jede davon wirkt.

SBOM erstellen und verwenden

Eine Software-Stückliste (SBOM, Software Bill of Materials) ist das Inventar, ohne das man sich nicht verteidigen kann. Die registrierungsübergreifende Kampagne funktioniert teilweise, weil Teams nicht wissen, was sie beziehen. Erstellen Sie ein SBOM (Format CycloneDX oder SPDX) zur Build-Zeit, speichern Sie es als Artefakt und vergleichen Sie es zwischen Builds. Wenn das nächste Security Advisory ein Paket nennt, sollte die Antwort auf „Sind wir betroffen?” Minuten dauern, nicht Tage. Ein SBOM-Diff erkennt eine nächtliche Neuveröffentlichung durch einen Wurm, bevor sie die Produktion erreicht.

Abhängigkeiten fixieren und Lockfile-Integrität erzwingen

Das Fixieren von Versionen ist die einzelne wirkungsvollste Maßnahme gegen Wurmausbreitung. Die Schwachstelle ist der ^- oder ~-Versionsbereich. Ein Caret akzeptiert stillschweigend eine neue Minor- oder Patch-Version — genau so erreicht eine vergiftete Neuveröffentlichung Sie, ohne dass Sie den Code angefasst haben. Fixieren Sie exakte Versionen, committen Sie Ihr Lockfile, verwenden Sie npm ci statt npm install in CI und verifizieren Sie Integritätshashes. Wo ein bekannt schlechtes Release existiert, erzwingen Sie eine Fixierung bis ganz nach unten:

{
  "overrides": {
    "compromised-pkg": "1.2.3"
  }
}

Ein fixiertes, hash-verifiziertes Lockfile hätte den Kerntrick von Shai-Hulud stumpf gemacht — das stille Upgrade auf eine vergiftete Version.

Artefakte signieren und Herkunft verifizieren

Hören Sie auf anzunehmen, dass eine Registry Ihnen das geliefert hat, was der Maintainer tatsächlich veröffentlicht hat. Signieren Sie Build-Artefakte und prüfen Sie Signatur und Herkunft, bevor Sie sie ausführen. Sigstores cosign zusammen mit SLSA-Provenance-Attestierungen ermöglicht es zu beweisen, wo ein Artefakt gebaut wurde und durch welche Pipeline — und alles abzulehnen, das die Prüfung nicht besteht:

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/your-org/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/your-org/your-image:latest

Das ist dieselbe Idee, auf Artefakte angewendet. Statt dem Kanal zu vertrauen, verifizieren Sie jedes Artefakt und jede Identität in der Pipeline — die Haltung, die unser Zero-Trust-Leitfaden 2026 auf Netzwerk und Identitäten anwendet. Artefaktverifizierung ist die Schutzmaßnahme, die ein Fall wie die Trivy-Kompromittierung im März erfordert.

Auf OIDC Trusted Publishing umstellen

Langlebige Token sind der Treibstoff, der einem Wurm erlaubt, sich auszubreiten. Shai-Hulud breitet sich aus, weil er einen wiederverwendbaren npm-Token in CI findet und ihn wiederverwendet. Die meisten CI-Setups haben genau einen langlebigen npm-Token, der vor Jahren von jemandem hinzugefügt wurde, der das Unternehmen seitdem verlassen hat. OIDC Trusted Publishing beseitigt den Token: Die Registry vertraut einer kurzlebigen Identität, die auf einen einzigen Workflow beschränkt und bei jedem Run frisch ausgestellt wird — es gibt also nichts Dauerhaftes zu stehlen aus ~/.npmrc oder der Umgebung eines Runners. Keine stehenden Zugangsdaten bedeutet keinen Wurmtreibstoff. Wenn Sie 2026 aus CI veröffentlichen, ist das die Änderung, die die Schleife schließt, auf der der Wurm läuft.

Häufige Fragen

Was ist ein Lieferkettenangriff auf Software?

Er vergiftet Software, bevor sie Sie erreicht — indem eine Abhängigkeit, ein Build-Werkzeug, eine Registry oder die Zugangsdaten eines Maintainers manipuliert werden. Sie beziehen dann den bösartigen Code über Ihre normale Installation oder Aktualisierung, statt durch einen direkten Einbruch in Ihre eigenen Systeme.

Was unterscheidet Shai-Hulud von einem gewöhnlichen bösartigen Paket?

Er breitet sich von selbst aus. Ein gewöhnliches bösartiges Paket sitzt in einer Registry und wartet darauf, installiert zu werden. Shai-Hulud stiehlt die Publish-Token desjenigen, der ihn installiert, nutzt sie, um alle anderen Pakete dieses Maintainers zu vergiften und neu zu veröffentlichen, und wiederholt das von jedem neuen Account, den er erreicht — ohne dass der Angreifer einen Finger rühren muss.

Wie verbirgt sich GlassWorm vor Code-Reviews?

Er schreibt seine Nutzlast in unsichtbare Unicode-Zeichen mit Nullbreite, die auf dem Bildschirm nicht erscheinen. Ein Reviewer, der das Diff liest, sieht sauberen Code, weil die schädlichen Anweisungen keinen sichtbaren Platz einnehmen, während der Interpreter trotzdem jedes Byte liest und ausführt.

Welche Werkzeuge wurden in der registrierungsübergreifenden Welle 2026 getroffen?

Eine TeamPCP-Kampagne traf Trivy im März 2026, dokumentiert vom Microsoft Defender Security Research-Team, dann das Checkmarx kics Docker-Image und das @bitwarden/cli npm-Paket am 22. April, mit früherer PyPI-Aktivität in derselben Kampagne. Sie umfasste Go-CLI-Werkzeuge, Docker Hub und mehrere Paket-Registries — nicht nur ein Ökosystem.

Wer steckt hinter den Lieferkettenangriffen 2026?

Sicherheitsforscher verknüpfen die Mini-Shai-Hulud-Wellen und die Kompromittierungen von Trivy, kics und Bitwarden CLI mit einer finanziell motivierten Gruppe namens TeamPCP. Der Group-IB-Bericht 2026 ordnet sie in ein breiteres Feld von Akteuren ein, darunter Lazarus, DragonForce und eine als 888 verfolgte Gruppe. Die Attribution bleibt eine Einschätzung, kein Urteil.

Was ist die wirksamste einzelne Schutzmaßnahme?

Gegen Wurmausbreitung konkret: Fixieren Sie exakte Versionen mit einem hash-verifizierten Lockfile und kombinieren Sie das mit OIDC Trusted Publishing, um langlebige Token zu eliminieren. Das Fixieren stoppt das stille vergiftete Upgrade; OIDC entfernt die Zugangsdaten, die der Wurm zum Ausbreiten braucht.

Was bleibt

Die Welle 2026 belohnt Teams, die wissen, was sie ausführen, und es prüfen, bevor sie es starten. Beginnen Sie dieses Quartal mit zwei Maßnahmen: Fixieren und hash-verifizieren Sie Ihre Lockfiles, um stille Upgrades zu unterbinden, und wechseln Sie CI-Veröffentlichungen auf OIDC, sodass es keine langlebigen Token mehr zu stehlen gibt. Fügen Sie danach SBOM-Generierung und cosign-Verifizierung hinzu. Nichts davon ist exotisch, und zusammen verwandeln diese vier Maßnahmen einen kompromittierten Maintainer zurück in einen eingedämmten Vorfall statt in eine sich selbst ausbreitende Kontamination.