npm-Sicherheits-Best Practices: So schützen Sie Ihre Pakete nach dem Shai-Hulud-Angriff von 2025

Angriffe wie Shai-Hulud, Nx, event-stream, colors, node-ipc und andere zeigen: Paketmanager sind Ausführungsumgebungen und nicht bloß Bibliotheks-Downloader. Wir müssen beim Management von Drittanbieter-Abhängigkeiten wachsam sein und für angemessene Sicherheitskontrollen sorgen.

Die folgende kuratierte, praxisorientierte und sicherheitsfokussierte Checkliste zur Absicherung von npm-Paketmanagern enthält Empfehlungen für sichere lokale Entwicklungsabläufe und die Prozesse von Open-Source-Maintainern. Halten Sie sie neben Ihrem Terminal geöffnet.

Im Folgenden finden Sie wichtige Highlights zu Sicherheitspraktiken, Tools und Bereichen, in denen wir eine verantwortungsvolle Nutzung für Entwickler und Open-Source-Maintainer gleichermaßen erläutern:

• Sichere CLI-Optionen mit sicheren Standardwerten für npm, pnpm, Bun, Yarn und Deno

• Absicherung der Supply Chain und deterministische Installationen

• Lockfile- und Abhängigkeitshygiene

• Prüfungen auf Schwachstellen und Paketqualität

• Umgang mit Secrets und Isolierung der Entwicklungsumgebung

• Praktiken für Maintainer: 2FA, Provenance, OIDC und Reduzierung von Abhängigkeiten

Über Shai-Hulud und Supply-Chain-Malware

Die Shai-Hulud-Angriffsfamilie markiert einen Wendepunkt für JavaScript-Entwickler: npm install ist eindeutig ein Mechanismus zur Remote-Code-Ausführung und keine harmlose Komfortfunktion mehr. Im September 2025 nutzte die ursprüngliche Shai-Hulud-Kampagne manipulierte Versionen von Paketen wie ngx-bootstrap, ng2-file-upload und @ctrl/tinycolor, um über npm-Lifecycle-Skripte eine wurmartige Payload einzuschleusen. Bösartige postinstall-Hooks luden eine verschleierte Datei bundle.js nach, die auf Entwicklerrechnern und CI-Agenten ausgeführt wurde, npm-, GitHub- und Cloud-Zugangsdaten abgriff und sie über Webhooks und GitHub-Workflows exfiltrierte. Letztlich waren Hunderte Pakete betroffen.

Am 24. November 2025 trat SHA1-Hulud als zweite Welle derselben Angriffsidee in Erscheinung und zeigte, wie schnell Angreifer ihre Methoden weiterentwickeln. Diese Variante verbreitet sich über trojanisierte npm-Pakete, die Payloads in preinstall-Skripten verstecken. Nach der Installation versucht der Wurm, das Opfer in einen von Angreifern kontrollierten, selbst gehosteten GitHub-Actions-Runner zu verwandeln, schleust bösartige Workflows in Repositories ein und führt damit beliebige Befehle aus, um npm- und GitHub-Secrets abzuschöpfen. Er sucht gezielt nach AWS-, Azure- und GCP-Zugangsdaten und versucht in manchen Fällen sogar, aus Containern auszubrechen, auf dem Host seine Berechtigungen auszuweiten und das Home-Verzeichnis des Nutzers durch destruktives „Wiper“-Verhalten zu zerstören. Zum Zeitpunkt der Veröffentlichung wurden mehr als 600 Pakete als Teil dieser Kampagne identifiziert, darunter beliebte Pakete von Anbietern wie Zapier, PostHog und Postman. Die Zahl steigt weiter.

Zusammen zeichnen Shai-Hulud und SHA1-Hulud ein klares Muster moderner Supply-Chain-Malware. Sie missbrauchen die npm-Lifecycle-Hooks als Angriffsfläche zur Ausführung von Code, nutzen Entwicklerrechner und CI/CD-Infrastruktur als Sprungbrett und haben es in Wirklichkeit auf Cloud-Zugangsdaten, Tokens und Secrets abgesehen. Die Details der einzelnen Vorfälle entwickeln sich noch weiter, doch das Muster ist bereits klar genug, um daraus dauerhafte Praktiken abzuleiten, die jedem JavaScript-Entwickler in Fleisch und Blut übergehen sollten.

