Blog

NPM Abhängigkeiten sichern: Supply Chain Security Guide für API Entwickler

Ashley Innocent

Ashley Innocent

1 April 2026

NPM Abhängigkeiten sichern: Supply Chain Security Guide für API Entwickler

Apidog für Unternehmen

On-Premises-Bereitstellung

SSO & RBAC

SOC 2 konform

Apidog Enterprise entdecken

TL;DR

NPM-Supply-Chain-Angriffe stiegen allein im Jahr 2024 auf über 3.000 bösartige Pakete an, und die Axios-Kompromittierung im März 2026 bewies, dass selbst Top-10-Pakete nicht sicher sind. Dieser Leitfaden behandelt jede Verteidigungsschicht, die API-Entwickler benötigen: Lockfile-Durchsetzung, Blockierung von Postinstall-Skripten, Provenienzverifizierung, Tools zur Verhaltensanalyse und architektonische Entscheidungen, die Ihre Angriffsfläche verkleinern.

Einleitung

Der Axios-Supply-Chain-Angriff vom 31. März 2026 war nicht die erste npm-Kompromittierung. Und es wird nicht die letzte sein. Aber mit 83 Millionen wöchentlichen Downloads und einem plattformübergreifenden RAT, das über ein einziges gekapertes Maintainer-Konto bereitgestellt wurde, war es der lauteste Weckruf, den das JavaScript-Ökosystem erhalten hat.

Was diesen Fall vom üblichen Ratschlag „Aktualisieren Sie Ihre Abhängigkeiten“ unterscheidet: Der Axios-Angriff umging jede traditionelle Verteidigung. Der bösartige Code befand sich nicht in Axios selbst. Er wurde über eine Phantom-Abhängigkeit eingeschleust, die einen Postinstall-Hook auslöste. Lockfiles halfen nicht, wenn Sie npm install während des Angriffsfensters ausführten. Versions-Pinning half nicht, wenn Sie noch nicht gepinnt hatten.

API-Entwickler sind besonders gefährdet. Ihre Testskripte, CI/CD-Pipelines, Mock-Server und HTTP-Clients beziehen alle Pakete von npm. Ein einziges kompromittiertes Paket in Ihrer Toolchain kann API-Schlüssel, Datenbank-Anmeldeinformationen und Cloud-Token von Ihrem Entwicklungsrechner preisgeben.

💡
Apidog eliminiert einen wichtigen Angriffsvektor, indem es einen integrierten HTTP-Client für API-Tests bereitstellt, sodass Sie Axios, node-fetch oder got nicht in Ihrem Test-Stack benötigen. Laden Sie Apidog kostenlos herunter, um Ihre npm-Abhängigkeitsoberfläche zu reduzieren und gleichzeitig die unten stehenden Verteidigungsstrategien zu befolgen.
button

Dieser Leitfaden behandelt sieben Schutzschichten, von der grundlegenden Lockfile-Hygiene bis zur fortgeschrittenen Verhaltensanalyse.

Schicht 1: Lockfile-Durchsetzung

Warum Lockfiles wichtig sind

Eine Lockfile zeichnet die genaue Version jedes Pakets und jeder transitiven Abhängigkeit zum Zeitpunkt der Installation auf. Ohne eine Lockfile löst npm install die neueste Version auf, die Ihrem Semver-Bereich entspricht. Wenn Ihre package.json "axios": "^1.14.0" angibt und eine bösartige Version 1.14.1 im Registry existiert, erhalten Sie die bösartige Version.

Die Regeln

Committen Sie Ihre Lockfile immer. Ob es package-lock.json (npm), yarn.lock (Yarn), pnpm-lock.yaml (pnpm) oder bun.lock (Bun) ist, sie gehört in die Versionskontrolle.

Verwenden Sie eingefrorene Installationen in CI/CD. Führen Sie niemals npm install in automatisierten Umgebungen aus. Verwenden Sie das Äquivalent für eine eingefrorene Lockfile:

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile

npm ci löscht node_modules und installiert strikt gemäß der Lockfile. Wenn die Lockfile nicht mit package.json übereinstimmt, schlägt der Vorgang fehl. Dies verhindert Überraschungen bei der Auflösung.

Überprüfen Sie Lockfile-Diffe in Pull Requests. Wenn ein PR die package-lock.json ändert, prüfen Sie, was sich geändert hat. Neue Abhängigkeiten, Versionssprünge und Änderungen der Registry-URL verdienen alle eine genaue Prüfung. Automatisierte Tools wie Socket.dev können verdächtige Lockfile-Änderungen in PR-Reviews markieren.

Die Lockfile-Lücke

Lockfiles schützen vor unerwarteter Versionsauflösung, aber sie schützen nicht vor der Erstinstallation. Wenn Sie ein Projekt initialisieren oder eine neue Abhängigkeit während eines Angriffsfensters hinzufügen, wird die bösartige Version festgeschrieben. Deshalb sind Lockfiles Schicht 1, nicht die einzige Schicht.

Schicht 2: Postinstall-Skripte deaktivieren

Der primäre Angriffsvektor

Der Axios-Angriff, der ua-parser-js-Angriff, der event-stream-Angriff und Dutzende andere nutzten alle denselben Mechanismus: ein postinstall-Skript, das beliebigen Code während npm install ausführt. Dieser Hook wird ausgeführt, bevor Ihr Anwendungscode läuft, bevor Sie das Paket überprüfen und bevor jedes Laufzeit-Sicherheitstool eingreifen kann.

Skripte global blockieren

Fügen Sie Ihrer .npmrc hinzu:

ignore-scripts=true

Oder stellen Sie es über die CLI ein:

npm config set ignore-scripts true

Dies verhindert, dass alle Lebenszyklus-Skripte (preinstall, install, postinstall, prepare) während der Paketinstallation ausgeführt werden.

Pakete handhaben, die Skripte benötigen

Einige Pakete erfordern Postinstall-Skripte für die native Kompilierung (wie bcrypt, sharp oder sqlite3). Sie haben zwei Optionen:

Option 1: Skripte selektiv nach der Installation ausführen

npm ci --ignore-scripts
npm rebuild bcrypt sharp

Option 2: Eine Allowlist verwenden (npm 10+)

Erstellen Sie eine .scriptsrc.json, die nur vertrauenswürdigen Paketen das Ausführen von Skripten erlaubt:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}

Option 3: Vorkompilierte Binärdateien verwenden

Viele Pakete, die zuvor eine native Kompilierung benötigten, bieten jetzt vorkompilierte Binärdateien an. sharp liefert beispielsweise vorkompilierte Binärdateien für die meisten Plattformen, wodurch die Notwendigkeit einer Postinstall-Kompilierung entfällt. Überprüfen Sie Ihre Abhängigkeiten; möglicherweise benötigen Sie weniger Skriptausnahmen, als Sie denken.

Der PackageGate-Vorbehalt

Im Januar 2026 legten Forscher sechs Zero-Day-Schwachstellen namens „PackageGate“ offen, die npm, pnpm, vlt und Bun betreffen. Eine Erkenntnis: Git-basierte Abhängigkeiten können Konfigurationsdateien enthalten, die die Codeausführung ermöglichen, selbst wenn Lebenszyklus-Skripte deaktiviert sind. Wenn Ihre package.json Git-URLs für Abhängigkeiten referenziert, reicht ignore-scripts allein nicht aus. Pinnen Sie diese Abhängigkeiten an bestimmte Commit-Hashes und überprüfen Sie den Repository-Inhalt.

Schicht 3: Exakte Versionen pinnen

Verwenden Sie keine Semver-Bereiche mehr

Das Standardverhalten von npm install --save fügt Pakete mit einem Caret-Präfix hinzu:

{
  "axios": "^1.14.0"
}

