DEV Community

Cover image for NPM Abhängigkeiten sichern: Supply Chain Security Guide für API Entwickler
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

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

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.

Teste Apidog noch heute

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.

💡 Tipp:

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.

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 exakte Version jedes Pakets und jeder transitiven Abhängigkeit zum Installationszeitpunkt auf. Ohne Lockfile löst npm install die jeweils neueste Version im Semver-Bereich auf. Beispiel: Ihre package.json enthält "axios": "^1.14.0" und eine bösartige Version 1.14.1 existiert – Sie erhalten die bösartige Version.

Die Regeln

1. Committen Sie Ihre Lockfile immer.

Egal ob package-lock.json (npm), yarn.lock (Yarn), pnpm-lock.yaml (pnpm) oder bun.lock (Bun): Gehört in die Versionskontrolle.

2. Verwenden Sie eingefrorene Installationen in CI/CD.

Führen Sie niemals npm install in automatisierten Umgebungen aus. Nutzen Sie:

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile
Enter fullscreen mode Exit fullscreen mode

npm ci löscht node_modules und installiert exakt nach Lockfile. Ein Mismatch mit package.json bricht den Build ab.

3. Überprüfen Sie Lockfile-Diffs in Pull Requests.

Jede Änderung an der Lockfile im PR muss geprüft werden: Neue Abhängigkeiten, Versionssprünge, Registry-URL-Änderungen. Tools wie Socket.dev markieren verdächtige Lockfile-Änderungen automatisch.

Die Lockfile-Lücke

Lockfiles schützen vor unerwarteter Versionsauflösung, aber nicht vor der Erstinstallation. Initialisieren Sie ein neues Projekt oder fügen Sie während eines Angriffsfensters eine Abhängigkeit hinzu, wird die bösartige Version festgeschrieben. Lockfiles sind Schicht 1, nicht die einzige Schicht.

Schicht 2: Postinstall-Skripte deaktivieren

Der primäre Angriffsvektor

Der Axios-Angriff, ua-parser-js, event-stream und viele andere nutzten denselben Mechanismus: Ein postinstall-Skript, das während npm install beliebigen Code ausführt – noch bevor Ihr Anwendungscode läuft.

Skripte global blockieren

Fügen Sie Ihrer .npmrc hinzu:

ignore-scripts=true
Enter fullscreen mode Exit fullscreen mode

Oder per CLI:

npm config set ignore-scripts true
Enter fullscreen mode Exit fullscreen mode

Das blockiert alle Lebenszyklus-Skripte (preinstall, install, postinstall, prepare) während der Installation.

Pakete handhaben, die Skripte benötigen

Einige Pakete (z.B. bcrypt, sharp, sqlite3) benötigen Postinstall-Skripte. Sie haben drei Optionen:

Option 1: Skripte selektiv nach der Installation ausführen

npm ci --ignore-scripts
npm rebuild bcrypt sharp
Enter fullscreen mode Exit fullscreen mode

Option 2: Allowlist mit npm 10+

Legen Sie .scriptsrc.json an:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}
Enter fullscreen mode Exit fullscreen mode

Option 3: Vorkompilierte Binärdateien nutzen

Viele Pakete (z.B. sharp) liefern vorkompilierte Binärdateien, wodurch Postinstall überflüssig wird.

Der PackageGate-Vorbehalt

Im Januar 2026 wurden sechs Zero-Day-Schwachstellen ("PackageGate") aufgedeckt: Git-basierte Abhängigkeiten können trotz deaktivierter Lebenszyklus-Skripte Code ausführen. Pinnen Sie Git-Abhängigkeiten auf feste Commit-Hashes und prüfen Sie den Repository-Inhalt.

Schicht 3: Exakte Versionen pinnen

Verwenden Sie keine Semver-Bereiche mehr

Standardmäßig wird ein Paket mit Caret-Präfix gespeichert:

{
  "axios": "^1.14.0"
}
Enter fullscreen mode Exit fullscreen mode