Dieser Spickzettel macht aus diesen Erkenntnissen konkrete Maßnahmen, die Sie sofort umsetzen können: sichere Paketmanager-Einstellungen als Standard konfigurieren, sich gegen Supply-Chain-Angriffe absichern, eine deterministische und sichere Auflösung von Abhängigkeiten durchsetzen, kontinuierliche Prüfungen auf Schwachstellen und Paketqualität integrieren und diese Kontrollen npm, pnpm, Bun sowie den übrigen Tools Ihrer Toolchain zuordnen. Ziel ist nicht, speziell auf Shai-Hulud zu reagieren, sondern den npm-Alltag gegen die von diesem Angriff repräsentierte Angriffsklasse widerstandsfähig zu machen.

Schnellübersicht

1. Post-Install-Skripte deaktivieren

2. Mit Cooldown installieren

3. Installationen mit npq absichern

4. Lockfile-Injection verhindern

5. Deterministisch installieren (npm ci usw.)

6. Keine blinden Upgrades

7. Keine Secrets im Klartext in .env

8. In Containern entwickeln

9. npm-2FA aktivieren

10. Mit Provenance veröffentlichen

11. Mit OIDC veröffentlichen (Trusted Publishing)

12. Abhängigkeitsbaum verkleinern

1. Post-Install-Skripte deaktivieren

Ziel ist es, die Ausführung beliebigen Codes während install zu verhindern.

Risiko

Post-Install- und andere Lifecycle-Skripte sind ein wichtiger Angriffsvektor für Supply-Chain-Angriffe (Shai-Hulud, Nx, event-stream). Jede direkte oder transitive Abhängigkeit kann während der Installation beliebigen Code ausführen.

Grundlegende npm-Absicherung

Global: alle Lifecycle-Skripte deaktivieren (empfohlen):

# Safe-by-default on your machine
npm config set ignore-scripts true

Pro Installation:

# One-off installs without running lifecycle scripts
npm install --ignore-scripts <package-name>

pnpm

Ab v10 deaktiviert pnpm postinstall-Skripte standardmäßig und unterstützt eine Zulassungsliste sowie die Möglichkeit, sie wieder zu aktivieren. Wir empfehlen, die Dokumentation zur Supply-Chain-Sicherheit von pnpm für weitere Konfigurationsbeispiele zu lesen.

Bun

Bun deaktiviert postinstall-Skripte standardmäßig und verwaltet eine interne Zulassungsliste. Über trustedDependencies in package.json können Sie bestimmten Abhängigkeiten ausdrücklich vertrauen:

{
  "trustedDependencies": [
    "some-package",
    "another-package"
  ]
}

Nur wirklich benötigte Skripte ausführen

Verwenden Sie eine Zulassungsliste, statt package.json blind zu vertrauen:

1# Use LavaMoat's allow-scripts to define where scripts may run
2npm install --save-dev @lavamoat/allow-scripts
3npx allow-scripts

Mit LavaMoats npm-Paket allow-scripts können Sie Skripte an bestimmten Stellen in Ihrem Abhängigkeitsgraphen gezielt aktivieren – für vertrauenswürdige npm-Pakete, die tatsächlich Pre-Install- oder Post-Install-Skripte benötigen, beispielsweise bcrypt, playwright und andere.

2. Mit Cooldown installieren

Ziel ist es, „brandneue und bösartige“ Releases sowie Typosquatting-Fallen zu vermeiden.

Risiko

Angreifer nutzen SemVer und die Auflösung auf „latest“ aus, indem sie neue Versionen veröffentlichen, die schnell erkannt und wieder zurückgezogen werden. Wenn Sie sofort installieren, tragen Sie die Folgen.

npm: zeitbasierte Installationen

Versionen zulassen, die vor einem bestimmten Datum veröffentlicht wurden:

# Install only if published before 2025-01-01
npm install express --before=2025-01-01

Dynamischer 7-Tage-Cooldown (Beispiel mit BSD-ähnlichem date):

npm install express --before="$(date -v -7d)"

Hinweis: Dies ist manuell und für Automatisierungen anfällig, bietet aber eine nützliche, explizite Sicherheitsmaßnahme.

2.1 pnpm minimumReleaseAge

In pnpm-workspace.yaml:

minimumReleaseAge: 20160  # minutes; here: 2 weeks

