Die Abhängigkeitskette von npm ist ein Sicherheitsrisiko – und Entwickler können ihre Gefährdung reduzieren

Das Ausmaß des Problems: Ein Paket, Millionen von Opfern

Der ua-parser-js-Angriff von 2021 zeigte auf brutale Weise, welche Reichweite ein kompromittiertes Paket haben kann. Die Bibliothek, die Browser-User-Agent-Strings parst, hatte über 8 Millionen wöchentliche Downloads und war eine transitive Abhängigkeit in Projekten von Facebook, Apple, Amazon und Microsoft. Angreifer übernahmen das npm-Konto des Maintainers, veröffentlichten in rascher Folge drei bösartige Versionen und schleusten Kryptominer sowie Trojaner zum Diebstahl von Zugangsdaten ein – bei jedem, der in diesem Zeitfenster npm install ausführte. Das Paket war etwa vier Stunden live, bevor npm es entfernte.

ua-parser-js war nicht der größte Vorfall. Die Sabotage von colors.js/faker.js im Jahr 2022 durch Maintainer Marak Squires legte absichtlich Anwendungen lahm – aus Protest gegen unbezahlte Open-Source-Arbeit – und betraf über 19.000 abhängige Pakete. Der XZ-Ultils-Backdoor im März 2024, tief im Build-System der Komprimierungsbibliothek versteckt und nach fast zwei Jahren geduldigen Social Engineerings, stand kurz davor, in großen Linux-Distributionen ausgeliefert zu werden. Diese Vorfälle decken die gesamte Bedrohungsoberfläche ab: Account-Übernahme, bösartiger Maintainer und langfristige Infiltration.

Wie Abhängigkeitsbäume zu Angriffsflächen werden

Eine typische React-Anwendung hat 6–10 direkte Abhängigkeiten. Wenn du npm install ausführst, zieht jede davon ihren eigenen Abhängigkeitsbaum nach sich, der wiederum weitere Bäume nach sich zieht. Ein minimales create-react-app-Projekt generiert über 1.400 Pakete in node_modules. Davon sind vielleicht 20–30 Pakete, die dein Team jemals auf Vertrauenswürdigkeit geprüft hat. Der Rest sind transitive Abhängigkeiten – Code, der in deiner Build-Pipeline, deinem CI und möglicherweise in deinem Production-Bundle läuft, den dein Team nie auditiert hat.

Die Angriffsfläche wächst nichtlinear mit der Abhängigkeitstiefe. Eine Schwachstelle in einem Paket auf Tiefe 4 deines Baums (eine Abhängigkeit einer Abhängigkeit einer Abhängigkeit einer Abhängigkeit) ist in der Praxis nicht von einer Schwachstelle in deinem eigenen Code zu unterscheiden, sobald sie in Production gelangt. Dennoch auditieren die meisten Teams nur direkte Abhängigkeiten und haben keine systematische Abdeckung der tieferen Ebenen.

Typosquatting fügt eine weitere Angriffsvektor hinzu. Die npm-Registry enthält Pakete mit Namen, die populären Paketen bewusst ähneln: lodahs (lodash), crossenv (cross-env), reqyuest (request). Die automatisierte Typosquatting-Erkennung von npm hat sich seit 2022 verbessert – laut OpenSSF-Daten werden schätzungsweise 15.000 bösartige Pakete pro Monat blockiert –, aber neue Varianten schlüpfen dennoch durch.

Die Werkzeuge, die das Risiko tatsächlich reduzieren

Software Composition Analysis (SCA) im CI: Tools wie Snyk, Socket.dev und GitHub Dependabot scannen deinen Abhängigkeitsbaum gegen bekannte CVE-Datenbanken und markieren verwundbare Versionen, bevor sie gemergt werden. Snyks kostenloses Tarif deckt öffentliche Repositories und die meisten kleinen Teams ab. Socket.dev hebt sich ab, indem es das Verhalten von Paketen analysiert (neue Netzwerkzugriffe, obfuskierter Code, Installationsskripte) und nicht nur CVE-Hashes abgleicht – es hat die ua-parser-js-artigen Angriffe erkannt, die CVE-Datenbanken hinterherhinken. Integriere dein ausgewähltes Tool direkt in Pull-Request-Checks, nicht nur als periodischen Scan.

npm audit und Lockfile-Durchsetzung: npm audit ist eine Basismaßnahme, keine Lösung. Es markiert nur Pakete mit veröffentlichten CVEs und erzeugt bei hohen Schweregraden Rauschen, das Teams lernen zu ignorieren. Wertvoller: Setze durch, dass package-lock.json eingecheckt und niemals umgangen wird. Verwende in deiner CI-Pipeline npm ci (anstatt npm install) – npm ci installiert strikt aus der Lockfile und aktualisiert nichts. Ein modifizierte Lockfile in einem PR ist eine rote Flagge, die eine Überprüfung wert ist.