Das ^ bedeutet „kompatibel mit 1.14.0“, was zur neuesten 1.x.x-Version auflöst. Während des Axios-Angriffs bedeutete dies die Auflösung auf 1.14.1.

Pinnen Sie stattdessen exakte Versionen:

{
  "axios": "1.14.0"
}

Konfigurieren Sie npm so, dass standardmäßig exakte Versionen gespeichert werden:

# .npmrc
save-exact=true
save-prefix=''

Overrides für transitive Abhängigkeiten verwenden

Ihre direkten Abhängigkeiten haben ihre eigenen Abhängigkeiten. Wenn eine transitive Abhängigkeit kompromittiert wird, hilft das Pinnen Ihrer direkten Abhängigkeit nicht. Verwenden Sie Overrides, um die transitive Auflösung zu steuern:

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}

Für Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

Für pnpm:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}

Der Kompromiss

Exaktes Pinnen bedeutet, dass Sie keine automatischen Patch-Updates erhalten. Sie müssen Versionen manuell aktualisieren, was Wartungsaufwand verursacht. Dieser Kompromiss ist bewusst: Sie wählen kontrollierte Updates gegenüber automatischen. Für sicherheitssensible Projekte ist dieser Kompromiss es wert.

Schicht 4: Paketprovenienz überprüfen

Was Provenienz bedeutet

Die npm-Provenienzattestierung verknüpft ein veröffentlichtes Paket mit seinem Quellcode und der Build-Umgebung unter Verwendung von Sigstore-Signaturen, die in einem öffentlichen Transparenz-Ledger protokolliert sind. Wenn ein Paket aus einer CI/CD-Pipeline mit aktivierter Provenienz veröffentlicht wird, enthält das Paket kryptographische Nachweise für:

Wie man die Provenienz prüft

npm audit signatures

Dies überprüft, ob installierte Pakete gültige Provenienzattestierungen haben. Pakete, die manuell von einem Entwicklerrechner veröffentlicht wurden, haben keine Provenienz.

Den bösartigen Axios-Versionen fehlte die OIDC-Provenienzbindung und sie hatten keine entsprechenden GitHub-Commits. Wäre eine automatisierte Provenienzprüfung Standardpraxis gewesen, hätte der Angriff sofort Warnsignale ausgelöst.

Provenienz für eigene Pakete aktivieren

Wenn Sie npm-Pakete veröffentlichen, aktivieren Sie die Provenienz in Ihrer CI/CD:

# GitHub Actions example
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Fügen Sie Ihrer .npmrc hinzu:

provenance=true

Einschränkungen

Provenienz ist Opt-in. Die meisten npm-Pakete haben sie noch nicht. Und Provenienz beweist nur, wo ein Paket gebaut wurde. Sie beweist nicht, dass der Quellcode sicher ist. Eine kompromittierte CI/CD-Pipeline könnte ein bösartiges Paket mit gültiger Provenienz veröffentlichen.

Schicht 5: Tools zur Verhaltensanalyse verwenden

Jenseits des Schwachstellen-Scannings

Traditionelle Tools wie npm audit und Snyk prüfen gegen Datenbanken bekannter Schwachstellen (CVEs). Sie erfassen gemeldete Probleme, übersehen jedoch Zero-Day-Angriffe. Die Axios-Kompromittierung befand sich zum Zeitpunkt ihrer Veröffentlichung in keiner CVE-Datenbank.

Tools zur Verhaltensanalyse untersuchen, was Pakete tun, nicht, was über sie berichtet wurde.

Socket.dev

Socket analysiert das Paketverhalten während der Installation und Laufzeit. Es kennzeichnet:

Bei der Integration mit GitHub kommentiert Socket PRs, wenn neue Abhängigkeiten verdächtiges Verhalten zeigen. Die plain-crypto-js-Abhängigkeit des Axios-Angriffs hätte mehrere Socket-Alarme ausgelöst: verschleierter Code, Netzwerkanfragen während des Postinstall und Dateisystemzugriffe außerhalb des Paketverzeichnisses.