pnpm lehnt Versionen ab, die jünger als dieser Zeitraum sind. So erhält das Ökosystem Zeit, bösartige oder fehlerhafte Releases zu erkennen.

2.2 Snyk-Cooldown bei automatischen PRs

Die automatischen PRs von Snyk für Abhängigkeitsupgrades überspringen Versionen, die jünger als etwa 21 Tage sind. Dadurch werden folgende Risiken reduziert:

• Upgrades auf fehlerhafte Versionen, die schnell wieder zurückgezogen werden

• Upgrades auf Pakete, die von kompromittierten Konten veröffentlicht wurden

Das ist ein Muster, bei dem der Cooldown direkt in die Automatisierung integriert ist.

3. Installationen mit npq absichern

Ziel ist es, die Installation eines Pakets so lange zu vermeiden, bis es grundlegende Sicherheits- und Plausibilitätsprüfungen bestanden hat.

Problem

Sie führen Folgendes aus:

npm install some-package

und wissen nicht, ob:

• es sich um einen Tippfehler bei einem beliebten Paket handelt

• es gestern ohne bisherige Nutzung veröffentlicht wurde

• bekannte Schwachstellen enthalten sind

• es gefährliche Pre- oder Post-Install-Skripte enthält

Strategie: npq vor die Installationsbefehle schalten

npq ist ein Sicherheitsprüfer vor der Installation (verwendet für die Prüfungen sogenannte „Marshalls“).

Installieren:

npm install -g npq

Anstelle von npm verwenden:

npq install express

Als Standard festlegen:

alias npm='npq-hero'

# Persist the alias
echo "alias npm='npq-hero'" >> ~/.zshrc  # or ~/.bashrc
source ~/.zshrc

Bei Verwendung des npq-Pakets werden npq und pq-hero installiert. Letzteres fungiert als direkt einsetzbarer npm-Wrapper.

Was npq prüft („Marshalls“)

• Schwachstellen anhand der Snyk-CVE-Datenbank

• Erkennung neuer Pakete (jünger als 22 Tage)

• Reifegrad der Version (Version jünger als 7 Tage)

• Ähnlich aussehende Namen zur Täuschung

• Überprüfung der npm-Registry-Signatur

• Provenance-Attestierung des Builds

• Vorhandensein von Pre- und Post-Install-Skripten

• Paketqualität: README, LICENSE, Repository-URL, Downloads

• Einführung von Binärdateien (neue CLI-Tools)

• Deprecation-Hinweise

• Gültigkeit der Maintainer-Domain / abgelaufene Domains

Integration mit pnpm und Bun

# One-off
NPQ_PKG_MGR=pnpm npq install fastify
NPQ_PKG_MGR=bun   npq install fastify

# Make pnpm go through npq
alias pnpm="NPQ_PKG_MGR=pnpm npq-hero"

4. npm-Lockfile-Injection verhindern

Ziel ist sicherzustellen, dass package-lock.json / yarn.lock Sie nicht unbemerkt auf bösartige Quellen umleiten können.

Risiko

Ein Mitwirkender (oder ein Angreifer über einen PR) kann:

• Ein bösartiges Paket zum Lockfile hinzufügen.

• Die URL unter resolved so ändern, dass sie auf einen von ihm kontrollierten Host verweist (Git-Repository, Tarball, Gist).

• Den Integrity-Hash so anpassen, dass er „gültig“ aussieht.

Beim nächsten install wird dann Malware heruntergeladen, selbst wenn package.json harmlos aussieht.

Gegenmaßnahme: lockfile-lint

Installieren:

npm install --save-dev lockfile-lint

Lockfile anhand zugelassener Hosts und HTTPS validieren:

npx lockfile-lint \
  --path package-lock.json \
  --type npm \
  --allowed-hosts npm yarn \
  --validate-https

Wichtige Validierungsoptionen

• Host-Validierung – nur npm, yarn, verdaccio usw.

• HTTPS erzwingen – unsichere URL-Schemata ablehnen

• Schema-Validierung – https:, git+https:, git+ssh: auf die Zulassungsliste setzen

• Paketnamenvalidierung – die aufgelöste URL muss zum Paketnamen passen

• Integritätsvalidierung – sichere SHA-512-Integritätshashes erzwingen

CI/CD-Integration

Einen Lockfile-Lint-Schritt vor der Installation hinzufügen:

{
  "scripts": {
    "lint:lockfile": "lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https",
    "preinstall": "npm run lint:lockfile"
  }
}

pnpm und Lockfile-Injection

Die pnpm-lock.yaml-Datei von pnpm ist widerstandsfähiger, weil:

• es nicht in gleicher Weise auf beliebige Tarball-URLs angewiesen ist

• es kein Paket installiert, das zwar im Lockfile, aber nicht in package.json enthalten ist

• das Format mehrere der bei npm und Yarn bekannten Injection-Angriffsvektoren vermeidet

Behandeln Sie Lockfiles dennoch als sicherheitskritische Artefakte.

5. Deterministisch installieren (npm ci)

Ziel ist sicherzustellen, dass Builds und Produktionsumgebungen die exakt im Lockfile festgelegten Versionen verwenden.

Risiko

npm install versucht, Abweichungen zwischen package.json und Lockfile zu „beheben“. Das kann:

• andere Versionen einbeziehen als die aufgezeichneten

• die Reproduzierbarkeit in CI und Produktion beeinträchtigen

• unerwartete, verwundbare oder bösartige Versionen einführen

npm: ci statt install

Lokal und in CI:

# Deterministic install based on package-lock.json
npm ci

Nur Produktionsabhängigkeiten in CI/CD:

npm ci --only=production

Stellen Sie sicher, dass Lockfiles eingecheckt und auf dem neuesten Stand gehalten werden.

Deterministische Befehle für verschiedene Paketmanager

Yarn:

yarn install --immutable --immutable-cache

pnpm:

pnpm install --frozen-lockfile

Bun:

bun install --frozen-lockfile

Deno:

deno install --frozen

Lockfiles sind Teil Ihrer Supply-Chain-Vereinbarung und keine Build-Artefakte, die ignoriert werden können.

6. Keine blinden Upgrades von npm-Paketen

Ziel ist es, Upgrades nach Prüfung und anhand relevanter Hinweise durchzuführen – nicht pauschal „alles auf die neueste Version“ zu bringen.

Risiko

Vermeiden Sie blinde Upgrades von Drittanbieter-Abhängigkeiten wie diesem:

npm update
npx npm-check-updates -u

Wenn Sie diese Befehle in CI oder lokalen Entwicklungsumgebungen ausführen, setzen Sie sich folgenden Risiken aus:

• Bösartige Versionen zurückziehen, die von kompromittierten Maintainer-Konten veröffentlicht wurden

• Einführung schwerwiegender Fehler und zurückgezogener Releases

• Auslösung von Dependency-Confusion- oder Namespace-Hijacking-Angriffen

Bessere Vorgehensweisen

1. Interaktive Upgrades:

npx npm-check-updates --interactive

2. Prüfen Sie jede Abhängigkeit, bevor Sie sie aktualisieren.

3. Sicherheitsbewusste Bots:

• Automatische Upgrade-PRs von Snyk

• Dependabot-PRs von GitHub

4. Diese erstellen prüfbare PRs mit Kontext (Änderungsprotokolle, CVEs), statt Ihr Lockfile unbemerkt zu ändern.

7. Keine Secrets im Klartext in .env-Dateien

Ziel ist es, zu verhindern, dass Secrets trivial aus Ihrer Entwicklungsumgebung exfiltriert werden können.

Risiko

.env-Dateien und Umgebungsvariablen im Klartext:

• sind ein leichtes Ziel für bösartige Pakete oder Malware in der Entwicklungsumgebung.

• landen häufig in Logs, Crash-Dumps, im Terminal-Verlauf usw.

• werden bei Supply-Chain-Angriffen über process.env oder direkt aus Dateien ausgelesen.

Ein Anti-Pattern:

DATABASE_PASSWORD=my-secret-password
API_KEY=sk-1234567890abcdef

Muster: Secret-Referenzen und Just-in-Time-Injektion

Schritt 1 – Referenzen (keine Werte) in .env eintragen:

DATABASE_PASSWORD=op://vault/database/password
API_KEY=infisical://project/env/api-key

Schritt 2 – Zur Laufzeit die CLI des Secret-Managers verwenden. Hier am Beispiel der 1Password-CLI:

# Run app with secrets injected into process.env
op run -- npm start

# More explicit example with env-file
op run --env-file="./.env" -- node --env-file="./.env" server.js