Dependency Pinning vs. semantische Versionierung: Die meisten package.json-Dateien verwenden Caret (^)-Versionierungsbereiche, die automatische Minor- und Patch-Updates erlauben. Ein Supply-Chain-Angriff, der eine bösartige Patch-Version veröffentlicht, wird bei der nächsten Installation automatisch eingezogen. Das Pinnen exakter Versionen (Entfernen des ^) verhindert stille Upgrades; Tools wie Renovate Bot oder Dependabot können die Disziplin automatisieren, Updates explizit zu prüfen und anzuwenden, anstatt sie stillschweigend zu übernehmen.

Subresource Integrity für CDN-geladene Skripte: Falls du in deinem HTML JavaScript von einem CDN lädst (jQuery, Analytics-Snippets, Font-Loader), verwende Subresource Integrity (SRI)-Hashes. Ein SRI-Hash weist den Browser an, das Skript abzulehnen, wenn sein Inhalt nicht mit dem erwarteten Hash übereinstimmt. Das verhindert, dass eine CDN-Kompromittierung deine Benutzer betrifft. SRI-Hashes zu generieren dauert 30 Sekunden mit openssl dgst -sha384 -binary script.js | base64; das Kosten-Nutzen-Verhältnis ist außergewöhnlich.

SLSA-Framework und Provenance Attestation

Das Supply-chain Levels for Software Artifacts (SLSA, ausgesprochen „Salsa“)-Framework, jetzt in Version 1.0 und von der OpenSSF verwaltet, bietet ein vierstufiges Reifegradmodell für Supply-Chain-Sicherheit. Auf SLSA Level 2 erzeugen Build-Systeme signierte Provenance Attestations: kryptografische Datensätze, die ein bestimmtes Artefakt (ein veröffentlichtes Paket) mit einem bestimmten Source-Commit und einer Build-Umgebung verknüpfen. Auf Level 3 wird die Build-Umgebung selbst gehärtet, um Manipulationen zu verhindern.

npm hat im Mai 2023 Unterstützung für Provenance Attestations hinzugefügt. Mit Provenance veröffentlichte Pakete enthalten eine überprüfbare Bestätigung, die das npm-Paket mit dem GitHub Actions-Workflow verknüpft, der es gebaut hat, dem spezifischen Commit-Hash und der Repository-URL. Als Verbraucher kannst du das mit npm audit signatures überprüfen. Anfang 2026 veröffentlichen etwa 8 % der Top-10.000-npm-Pakete mit Provenance – eine niedrige Zahl, die mit zunehmendem Bewusstsein und besseren Tools wachsen sollte.

Realistische Risikotriage: Worauf du dich konzentrieren solltest

Nicht jede Anwendung hat die gleiche Gefährdung. Eine serverseitige Node.js-API, die Finanztransaktionen abwickelt, hat ein ganz anderes Bedrohungsmodell als ein statischer Blog, der mit einem JavaScript-Framework erstellt wurde. Bevor du in umfassende SCA-Tools investierst, beantworte drei Fragen: Läuft diese Software mit erhöhten Rechten oder greift sie auf sensible Daten zu? Verarbeitet sie nicht vertrauenswürdige Eingaben? Wird sie in Umgebungen bereitgestellt, in denen eine Kompromittierung echte Konsequenzen hätte?

Für sicherheitskritische Anwendungen bietet der OpenSSF Scorecard (github.com/ossf/scorecard) automatisierte Sicherheitsbewertungen für Open-Source-Pakete über 18 Sicherheitschecks, darunter Branch Protection, Automatisierung von Dependency-Updates und Richtlinien zur Offenlegung von Schwachstellen. Den Scorecard gegen deine wichtigsten direkten Abhängigkeiten laufen zu lassen, bevor du sie hinzufügst, dauert Minuten und deckt Pakete mit schlechter Wartungshygiene auf, bevor sie in deinen Baum gelangen.

Konkrete Handlungsempfehlungen

• Füge noch diese Woche Socket.dev oder Snyk in deine CI-Pipeline ein – nicht als periodischen Scan, sondern als PR-Gate. Die Verhaltensanalyse von Socket.dev erkennt Bedrohungen, die reine CVE-Tools übersehen.
• Wechsle in CI von npm install zu npm ci und checke deine package-lock.json ein, falls du das noch nicht getan hast. Das verhindert Lockfile-Drift und stille Dependency-Upgrades in automatisierten Umgebungen.
• Pinne kritische Abhängigkeiten auf exakte Versionen und verwende Renovate Bot, um die Disziplin expliziter Upgrades zu verwalten. Der Betriebsaufwand ist gering; der Sicherheitsgewinn ist real.
• Führe npm audit signatures aus auf deinen wichtigsten Abhängigkeiten, um zu prüfen, welche mit Provenance Attestation veröffentlicht werden. Bevorzuge für hochsensible Anwendungen provenance-beglaubigte Pakete, wenn Alternativen existieren.
• Füge SRI-Hashes zu allen CDN-geladenen Skripten in deinem HTML hinzu. Das dauert Minuten und eliminiert CDN-Kompromittierung als Angriffsvektor für browserausgeführten Code.
• Bewerte deine tatsächliche Schadensreichweite, bevor du überdimensionierst. Ein persönliches Projekt braucht keine vollständige SLSA-Pipeline. Ein Zahlungsabwicklungsdienst schon. Passe die Investition an das tatsächliche Risiko an.