Das ^ löst auf die jeweils neueste 1.x.x auf. Während eines Angriffs riskant!

Besser: Exakte Versionen pinnen:

{
  "axios": "1.14.0"
}
Enter fullscreen mode Exit fullscreen mode

Konfigurieren Sie npm:

# .npmrc
save-exact=true
save-prefix=''
Enter fullscreen mode Exit fullscreen mode

Overrides für transitive Abhängigkeiten verwenden

Steuern Sie auch die Auflösung transitiver Abhängigkeiten:

npm:

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

Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

pnpm:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Der Kompromiss

Exaktes Pinnen bedeutet: Keine automatischen Patch-Updates. Sie müssen manuell aktualisieren – aber behalten so die Kontrolle. Für sicherheitskritische Projekte ist das sinnvoll.

Schicht 4: Paketprovenienz überprüfen

Was Provenienz bedeutet

Die npm-Provenienzattestierung verknüpft ein veröffentlichtes Paket mit Quellcode & Build-Umgebung über Sigstore-Signaturen im öffentlichen Transparenz-Ledger:

  • Welches Quell-Repository?
  • Welches CI/CD-System?
  • Welcher Commit?

Provenienz prüfen 

npm audit signatures
Enter fullscreen mode Exit fullscreen mode

Damit sehen Sie, ob installierte Pakete gültige Provenienzattestierungen enthalten. Fehlt die OIDC-Provenienzbindung (wie bei den bösartigen Axios-Versionen): Warnsignal!

Provenienz für eigene Pakete aktivieren

Für eigene npm-Pakete in CI/CD:

# GitHub Actions Beispiel
- 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 }}
Enter fullscreen mode Exit fullscreen mode

In .npmrc:

provenance=true
Enter fullscreen mode Exit fullscreen mode

Einschränkungen

Provenienz ist Opt-in. Die meisten Pakete haben sie noch nicht. Provenienz beweist nur, wo ein Paket gebaut wurde – nicht, dass der Quellcode sicher ist!

Schicht 5: Tools zur Verhaltensanalyse verwenden

Jenseits des Schwachstellen-Scannings

Tools wie npm audit und Snyk prüfen gegen bekannte CVEs, aber nicht gegen Zero-Day-Angriffe. Tools zur Verhaltensanalyse schauen, was Pakete tatsächlich tun.

Socket.dev

Socket analysiert Paketverhalten bei Installation/Laufzeit:

  • Netzwerkanfragen während Installation
  • Dateisystemzugriffe außerhalb des Paketverzeichnisses
  • Ausführen von Shell-Befehlen
  • Erfassen von Umgebungsvariablen
  • Verschleierter Code

Socket Screenshot

Integration: Socket kommentiert PRs bei verdächtigen neuen Abhängigkeiten.

Nutzung:

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

# Projekt scannen
socket scan
Enter fullscreen mode Exit fullscreen mode

Snyk

Snyk liefert Schwachstellenmanagement, Exploit-Reifegrad-Daten und Fix-Anleitungen. Gut bei bekannten Schwachstellen, weniger bei unbekannten.

# Snyk CLI installieren
npm install -g snyk

# Projekt testen
snyk test
Enter fullscreen mode Exit fullscreen mode

Snyk Screenshot

Geschichteter Ansatz

Beides nutzen!

Socket für Verhaltensanomalien, Snyk für bekannte Schwachstellen, npm audit als Basis:

# Basislinie
npm audit

# Verhaltensanalyse
socket scan

# Schwachstellenmanagement
snyk test
Enter fullscreen mode Exit fullscreen mode

Alle drei Checks in CI/CD als Gates einbauen. Kritische Funde blockieren den Build.

Schicht 6: Minimieren Sie Ihre Abhängigkeitsoberfläche

Die tiefere Frage

Jede Abhängigkeit in node_modules ist eine Vertrauensentscheidung. Der Axios-Angriff zeigte: Selbst Top-Pakete sind nicht immun. Reduzieren Sie die Gesamtzahl Ihrer Pakete – jede Reduktion verringert die Angriffsfläche.