Weitere Optionen: Infisical CLI, Cloud-Secret-Manager usw. Die Grundidee: Die Umgebungsvariable enthält einen Verweis und nicht das Secret.

8. In Dev-Containern arbeiten

Ziel ist es, Ihre Entwicklungsumgebung zu isolieren, damit npm-Malware nicht die Kontrolle über Ihren Host übernimmt.

Risiko

Wenn Sie npm install auf Ihrem Host ausführen:

• können bösartige Pakete Dateien aus Ihren anderen Repositories lesen

• können sie SSH-Schlüssel, Browserprofile, AI-/Agent-Tokens usw. durchsuchen

• teilen sie den OS-Namespace mit allem anderen, was Sie ausführen

Muster für Dev-Container

Verwenden Sie VS Code Dev Containers (oder ein ähnliches Tool) zur Isolierung, zum Beispiel mit der folgenden Dev-Container-Konfigurationsdatei .devcontainer/devcontainer.json:

{
  "name": "Node.js Dev Container",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:18",
  "features": {
    "ghcr.io/devcontainers/features/1password:1": {}
  },
  "postCreateCommand": "npm ci"
}

Anschließend:

1. Den Ordner in VS Code öffnen

2. „In Container erneut öffnen“

3. Alle Installationen und Ausführungen finden innerhalb des Containers statt.

Dev-Container absichern

Docker-Sicherheitsoptionen und sichere Node-Flags hinzufügen:

"runArgs": [
  "--security-opt=no-new-privileges:true",
  "--cap-drop=ALL",
  "--cap-add=CHOWN",
  "--cap-add=SETUID",
  "--cap-add=SETGID"
],
"containerEnv": {
  "NODE_OPTIONS": "--disable-proto=delete"
}

Noch mehr Kontrolle erhalten Sie mit einem benutzerdefinierten Dockerfile, das minimale Basis-Images, einen Nicht-Root-Benutzer und eine gehärtete Laufzeitumgebung verwendet.

9. 2FA für npm-Konten aktivieren

Ziel ist es, zu verhindern, dass eine Kontoübernahme dazu führt, dass kompromittierte Konten bösartige Versionen veröffentlichen.

Risiko

Vorfälle wie eslint-scope haben gezeigt: Sobald Angreifer Zugangsdaten erlangen, können sie manipulierte Versionen veröffentlichen, die Millionen von Nutzerinnen und Nutzern erreichen. Eine Authentifizierung nur mit Passwort reicht nicht aus.

Befehle

2FA für Anmeldung, Veröffentlichung und Profiländerungen:

npm profile enable-2fa auth-and-writes

2FA nur für Anmeldung und Profiländerungen (weniger strikt):

npm profile enable-2fa auth-only

Wenden Sie die Einstellung „auth-and-writes“ auf alle Konten an, die Pakete veröffentlichen oder Maintainer hinzufügen können.

Vertrauenswürdige OIDC-Veröffentlichung konfigurieren

Zusätzlich zu geeigneten Passwortschutzmaßnahmen für Ihr npm-Konto, etwa 2FA und Passkeys, sollten Sie die neue Methode Trusted OIDC Publishing als einzige Möglichkeit zum Veröffentlichen neuer npm-Pakete nutzen. Dabei wird die Veröffentlichung direkt Ihrem GitHub-Repository und bestimmten Workflows zugeordnet. Weiter unten finden Sie einen eigenen Abschnitt dazu.

10. Mit Provenance-Attestierungen veröffentlichen

Ihr Ziel: Verbraucherinnen und Verbraucher sollen überprüfen können, wo und wie Ihr Paket erstellt wurde.

Problem

Ohne Provenance können Verbraucherinnen und Verbraucher nur schwer feststellen:

• Wurde dieses Tarball aus GitHub-Quellcode A oder auf einem nicht vertrauenswürdigen Rechner erstellt?

• Hat eine kompromittierte CI-Pipeline Code eingeschleust?

Lösung: npm publish --provenance

In GitHub Actions:

permissions:
  id-token: write

steps:
  - run: npm publish --provenance

Voraussetzungen:

• npm CLI 9.5.0+

• GitHub Actions (oder GitLab CI/CD) mit cloud-gehosteten Runnern und OIDC-Unterstützung

Dadurch entstehen kryptografisch überprüfbare Build-Metadaten, die an aufkommenden Supply-Chain-Standards (z. B. OpenSSF) ausgerichtet sind.