# Install Socket CLI
npm install -g @socketsecurity/cli

# Scan your project
socket scan

Snyk

Snyk bietet Schwachstellenmanagement mit Risikobewertungen, Exploit-Reifegrad-Daten und Anleitungen zur Behebung. Es ist stärker bei bekannten Schwachstellen, aber schwächer bei der Zero-Day-Verhaltenserkennung.

# Install Snyk CLI
npm install -g snyk

# Test your project
snyk test

Geschichteter Ansatz

Verwenden Sie beide. Socket erfasst Verhaltensanomalien, die Snyk übersieht. Snyk erfasst bekannte Schwachstellen mit einem reichhaltigeren Kontext, als Socket bietet. Fügen Sie npm audit als Basislinie hinzu:

# Baseline
npm audit

# Behavioral analysis
socket scan

# Vulnerability management
snyk test

Führen Sie alle drei in CI/CD als Gates aus. Jeder kritische Befund sollte den Build blockieren.

Schicht 6: Minimieren Sie Ihre Abhängigkeitsoberfläche

Die tiefere Frage

Jedes Paket in Ihren node_modules ist eine Vertrauensentscheidung. Der Axios-Angriff kompromittierte ein Paket mit 83 Millionen wöchentlichen Downloads. Das durchschnittliche Node.js-Projekt hat Hunderte von transitiven Abhängigkeiten. Jede einzelne ist ein potenzieller Angriffsvektor.

Die effektivste Verteidigung besteht darin, weniger Abhängigkeiten verteidigen zu müssen.

Überprüfen Sie Ihren Abhängigkeitsbaum

# Count your total dependencies
npm ls --all | wc -l

# Check for duplicates
npm ls --all | sort | uniq -c | sort -rn | head -20

Stellen Sie sich diese Fragen für jede Abhängigkeit:

Native Alternativen für gängige Pakete

Paket Native Alternative Verfügbar seit
axios, node-fetch, got fetch (global) Node.js 18
uuid crypto.randomUUID() Node.js 19
dotenv --env-file Flag Node.js 20.6
chalk util.styleText() Node.js 21.7
glob fs.glob() Node.js 22
path-to-regexp Native URL-Pattern-API Node.js 23

Speziell für API-Tests

API-Test-Workflows hängen üblicherweise von HTTP-Client-Bibliotheken, Assertions-Bibliotheken, Test-Runnern und Mock-Servern ab. Jede Abhängigkeit ist eine Angriffsfläche.

Apidog ersetzt den gesamten Stack durch eine einzige Plattform:

Die Verlagerung Ihres API-Test-Workflows in Apidog eliminiert Dutzende von npm-Abhängigkeiten aus Ihrer Testinfrastruktur. Weniger Abhängigkeiten bedeuten weniger Vertrauensentscheidungen und weniger Angriffsvektoren.

Testen Sie Apidog kostenlos, um Ihren API-Test-Stack zu konsolidieren.

button

Schicht 7: Netzwerk- und Laufzeitüberwachung

Bekannte schädliche Domains blockieren

Blockieren Sie nach jedem Supply-Chain-Angriff die Command-and-Control-Infrastruktur auf Netzwerkebene:

# Add to /etc/hosts
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

Beschränken Sie in CI/CD-Umgebungen den ausgehenden Netzwerkzugriff auf bekannte, vertrauenswürdige Domains. Die meisten Build-Prozesse benötigen nur Zugriff auf die npm-Registry, Ihren Git-Host und Ihre Bereitstellungsziele. Alles andere sollte standardmäßig blockiert werden.

Verwenden Sie StepSecurity Harden-Runner für CI/CD

StepSecuritys Harden-Runner überwacht GitHub Actions-Workflows in Echtzeit. Er erkannte, wie der Axios-Dropper innerhalb von 1,1 Sekunden nach dem Start von npm install Kontakt zu C2 aufnahm. Das Tool bietet:

# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # or 'block' for strict mode

Laufzeit-Prozessüberwachung

