--- title: "npm-Lieferkettenangriffe abwehren: Was wirklich hilft" description: "Das npm-Ökosystem hat sich 2026 stark verändert. Was jetzt standardmäßig sicher ist, was Sie diese Woche selbst einschalten sollten und welche Lücken weiterhin ganz bei Ihnen liegen." author: Aleksei Aleinikov date: 2026-09-09 lang: de tags: [npm-lieferkettenangriff, supply-chain-security, trusted-publishing, npm-provenance, devsecops, ci-cd-sicherheit] canonical: https://www.alekseialeinikov.com/de/blog/topics/security/npm-lieferkettenangriffe-abwehren-2026 source: alekseialeinikov.com --- # npm-Lieferkettenangriffe abwehren: Was wirklich hilft Wenn Sie zuletzt nach dem Shai-Hulud-Wurm über npm-Lieferkettensicherheit gelesen haben, ist Ihr mentales Modell ein Jahr alt. 2026 kam vieles dazu, und ein Teil der damals überall empfohlenen Maßnahmen erledigt npm inzwischen selbst. Hier steht, was heute tatsächlich gilt: was Sie geschenkt bekommen, was weiterhin optional ist, und was niemand für Sie löst. ![npm-Lieferkettenangriffe abwehren: was Standard ist, was optional, und was bei Ihnen bleibt.](https://www.alekseialeinikov.com/blog/npm-supply-chain-attack-mitigation-2026.webp) ## Der Angriff, auf den das alles antwortet GitHub wurde am **14. September 2025** über den **Shai-Hulud**-Angriff informiert. Die Wiederholung lohnt, weil jede Maßnahme unten von ihm geprägt ist: - Einstieg über **kompromittierte Maintainer-Konten**, nicht über eine Paketschwachstelle. - Eingeschleust wurden bösartige **Post-Install-Skripte** in populäre Pakete. - Der Code war **selbstreplizierend** — ein Wurm. - Gestohlen wurden **mehrere Arten von Geheimnissen**, nicht nur npm-Tokens. GitHub entfernte **über 500 kompromittierte Pakete** und blockierte Uploads, die den Indicators of Compromise entsprachen. Jedes beteiligte Paket war eines, das Sie installieren wollten, von einem Maintainer mit gutem Ruf, in einer unauffälligen Versionsnummer. ## Warum Ihr Scanner „sauber" meldete `npm audit` gleicht Ihren Abhängigkeitsbaum mit einer **Advisory-Datenbank** ab. Damit ein Befund existiert, muss ihn zuerst jemand entdecken, melden und veröffentlichen. Eine vor zwanzig Minuten publizierte Schadversion hat davon nichts durchlaufen. Kein Advisory, keine Übereinstimmung, sauberer Bericht. **Eine ehrliche Aktualisierung:** Im August 2026 hat GitHub die Malicious-Packages-Daten der OpenSSF in die Advisory-Datenbank eingebunden. Malware-Advisories stehen jetzt neben CVEs, die Lücke ist kleiner als zuvor. Geschlossen ist sie nicht. Ein Advisory hinkt dem Angriff weiterhin hinterher, und sich in dieser Verzögerung auszubreiten ist das gesamte Geschäftsmodell. Lassen Sie `npm audit` laufen — hören Sie nur auf, ein sauberes Ergebnis als Beweis Ihrer Unversehrtheit zu lesen. ![Warum npm audit einen sauberen Baum meldet: die Advisory-Lücke, in der diese Angriffsklasse lebt.](https://www.alekseialeinikov.com/blog/npm-audit-blind-spot-2026.webp) ## Was Sie jetzt standardmäßig bekommen Das ist der Teil, der sich geändert hat — und der Grund, warum die meisten Ratschläge aus 2025 neu gelesen werden müssen. ### npm v12 deaktiviert Install-Skripte Im Juni 2026 als Breaking Change angekündigt: **npm v12 deaktiviert Install-Skripte standardmäßig**. Angreifer nutzten sie, um Zugangsdaten schon bei der Installation abzuziehen, statt darauf zu warten, dass Ihr Code irgendetwas importiert. Reaktivieren lässt sich das durch gezielte Freigabe einzelner Skripte. Dieselbe Änderung **blockiert Abhängigkeiten über Git- oder Remote-URLs** und schließt damit einen weiteren Ausführungspfad zur Installationszeit. Das ist die wichtigste Zeile dieses Artikels. Genau der Vektor, den Shai-Hulud nutzte, ist standardmäßig aus — **sofern Sie auf v12 sind**. Falls nicht, bleibt es Ihre Aufgabe: ```bash npm ci --ignore-scripts ``` Oder in `.npmrc`: ``` ignore-scripts=true ``` **Die ehrlichen Kosten:** Pakete mit nativen Bestandteilen brauchen ihren Build-Schritt. Ein pauschales Verbot in einem großen Monorepo bricht Installationen. Standardmäßig verbieten, Ausnahmen freigeben — dieses Modell fährt pnpm seit Längerem über `allowBuilds`, mit `dangerouslyAllowAllBuilds` für den kompletten Ausstieg. Der Name verrät, was die Maintainer davon halten. ### Dependabot wartet drei Tage Seit Juli 2026 warten Dependabot-Versionsupdates, **bis ein Release mindestens drei Tage alt ist**, bevor ein Pull Request geöffnet wird. Erkennungssignale bekommen so einen Vorsprung. **Standardmäßig aktiv**, und **Sicherheitsupdates sind ausgenommen** — kritische Fixes verzögern sich nicht. Angreifer leben von Geschwindigkeit. Das nimmt sie ihnen, und kostet Sie praktisch nichts. pnpm setzt eine strengere Variante schon bei der Installation durch: ```yaml # pnpm-workspace.yaml minimumReleaseAge: 10080 # Minuten — eine Woche ``` Eine jüngere Version kommt gar nicht erst infrage. `minimumReleaseAgeExclude` deckt die Pakete ab, die Sie sofort wollen. ### Klassische Tokens gibt es nicht mehr Die npm-Dokumentation ist eindeutig: **Seit November 2025 werden nur noch granulare Zugriffstokens unterstützt, Legacy-Tokens wurden entfernt.** Granulare Tokens lassen sich nach Paket, Scope und Organisation eingrenzen, auf IP-Bereiche beschränken und mit einem Ablaufdatum von mindestens einem Tag versehen. **Ein Fallstrick, den man kennen sollte:** Granulare Tokens haben eine Option **Bypass 2FA**. Sie ist standardmäßig aus, hebt aber im aktivierten Zustand **sowohl konto- als auch paketweite 2FA** beim Veröffentlichen aus. Wenn Sie 2FA für ein Paket erzwingen und jemand ein Bypass-Token besitzt, ist Ihre Durchsetzung nicht das, wofür Sie sie halten. Seit **August 2026** können Bypass-2FA-Tokens keine Konto- oder Governance-Aktionen mehr ausführen — E-Mail oder Passwort ändern, 2FA-Konfiguration anfassen, Tokens verwalten, Maintainer hinzufügen. Dafür ist immer eine interaktive Challenge nötig. Direkt veröffentlichen dürfen sie weiterhin. ### Kompromittierte Konten bekommen eine Abkühlphase Seit Juni 2026 gehen npm-Konten mit hoher Reichweite für **72 Stunden in einen Nur-Lese-Modus**, wenn die E-Mail geändert oder ein 2FA-Wiederherstellungscode benutzt wird. Phishing steht am Anfang dieser Kampagnen; das verschafft dem echten Maintainer Zeit zur Rückgewinnung, bevor das Konto veröffentlichen kann. ## Was weiterhin optional ist Standardeinstellungen decken den letzten Angriff ab. Das Folgende schalten Sie selbst ein. ### Trusted Publishing OIDC zwischen npm und Ihrem CI-Anbieter. Ein benannter Workflow ist zum Veröffentlichen autorisiert. Jede Veröffentlichung erzeugt ein kurzlebiges, signiertes Credential, das sich **weder aus Logs extrahieren noch wiederverwenden lässt**. ```yaml permissions: id-token: write # für OIDC erforderlich contents: read steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: '24' registry-url: 'https://registry.npmjs.org' package-manager-cache: false # in Release-Builds nie cachen - run: npm ci - run: npm test - run: npm publish ``` Randbedingungen für die Planung: - npm CLI **11.5.1+**, Node **22.14.0+** - GitHub Actions, GitLab CI/CD und **CircleCI seit April 2026** - **Nur cloud-gehostete Runner** — selbst gehostete werden nicht unterstützt - Bis zu **10 Trusted Publisher** pro Paket Dieselbe Idee wie beim [Abschaffen von Service-Account-Schlüsseln mit Workload Identity Federation](https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-workload-identity-federation-2026): kein langlebiges Credential speichern, sondern pro Lauf ein kurzlebiges gegen eine verifizierte Identität ausstellen. ![Der npm-Veröffentlichungspfad mit langlebigem Token gegenüber Trusted Publishing mit OIDC.](https://www.alekseialeinikov.com/blog/npm-trusted-publishing-2026.webp) Wer so aus GitHub Actions oder GitLab CI/CD veröffentlicht, erhält **Provenance-Attestierungen automatisch** — ohne `--provenance`. Für CircleCI nicht unterstützt, und für Pakete aus **privaten Repositories** wird keine erzeugt, selbst wenn das Paket öffentlich ist. ### Staged Publishing Mai 2026, optional. Credentials allein verteilen kein Paket mehr: Die Version bleibt **im Staging, bis ein Maintainer sie mit 2FA freigibt**, in der CLI oder auf npmjs.com. Das ist die Maßnahme, die eine vollständig kompromittierte Pipeline überlebt. Ein Angreifer mit Ihren CI-Credentials bekommt eine gestagte Version und eine Benachrichtigung an einen Menschen — kein Release. ### Die nicht mehr genutzten Türen schließen Trusted Publishing einzurichten und den alten Automation-Token gültig zu lassen, bringt wenig. Sobald der neue Ablauf läuft: 1. Package Settings → Publishing access → **„Require two-factor authentication and disallow tokens"** 2. Nicht mehr benötigte Automation-Tokens widerrufen Und bei der 2FA-Einrichtung ist npms Empfehlung eindeutig: **WebAuthn statt TOTP**. TOTP-Codes sind phishbar. ### Beobachten, was den Runner verlässt GitHubs **Actions Network Firewall** ist in der Technical Preview und protokolliert den gesamten ausgehenden Verkehr von Workflow-Läufen — Sie sehen also, wenn ein Job plötzlich mit einer Domain spricht, mit der er nie zuvor gesprochen hat. Das ist der einzige Punkt hier, der **Erkennung** statt Prävention leistet, und deshalb überproportional wertvoll. ## Was all das nicht löst Der Abschnitt, den Hersteller-Posts weglassen. **Ein kompromittierter Maintainer kann weiterhin Schadcode veröffentlichen.** Trusted Publishing belegt, dass das Paket aus dem richtigen Workflow im richtigen Repository kam. Über die Gutartigkeit des Codes sagt es nichts. Mit Commit-Zugriff attestiert die Provenance getreulich einen bösartigen Build. **Install-Skripte sind nicht der einzige Ausführungspfad.** Dass npm v12 sie schließt, verteuert das aktuelle Muster. Gegen eine Nutzlast in der Bibliothek, die Sie importieren und ausführen, hilft es nicht. **Cooldowns sind ein Kompromiss, kein Gewinn.** Sie akzeptieren ein Fenster mit einer bekannt verwundbaren Version, um nicht die Ersten mit einer bösartigen zu sein. Meist richtig. Ein Kompromiss bleibt es — genau deshalb nimmt Dependabot Sicherheitsupdates aus. **Fast nichts davon ist Erkennung.** Jede Maßnahme senkt die Wahrscheinlichkeit, Schadcode auszuführen. Nur Egress-Monitoring sagt Ihnen, dass es bereits passiert ist. Gehen Sie davon aus, dass die Antwort ja lauten könnte — und wissen Sie, wie schnell Sie jedes Geheimnis rotieren können, das ein Build-Job sieht. ## Womit anfangen | Maßnahme | Aufwand | Status | | --- | --- | --- | | Auf npm v12 wechseln (Install-Skripte aus) | Stunden | **Nach Upgrade Standard** | | Dependabot-Cooldown | Keiner | **Bereits aktiv** | | Nur-Lese-Tokens fürs Installieren; kein Publish-Token im Build-Job | Stunden | Bei Ihnen | | Trusted Publishing + Tokens verbieten | Stunden | Optional | | Staged Publishing | Stunden | Optional | | `minimumReleaseAge` (pnpm) | Stunden | Optional | | Granulare Tokens auf Bypass-2FA prüfen | Minuten | Bei Ihnen | | WebAuthn statt TOTP | Minuten | Bei Ihnen | | Egress-Monitoring auf CI-Runnern | Tage | Preview | Zwei Dinge diese Woche: **auf npm v12 wechseln oder bis dahin `ignore-scripts` setzen**, und **Publish-Tokens aus jedem Job entfernen, der auch Abhängigkeiten installiert**. Damit ist der Weg abgedeckt, den Shai-Hulud tatsächlich genommen hat. ## Das Fazit Der Ratschlag von 2025 lautete: „Tun Sie das selbst, weil es sonst niemand tut." Im Lauf von 2026 hat das Ökosystem die beiden wirksamsten Punkte — keine Install-Skripte, keine sofortigen Updates — zum Standard gemacht. Das ist echter Fortschritt. Es bedeutet aber auch, dass sich das verbleibende Risiko verschoben hat: Es sitzt jetzt in dem, was weiterhin ausgeschaltet ist — Trusted Publishing, Staged Publishing und jede Vorstellung davon, mit wem Ihre Build-Maschinen sprechen. `npm audit` wird Ihnen weiterhin sagen, der Baum sei sauber. Es beantwortet eine engere Frage als die, die Sie stellen sollten.