11. Mit OIDC veröffentlichen (Trusted Publishing)

Ihr Ziel: langlebige npm-Tokens aus CI/CD entfernen.

Risiko

Langlebige Tokens:

• Werden versehentlich protokolliert oder in Commits aufgenommen

• Bleiben auch nach einem Leak gültig

• Ermöglichen umfassenden, langfristigen Zugriff auf Ihre Organisation und Pakete

Trusted-Publishing-Verfahren

1. Konfigurieren Sie das Paket auf npmjs.com als vertrauenswürdigen Publisher (GitHub oder GitLab).

2. Verwenden Sie OIDC in Ihrem Workflow:

Beispiel für GitHub Actions:

permissions:
  id-token: write

steps:
  - run: npm publish

NPM_TOKEN wird nirgendwo gespeichert. npm überprüft das OIDC-Token Ihrer CI und erlaubt Veröffentlichungen nur aus Ihren genehmigten Workflows. Provenance-Attestierungen werden automatisch erstellt.

12. Abhängigkeitsbaum Ihres Pakets verkleinern

Ihr Ziel: einen kleineren Abhängigkeitsgraphen schaffen und dadurch die Angriffsfläche verringern, die Sie gefährden könnte.

Risiko

Jede Abhängigkeit:

• Bringt eigene transitive Abhängigkeiten mit

• Übernimmt Maintainer, Konten und deren potenzielle Kompromittierungen

• Vergrößert Ihre Angriffsfläche in Bezug auf Schwachstellen und Lizenzen

Strategie

Setzen Sie bevorzugt auf Designs ohne oder mit wenigen Abhängigkeiten. Nutzen Sie modernes JavaScript, statt für einfache Aufgaben eine Utility-Bibliothek einzubinden.

Beispiele:

// Instead of lodash uniq
const unique = [...new Set(array)];

// Instead of axios for simple HTTP GET
const response = await fetch(url);

// Instead of utility libs for trivial checks
const isEmpty = obj => Object.keys(obj).length === 0;

Fragen Sie sich (oder Ihr Team), bevor Sie eine Abhängigkeit hinzufügen:

• Ist diese Funktionalität nicht trivial?

• Rechtfertigt sie den Aufwand für Sicherheit und Wartung?

• Gibt es inzwischen eine Standard-API dafür?

Ausblick auf Entwicklersicherheit und Malware in der Supply Chain

Dieser Leitfaden fasst einige npm-Sicherheits-Best-Practices zusammen, die wir erstmals 2019 veröffentlicht haben. Er baut sie weiter aus und ergänzt sie um moderne Praktiken sowie Erkenntnisse aus den Supply-Chain-Angriffen, die wir 2025 beobachtet haben.

Erstens müssen Entwicklerinnen und Entwickler den Paketmanager als nicht vertrauenswürdige Ausführungsumgebung behandeln und ihn standardmäßig sicher konfigurieren. Das bedeutet, Lifecycle-Skripte nach Möglichkeit zu deaktivieren, bei echtem Bedarf auf explizite Zulassungslisten zu setzen und Schutzmaßnahmen wie Cooldown-Zeiträume und Prüfungen vor der Installation einzurichten. So wird die „Installation eines neuen Pakets“ zu einer bewussten Handlung statt zu einem Reflex. Diese Kontrollen müssen über npm hinaus auch pnpm, Bun und andere moderne Paketmanager umfassen, damit in allen Tools der Entwicklungsumgebung dieselben sicheren Standardeinstellungen gelten.

Zweitens muss die Auflösung von Abhängigkeiten deterministisch und nachvollziehbar sein. Die Shai-Hulud-Kampagnen nutzten aus, dass ein einzelnes unbemerktes Versionsupdate oder eine Änderung an der Lockdatei ein schädliches Tarball in Tausende Projekte einschleusen konnte. Teams sollten ihre Workflows daher auf strikte, unveränderliche Lockdateien stützen, dieses Verhalten in CI durchsetzen und die Lockdateien mit Tools schützen, die die Herkunft der Pakete überprüfen. Deterministische Installationen dienen nicht nur der Reproduzierbarkeit. Im Ernstfall muss sich auch die Frage beantworten lassen: „Welchen Code haben wir ausgeführt, und woher stammt er?“