Für Entwicklungsrechner sollten Sie Endpunkt-Erkennungs- und Reaktions-Tools (EDR) in Betracht ziehen, die verdächtige von Node.js gestartete Kindprozesse kennzeichnen. Der Axios-RAT startete osascript (macOS), cscript (Windows) und python3 (Linux) innerhalb des npm-Installationsprozesses. Diese Kindprozessmuster sind erkennbar.

Empfohlene .npmrc-Konfiguration

Hier ist eine sicherheitsgehärtete .npmrc-Datei, die die oben genannten Schichten kombiniert:

# Pin exact versions
save-exact=true
save-prefix=

# Disable lifecycle scripts
ignore-scripts=true

# Enable provenance for publishing
provenance=true

# Use the official registry
registry=https://registry.npmjs.org/

# Require 2FA for publishing
auth-type=web

# Audit level threshold
audit-level=moderate

Committen Sie diese Datei in Ihr Repository, damit jedes Teammitglied dieselben Sicherheitseinstellungen verwendet.

Beispiel für eine CI/CD-Sicherheitspipeline

Hier ist ein GitHub Actions-Workflow, der alle sieben Schichten durchsetzt:

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit  # or 'block' for strict mode

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # Schicht 1+2: Eingefrorene Lockfile, keine Skripte
      - run: npm ci --ignore-scripts

      # Schicht 3: Überprüfen Sie, dass keine unerwarteten Versionen vorhanden sind
      - run: npm ls --all > deps.txt

      # Schicht 4: Provenienz prüfen
      - run: npm audit signatures

      # Schicht 5: Verhaltensanalyse
      - run: npx socket scan

      # Schicht 5: Schwachstellenscan
      - run: npx snyk test

      # Schicht 1: Basislinienprüfung
      - run: npm audit --audit-level=moderate

      # Nur zugelassene native Abhängigkeiten neu erstellen
      - run: npm rebuild sharp bcrypt

Was kommt als Nächstes für die npm-Sicherheit

Obligatorische Provenienz für beliebte Pakete

npm diskutiert die Einführung einer obligatorischen Provenienzattestierung für Pakete oberhalb einer bestimmten Download-Schwelle. Dies würde die manuelle, Token-basierte Veröffentlichung verhindern, die den Axios-Angriff ermöglichte.

Zwei-Personen-Freigabeprinzip

Ähnlich wie bei Finanztransaktionen, die eine doppelte Autorisierung erfordern, könnten Pakete mit hoher Downloadzahl einen zweiten Maintainer zur Genehmigung von Releases benötigen. Ein einzelnes kompromittiertes Konto wäre nicht ausreichend.

Laufzeit-Berechtigungsumfang

Deno schränkt bereits ein, worauf Skripte zugreifen können (Netzwerk, Dateisystem, Umgebungsvariablen), es sei denn, es wird explizit gewährt. Node.js erforscht ähnliche Berechtigungsmodelle. Wenn dies veröffentlicht wird, bräuchten Postinstall-Skripte explizite Erlaubnis, um Netzwerkanfragen zu stellen oder auf das Dateisystem zuzugreifen.

Konvergenz der Paketmanager

pnpms striktes Isolationsmodell (Pakete können nur auf ihre deklarierten Abhängigkeiten zugreifen) verhindert viele Dependency-Confusion-Angriffe. Wenn npm eine ähnliche Strenge annimmt, schrumpft die Angriffsfläche.

FAQ

Was ist ein Supply-Chain-Angriff in npm?

Ein Supply-Chain-Angriff in npm zielt auf die Software-Abhängigkeitskette statt direkt auf Ihre Anwendung. Angreifer kompromittieren Paket-Maintainer-Konten, injizieren bösartigen Code in beliebte Pakete oder veröffentlichen Typosquat-Pakete mit ähnlichen Namen. Wenn Sie Abhängigkeiten installieren oder aktualisieren, wird der bösartige Code auf Ihrem Rechner oder in Ihrer CI/CD-Pipeline ausgeführt, stiehlt Anmeldeinformationen, installiert Backdoors oder exfiltriert Daten.

