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.

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.

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:

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:

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.

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: kein langlebiges Credential speichern, sondern pro Lauf ein kurzlebiges gegen eine verifizierte Identität ausstellen.

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

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.