Drittens müssen Schwachstellen und Zustandsindikatoren für Abhängigkeiten als kontinuierlicher Datenstrom behandelt werden, nicht als gelegentlicher Bericht. Solche Vorfälle entwickeln sich schneller als die herkömmliche Veröffentlichung von CVEs. Ihre Schutzmaßnahmen müssen daher Schwachstellendatenbanken, Malware-Warnungen, Provenance-Attestierungen, Signale zu Alter und Beliebtheit von Paketen sowie automatisierte Upgrade-Richtlinien mit integrierten Cooldown-Zeiträumen kombinieren. Dazu gehören Sicherheitsprüfungen bei der Installation, automatisierte Pull Requests, die sehr neue Releases vermeiden, und Tools, die zwischen einer kleinen Fehlerbehebung und einer nicht vertrauenswürdigen, bisher unbekannten Paketversion unterscheiden können.

Und schließlich geht es bei wirksamer npm-Sicherheit nicht nur um die Installation von Abhängigkeiten. Entscheidend sind auch der Aufbau Ihrer lokalen Entwicklungsumgebung, der Umgang mit Secrets sowie die Veröffentlichung und Pflege Ihrer eigenen Pakete. Gehärtete Entwicklungscontainer begrenzen den möglichen Schaden, wenn ein schädliches Paket entdeckt wird. Ich empfehle, keine Secrets im Klartext in Ihren Umgebungsvariablen zu verwenden. Wenn Sie Klartext-.env-Dateien durch die bedarfsgesteuerte Bereitstellung von Secrets ersetzen, können Angreifer weniger stehlen, selbst wenn sie Code ausführen können. Mit 2FA, vertrauenswürdiger Veröffentlichung über OIDC und Provenance-Attestierungen für Ihre eigenen npm-Pakete erschweren Sie es Angreifern, Ihre Identität im Ökosystem zu übernehmen.

Mit Snyk sicher bleiben

Snyk beobachtet die Lage rund um Shai-Hulud genau und veröffentlicht regelmäßig Updates über die Plattform. Stand gestern (24. November) haben wir bereits mehr als 800 schädliche Pakete erfasst.

Im Folgenden finden Sie einige Ressourcen, mit denen Sie die Kontrolle über den aktuellen Vorfall verbessern und sich auf den nächsten vorbereiten können.

Liste der kompromittierten Shai-Hulud-Pakete

Snyk führt eine öffentliche Webseite mit einer Liste schädlicher Shai-Hulud-Pakete, die mit der Malware-Kampagne in Verbindung stehen:

Snyk Zero-Day-Berichte

Wenn Sie Ihre Repositories mit Snyk verbinden oder sie auf andere Weise überwachen, erhalten Sie einen Überblick über Ihren Bestand. Damit können Sie verschiedene Aspekte Ihrer Abhängigkeiten einfach nachverfolgen und beispielsweise Ihre gesamte F&E-Organisation daraufhin überprüfen, ob sie von der Shai-Hulud-Malware betroffen ist.

Um herauszufinden, ob Sie von diesem Vorfall betroffen sind, rufen Sie „Reports“ > „Featured Zero-Day Report“ auf. Weitere Informationen zu dieser Funktion finden Sie in unseren User Docs.

Die folgenden Screenshots zeigen, wo Sie den Bericht in der Snyk-Benutzeroberfläche finden (hier ist der vorherige Shai-Hulud-npm-Supply-Chain-Angriff vom September 2025 zu sehen). Der neue Bericht heißt SHA1-Hulud npm Supply Chain Attack - Nov 2025:

Überwachen Sie Ihre Abhängigkeiten mit Snyk

Wer Open-Source-Softwarebibliotheken nutzt, muss diese kontinuierlich überwachen und Sicherheitsupdates im Blick behalten. Das gilt sowohl für CVE-Schwachstellen als auch für Malware-Kampagnen und für den gesamten Abhängigkeitsbaum – direkte wie indirekte Abhängigkeiten – in Ihrer gesamten Organisation.

Mit Snyk können Sie Ihre Git-Repositories verbinden und mit Snyk Open Source als SCA-Tool Open-Source-Risiken für JavaScript-Projekte proaktiv kontrollieren. Außerdem können und sollten Sie eine SBOM pflegen, die Snyk standardmäßig für Sie bereitstellt.

Wir empfehlen Ihnen außerdem, sich schon heute auf die Zero-Day-Schwachstellen von morgen vorzubereiten.