Ist npm audit ausreichend, um vor Supply-Chain-Angriffen zu schützen?

Nein. npm audit prüft gegen eine Datenbank bekannter Schwachstellen (CVEs). Zero-Day-Angriffe wie die Axios-Kompromittierung befinden sich zum Zeitpunkt ihres Auftretens in keiner CVE-Datenbank. Sie benötigen Tools zur Verhaltensanalyse wie Socket.dev, die untersuchen, was Pakete tun, nicht, was über sie berichtet wurde. Verwenden Sie npm audit als Basislinie, nicht als einzige Verteidigung.

Sollte ich npm komplett aufhören zu verwenden?

Nein. npm bleibt das größte Paket-Ökosystem, und die meisten Pakete sind sicher. Ziel ist es, Ihre Gefährdung durch exaktes Versions-Pinning, Lockfile-Durchsetzung, Skriptblockierung und Abhängigkeitsminimierung zu reduzieren. Prüfen Sie, ob jede Abhängigkeit notwendig ist, und verwenden Sie nach Möglichkeit native Alternativen.

Wie hilft Apidog, das npm-Supply-Chain-Risiko zu reduzieren?

Apidog bietet einen integrierten HTTP-Client, Test-Runner, Mock-Server und Dokumentationsgenerator für die API-Entwicklung. Dies eliminiert die Notwendigkeit für npm-Pakete wie Axios, node-fetch, Jest, Express (für Mocks) und andere Test-Abhängigkeiten. Weniger npm-Abhängigkeiten bedeuten weniger Angriffsvektoren in Ihrem API-Entwicklungsworkflow.

Was ist Paketprovenienz in npm?

Paketprovenienz verwendet Sigstore, um ein veröffentlichtes Paket kryptographisch mit seinem Quell-Repository und der CI/CD-Build-Umgebung zu verknüpfen. Es beweist, wo und wie ein Paket gebaut wurde. Sie können die Provenienz mit npm audit signatures überprüfen. Paketen, die manuell von Entwicklerrechnern veröffentlicht wurden, fehlt die Provenienz, was bei Paketen mit hoher Downloadzahl ein Warnsignal ist.

Wie viele npm-Pakete sind bösartig?

Snyk identifizierte im Jahr 2024 über 3.000 bösartige npm-Pakete. Bis zum vierten Quartal 2025 blockierte Sonatype 120.612 Malware-Angriffe in einem einzigen Quartal über npm, PyPI und andere Registries hinweg. Die Zahl wächst. Die meisten bösartigen Pakete sind Typosquats mit geringer Downloadzahl, aber hochkarätige Kompromittierungen wie Axios beweisen, dass beliebte Pakete nicht immun sind.

Was ist die PackageGate-Schwachstelle?

PackageGate ist eine Reihe von sechs Zero-Day-Schwachstellen, die im Januar 2026 offengelegt wurden und npm, pnpm, vlt und Bun betreffen. Eine Erkenntnis zeigt, dass Git-basierte Abhängigkeiten Konfigurationsdateien enthalten können, die die Codeausführung ermöglichen, selbst wenn Lebenszyklus-Skripte deaktiviert sind. Dies bedeutet, dass ignore-scripts allein nicht ausreicht, wenn Ihre Abhängigkeiten Git-Repositories referenzieren. Pinnen Sie Git-Abhängigkeiten an bestimmte Commit-Hashes.

Wichtige Erkenntnisse

Jede Abhängigkeit ist eine Vertrauensentscheidung. Je weniger Abhängigkeiten Sie haben, desto kleiner ist Ihre Angriffsfläche. Je mehr Verifizierungsschichten Sie anwenden, desto schwieriger wird es für einen Angreifer, sich durchzuschleichen. Bauen Sie Ihre Verteidigung in der Tiefe auf, nicht isoliert.

button

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen

Kostenlos registrierenDownload