Abhängigkeitsbaum prüfen 

# Abhängigkeiten zählen
npm ls --all | wc -l

# Doppelte Pakete ermitteln
npm ls --all | sort | uniq -c | sort -rn | head -20
Enter fullscreen mode Exit fullscreen mode

Checkliste für jede Abhängigkeit:

  • Gibt es eine native Alternative in Node.js?
  • Zieht das Paket viele (transitive) Abhängigkeiten nach sich?
  • Kann ich den Code stattdessen direkt ins Projekt kopieren (vendoring)?

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 nutzen oft HTTP-Clients, Assertions-Bibliotheken, Test-Runner und Mock-Server – jede Abhängigkeit ein Angriffsvektor.

Test-Stack

Apidog ersetzt diesen Stack durch eine einzige Plattform:

  • HTTP-Client: Integriert, keine npm-Abhängigkeit
  • Assertions: Visueller Test-Builder
  • Test-Runner: Automatisierte Szenarien mit CI/CD-Integration via Apidog CLI
  • Mock-Server: Smarte Mocks, keine Express- oder Drittanbieter-Bibliotheken
  • Dokumentation: Automatisch generiert

Verschieben Sie Ihren API-Test-Workflow in Apidog und eliminieren Sie Dutzende npm-Abhängigkeiten.

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

Schicht 7: Netzwerk- und Laufzeitüberwachung

Bekannte schädliche Domains blockieren

Blockieren Sie nach Supply-Chain-Vorfällen die C2-Infrastruktur auf Netzwerkebene:

# In /etc/hosts eintragen
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
Enter fullscreen mode Exit fullscreen mode

Beschränken Sie in CI/CD den ausgehenden Netzwerkzugriff auf notwendige Domains (npm-Registry, Git, Deploy-Ziele). Alles andere blockieren.

StepSecurity Harden-Runner für CI/CD nutzen

StepSecuritys Harden-Runner überwacht GitHub Actions-Workflows in Echtzeit und erkennt z.B. C2-Verbindungen direkt nach npm install:

  • Überwachung ausgehender Netzwerke
  • Prozessverfolgung
  • Dateintegrität
  • Automatische Warnungen 
# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # oder 'block' für strikten Modus
Enter fullscreen mode Exit fullscreen mode

Laufzeit-Prozessüberwachung

Für Dev-Rechner empfiehlt sich EDR (Endpoint Detection & Response), das Node.js-Kindprozesse überwacht. Der Axios-RAT startete Prozesse wie osascript, cscript, python3 – diese Muster sind erkennbar.

Empfohlene .npmrc-Konfiguration

Eine sicherheitsgehärtete .npmrc-Datei:

# Exakte Versionen pinnen
save-exact=true
save-prefix=

# Lebenszyklus-Skripte deaktivieren
ignore-scripts=true

# Provenienz für Veröffentlichungen aktivieren
provenance=true

# Offizielle Registry erzwingen
registry=https://registry.npmjs.org/

# 2FA für Veröffentlichungen verlangen
auth-type=web

# Audit-Level-Schwelle
audit-level=moderate
Enter fullscreen mode Exit fullscreen mode

Committen Sie diese Datei ins Repository.

Beispiel für eine CI/CD-Sicherheitspipeline

GitHub Actions-Workflow, der alle sieben Schichten abdeckt:

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  # oder 'block' für strikten Modus

      - 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 auf unerwartete Versionen
      - 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 bauen
      - run: npm rebuild sharp bcrypt
Enter fullscreen mode Exit fullscreen mode

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

Obligatorische Provenienz für beliebte Pakete

npm diskutiert verpflichtende Provenienzattestierung ab einer bestimmten Download-Schwelle – verhindert manuelle, Token-basierte Veröffentlichungen wie beim Axios-Angriff.

Zwei-Personen-Freigabeprinzip

Pakete mit hoher Downloadzahl könnten eine doppelte Autorisierung für Releases erfordern – ein kompromittiertes Konto reicht nicht mehr.

Laufzeit-Berechtigungsumfang

Deno beschränkt schon heute Netzwerk-, Dateisystem- und Env-Zugriffe von Skripten. Node.js experimentiert mit ähnlichen Modellen. Postinstall-Skripte müssten explizit berechtigt werden.

Konvergenz der Paketmanager

pnpms Isolationsmodell verhindert viele Dependency-Confusion-Angriffe. Nimmt npm ähnliche Strenge an, schrumpft die Angriffsfläche weiter.

FAQ

Was ist ein Supply-Chain-Angriff in npm?

Ein Supply-Chain-Angriff zielt auf die Abhängigkeitskette: Angreifer kompromittieren Maintainer-Konten, injizieren bösartigen Code in populäre Pakete oder veröffentlichen Typosquat-Pakete. Beim Installieren/Aktualisieren wird der Code auf Ihren Systemen ausgeführt und kann Daten stehlen oder Backdoors platzieren.

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

Nein. npm audit prüft gegen bekannte CVEs. Zero-Day-Angriffe wie Axios erscheinen erst später. Sie benötigen Tools wie Socket.dev, die das tatsächliche Verhalten der Pakete analysieren.

Sollte ich npm komplett aufhören zu verwenden?

Nein. npm bleibt das größte Ökosystem, die meisten Pakete sind sicher. Ziel: Gefährdung durch exaktes Pinnen, Lockfile-Durchsetzung, Skript-Blockierung und Abhängigkeitsminimierung reduzieren. Prüfen Sie jede Abhängigkeit und nutzen Sie native Alternativen, wo möglich.

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

Apidog bietet integrierten HTTP-Client, Test-Runner, Mock-Server und Doku-Generator für APIs. Keine npm-Abhängigkeit für Axios, node-fetch, Jest, Express etc. Weniger npm-Abhängigkeiten = weniger Angriffsvektoren.

Was ist Paketprovenienz in npm?

Paketprovenienz verknüpft ein veröffentlichtes Paket kryptographisch mit Quell-Repository und CI/CD-Umgebung (Sigstore). Nachprüfbar mit npm audit signatures. Fehlt die Provenienz, ist Vorsicht geboten.

Wie viele npm-Pakete sind bösartig?

Snyk fand 2024 über 3.000 bösartige npm-Pakete. Im Q4/2025 blockierte Sonatype über 120.000 Malware-Attacken über npm, PyPI und andere. Die Zahl steigt. Die meisten bösartigen Pakete sind Typosquats, aber Kompromittierungen wie Axios zeigen: Auch populäre Pakete sind gefährdet.

Was ist die PackageGate-Schwachstelle?

PackageGate = 6 Zero-Day-Schwachstellen (offenbart Jan 2026; npm, pnpm, vlt, Bun). Git-basierte Abhängigkeiten können trotz deaktivierter Lebenszyklus-Skripte Code ausführen. Pinnen Sie Git-Abhängigkeiten auf Commit-Hashes.

Wichtige Erkenntnisse

  • Lockfiles sind das Fundament, schützen aber nicht bei Erstinstallation während eines Angriffsfensters
  • Postinstall-Skripte global deaktivieren (ignore-scripts=true in .npmrc)
  • Exakte Versionen pinnen (save-exact=true), um Semver-Fallen zu vermeiden
  • Paketprovenienz mit npm audit signatures prüfen
  • Socket.dev (Verhaltensanalyse) + Snyk (bekannte Schwachstellen) + npm audit (Basis)
  • Abhängigkeitsanzahl durch native Node.js-APIs und Plattformen wie Apidog reduzieren
  • CI/CD-Netzwerk-Egress mit StepSecurity Harden-Runner überwachen

Jede Abhängigkeit ist eine Vertrauensentscheidung. Je weniger Abhängigkeiten, desto kleiner die Angriffsfläche. Je mehr Verifizierungsschichten, desto schwieriger für Angreifer. Verteidigung in der Tiefe – nicht isoliert.

Top comments (0)