Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Jedes Mal, wenn „npm install“ ist ein Vertrauensakt. Dasselbe Paket-Ökosystem, das die JavaScript-Entwicklung beschleunigt, ist zugleich ein Hauptvektor für Supply-Chain-Angriffe. Wenn Sie einen Installationsbefehl ausführen, holen Sie sich einen weitverzweigten Baum von Abhängigkeiten ins Haus, von denen viele undurchsichtig und verborgen sind.
npm install ist in den meisten Fällen sicher. Dieses „meistens“ hat es in sich. „Install“ ist nicht nur ein Download, sondern eine Ausführung, und Skripte zum Lebenszyklus von Abhängigkeiten werden mit den Berechtigungen ausgeführt, über die die Installationsumgebung bereits verfügt. Auf einem Entwickler-Laptop oder einem CI-Runner reicht das in der Regel völlig aus. Der Code wird abgerufen, entpackt und ausgeführt, bevor ihn jemand überprüft hat. Alle folgenden Ausführungen beziehen sich auf npm v12, pnpm 11 und Yarn 4.10 (Stand: August 2026), da sich die Standardwerte in diesem Bereich rasch weiterentwickelt haben.
Die Typosquatting-Falle
Dieser Angriff findet statt, wenn ein Angreifer ein Paket veröffentlicht, das einen Tippfehler enthält. Bei dem Tippfehler kann es sich um eine einfache falsche Schreibweise des Paketnamens handeln oder um einen ganz anderen Formatierungstrick. Das Paket sieht fast genauso aus wie beliebte Pakete und bietet dieselben Funktionen.
- Zeichenbearbeitung: Vertauschen lodash durch „lodahs“oder die Verwendung von Homoglyphen (z. B. das Ersetzen von „l“ durch „I“).
- Formatvarianten: Verwendung von Bindestrich-Tricks (cross-env vs. crossenv) oder Pluralisierung (color vs. colors).
- Verwechslung von Namespace und Geltungsbereich: Erstellung bösartiger, auf einen bestimmten Geltungsbereich beschränkter Pakete, die offizielle Bibliotheken imitieren.
Diese Pakete können während des Installationsvorgangs beliebigen Code ausführen und alle Arten von Anmeldedaten abgreifen – von API-Schlüsseln über Umgebungsvariablen bis hin zu AWS-Anmeldedaten usw. Dies kann extrem schnell geschehen, noch bevor ein Entwickler die Möglichkeit hat, den Code zu überprüfen.
So funktionieren Dependency-Confusion-Angriffe
Dieser Angriff nutzt Organisationen aus, die eine hybride Konfiguration verwenden, d. h. eine interne Registry neben der öffentlichen npm-Registry.
Angriffe durch „Dependency Confusion“ treten auf, wenn ein Unternehmen über ein internes Paket verfügt und ein Angreifer ein Paket mit demselben Namen im öffentlichen Register veröffentlicht. In der Regel wird dieses Paket mit einer Versionsnummer veröffentlicht, die höher ist als die des internen Pakets. Wenn Ihre Build-Umgebung diesen Namen aus beiden Registern auflösen kann, wird möglicherweise stattdessen das öffentliche Paket des Angreifers abgerufen. In diesem Paket befindet sich der Schadcode.
Ob dies geschieht, hängt von der Konfiguration Ihrer Registrierungsdatenbank, Ihres Scopes, Ihres Proxys und Ihrer Lockfile-Datei ab. Betroffen sind jene Konfigurationen, die niemand überprüft hat.
Um dieses Risiko zu mindern, sollten Sie Pakete mit festgelegten Gültigkeitsbereichen verwenden und das Routing deterministisch gestalten. Ordnen Sie jeden privaten Gültigkeitsbereich explizit Ihrer privaten Registry in .npmrczu ordnen und sicherzustellen, dass nichts in Ihrer Proxy-Kette unbemerkt auf den öffentlichen Bereich zurückgreift. Beanspruchen Sie den entsprechenden Bereich auf npmjs.com sorgt für eine zusätzliche Sicherheitsebene, da ein Angreifer nicht unter einem Scope veröffentlichen kann, der Ihnen bereits gehört. Wenn Sie in den letzten Jahren etwas installiert haben, wissen Sie, was ein Scoped-Paket ist. Ein Scoped-Paket sieht in etwa so aus: @my-org/cool-package. Das erste Zeichen ist das @-Symbol, gefolgt von Ihrem Namen oder Ihrer Organisation und dem Paket, das Sie installieren.
Ohne diese Sicherheitsvorkehrungen kann der Angriff allein durch die Festlegung eines Gültigkeitsbereichs nicht vollständig verhindert werden. Ein Gültigkeitsbereich an sich ist lediglich eine Namenskonvention, keine Kontrollmaßnahme. Die richtige Konfiguration Ihrer CI/CD-Plattform trägt ebenfalls dazu bei, das Risiko zu mindern.
Was passiert, wenn ein Maintainer-Konto gehackt wird?
Sowohl beim Typosquatting als auch bei der Abhängigkeitsverwechslung müssen Sie etwas installieren, das Sie eigentlich gar nicht installieren wollten. Bei der schwierigeren Variante wird dieser Schritt übersprungen. Der Angreifer übernimmt ein Paket, dem Sie bereits vertrauen, das Sie bereits geprüft und bereits fest zugeordnet haben.
Dies ist derzeit der Vektor, der den größten Schaden anrichtet. Im Rahmen einer Phishing-Kampagne gegen npm-Betreuer im September 2025 entstand der Shai-Hulud-Wurm, der Cloud-Token stahl und diese nutzte, um sich auf weitere Konten auszubreiten. Am 4. August 2026 verschaffte sich ein Angreifer Zugang zum GitHub-Konto des Betreuers hinter keyv, einer Bibliothek mit weit über 100 Millionen Downloads pro Woche, und veröffentlichte Versionen, die Anmeldedaten stahlen, über keyv, cacheable, flat-cache, file-entry-cacheund andere in diesem Cluster. Die Tracker zählten innerhalb eines Tages Hunderte betroffener Paketnamen und über tausend betroffene Versionen.
Hier ist der Punkt, der Ihnen zu denken geben sollte. Die Veröffentlichung erfolgte über den GitHub-Actions-Workflow des Betreuers selbst, sodass sie eine gültige, durch OIDC abgesicherte Herkunftsangabe sowie einen gültigen Integritäts-Hash enthielt. Beide beschrieben genau das manipulierte Artefakt, das der legitime Workflow erzeugt hatte. Die Herkunftsangabe gibt Auskunft darüber, wo und wie ein Paket erstellt wurde. Sie sagt jedoch nichts darüber aus, wer im Besitz der Schlüssel war.
Dies wurde durch Verhaltensanalysen und Kontrollen des Release-Alters aufgedeckt, nicht durch kryptografische Prüfungen. Die Rückverfolgbarkeit ist zwar wichtig, stellt aber nicht das A und O dar.
Warum transitive Abhängigkeiten nicht geprüft werden
Eine direkte Abhängigkeit kann – selbst wenn sie geprüft wurde – zahlreiche transitive Abhängigkeiten mit sich bringen, die Sie nicht gesehen haben und deren Existenz Ihnen nicht bewusst ist. Diese verborgenen Abhängigkeiten können im Abhängigkeitsbaum 5 bis 10 oder mehr Ebenen tief liegen.
Die meisten Abhängigkeiten befinden sich tief in der Projektstruktur, wo sie nur selten manuell überprüft werden, wodurch eine „dunkle Höhle“ entsteht, die Angreifern völlig schutzlos ausgeliefert ist. Diese mangelnde Transparenz ist ein Hauptangriffsvektor für Supply-Chain-Angriffe. Diese treten auf, wenn böswillige Akteure Pakete infiltrieren oder diese vollständig einschleusen, was bei der Installation oft unbemerkt bleibt – ein Risiko, das selbst einige KI-gesteuerte Scaffolding-Tools nicht eindämmen können, wie in meinem Blogbeitrag zum Thema „Dockerfile“erwähnt.
Während „npm ls“ ein nützliches Tool zur Visualisierung vollständiger Abhängigkeitsbäume ist, sucht es jedoch nicht nach Schwachstellen oder verdächtigem Verhalten. Deshalb sind Software-Composition-Analysis-Tools (SCA) wichtig, um Probleme zu finden, die tief im Stack verborgen sind.
| Werkzeug | Gut in | Wird fehlen |
| Dependabot | Bekannte CVEs in Ihrem Baum, automatisierte Bump-PRs | Völlig neue Schadsoftware-Pakete, da noch keine CVE-Nummer vorliegt |
| Buchse | Verhaltensmerkmale, neue Installationsskripte, unerwartete Netzwerk- oder Dateisystemzugriffe | Wurde nicht von vornherein als CVE-Datenbank konzipiert |
| Snyk | CVE-Abdeckung sowie Überprüfungen der Lieferkette und der Lizenzen | Muss noch abgestimmt werden, bevor der Ausgang kein Rauschen mehr liefert |
Dependabot ist die reibungslose Basislösung, wenn sich Ihre Repos auf GitHub befinden. Verwechseln Sie es jedoch nicht mit der Erkennung bösartiger Pakete, denn ein Paket, das erst vor einer Stunde veröffentlicht wurde, verfügt noch nicht über eine entsprechende CVE-Kennung.
Wie bösartig vorinstalliert und nach der Installation Skripte Code ausführen
Vorinstallation und postinstall Hooks in package.json führen Code automatisch aus, sobald ein Paket abgerufen und entpackt wurde, noch bevor der Entwickler den Inhalt des Pakets überprüft hat.
Diese Skripte zielen auf besonders wertvolle Ressourcen wie Bankensysteme, Build-Server usw. ab – sozusagen die Crème de la Crème. Sie entwenden wichtige Anmeldedaten wie .env -Dateien, AWS-Token und SSH-Schlüssel, an deren Bedeutung wir ständig erinnert werden NICHT in die Versionskontrolle einzuspielen.
Manche Skripte führen vor der Ausführung ihrer Nutzlast Umgebungsprüfungen durch, um Sandboxen oder stark überwachte Systeme zu erkennen, und greifen zunächst auf weniger gut gesicherte Umgebungen zurück.
Dies ist nach wie vor der bevorzugte Verbreitungsweg. Jede infizierte Version im Rahmen der Kampagne vom August 2026 enthielt eine vorinstallierten Dropper.
Die Standardeinstellungen haben sich nun aber doch geändert. pnpm hat in Version 10 die Ausführung von Skripten zum Lebenszyklus von Abhängigkeiten standardmäßig eingestellt, und npm v12, das am 8. Juli 2026 veröffentlicht wurde, verfolgt denselben Ansatz, der über npm approve-scriptsverwaltet wird. Ein nicht genehmigtes Skript wird mit einer Warnung übersprungen; setzen Sie daher strict-allow-scripts , wenn Sie stattdessen möchten, dass die CI fehlschlägt. Bei npm 11 oder früheren Versionen übernimmt das Flag diese Aufgabe für Sie:
bash npm install --ignore-scripts
Es ist wichtig zu wissen, dass all dies keinerlei Auswirkungen auf die Ausführung zum Zeitpunkt des Imports hat. Ein kompromittiertes Paket, dessen Code auf oberster Ebene ausgeführt wird, wenn Ihre App require() aufruft, umgeht die Kontrollen des Installationsskripts vollständig.
Warum das Alter einer Verpackung ein Sicherheitsindikator ist
Die meisten dieser Angriffe werden tatsächlich entdeckt, meist innerhalb von Stunden statt Wochen. Das Problem ist, dass Ihre CI in diesen Stunden bereits die fehlerhafte Version abgerufen hat.
Ein Mindestalter für die Veröffentlichung schränkt diesen Zeitraum ein, ohne dass jemand etwas überprüfen muss. Jeder größere Paketmanager bietet diese Funktion mittlerweile an. pnpm 11 führt minimumReleaseAge standardmäßig auf 1.440 Minuten ein, Yarn 4.10 setzt standardmäßig npmMinimalAgeGate standardmäßig auf drei Tage, und npm verfügt über min-release-age ab Version 11.10, lässt diese Option jedoch deaktiviert, sodass Sie sie selbst einstellen müssen. Achten Sie auf die Einheiten, da npm Tage und pnpm Minuten zählt.
# .npmrc min-release-age=7
Die meisten Fachleute gehen von drei bis sieben Tagen aus. Das hilft jedoch nicht bei einem Paket, das von Anfang an bösartig war, oder bei einem, das über Ihren Schwellenwert hinaus inaktiv bleibt.
npx erfordert denselben Ansatz. Wenn etwas Neues abgerufen wird, bestimmt Ihre Lock-Datei nicht, welche Version ausgewählt wird. Legen Sie daher fest, was Sie mit npx [email protected]fest.
So installieren Sie npm-Pakete sicher
- Stellen Sie sicher, dass Sie Ihre Lock-Dateien committen und verwenden Sie npm ci für deterministische, zuverlässige Builds in CI-Umgebungen. Die Lockdatei in Kombination mit npm ci sorgt dafür, dass Ihr aufgelöster Baum einschließlich der transitiven Abhängigkeiten tatsächlich festgelegt wird.
- Genaue Versionen in package.json fest, indem Sie Präfixsymbole (^, ~), an denen Sie den Zeitpunkt der Aktualisierung direkter Abhängigkeiten steuern möchten. Dies sorgt eher für Vorhersehbarkeit als für Sicherheit, da es für den transitiven Baum keine Auswirkungen hat.
- Der Paketmanager soll Abhängigkeitsskripte standardmäßig blockieren. Dies ist bereits das Verhalten bei pnpm 10 und höher sowie bei npm v12 der Fall, und es ist –ignore-scripts bei allen älteren Versionen.
- Überprüfen Sie Ihre Pakete regelmäßig und nutzen Sie SCA-Tools wie Dependabot, Socket oder Snyk, um Unregelmäßigkeiten in Ihrem Abhängigkeitsbaum aufzudecken.
- Legen Sie ein Mindestalter von drei bis sieben Tagen für die Freigabe fest.
- Aktivieren Sie die MFA für jedes Konto, das Inhalte veröffentlichen kann, und halten Sie die Veröffentlichungstoken begrenzt und von kurzer Dauer.
Das Blockieren von Skripten ist mit echten Kosten verbunden, treffen Sie Ihre Entscheidung daher wohlüberlegt. Native Module und Browser-Automatisierungstools erfordern eigene Installationsschritte, und genau, bcrypt, Prisma, Playwright und Cypress sind dabei die üblichen Opfer. Blockieren Sie in der CI standardmäßig, genehmigen Sie nur das, was Sie benötigen, und führen Sie diese Builds an einem Ort aus, an dem Ihre Produktionszugangsdaten nicht gespeichert sind. Auf einem Laptop sollten Sie lieber das eine Paket genehmigen, das zu Fehlern führt, anstatt den Schutz für alles zu deaktivieren. Achten Sie in jedem Fall auf stille Fehler, denn ein blockierter nativer Build kann scheinbar fehlerfrei beendet werden und erst später zur Laufzeit als fehlendes Modul auffallen.
Abschließende Überlegungen zur Sicherheit der npm-Lieferkette
Die Sicherheit der Software-Lieferkette ist niemals eine einmalige operative Anforderung. Sicherheitsmaßnahmen sind ein fortlaufender Prozess und sollten stets oberste Priorität haben. Drei Aspekte, die oft auf die lange Bank geschoben werden, bis die Hölle losbricht, sind Leistung, Barrierefreiheit und – Sie haben es erraten – Sicherheit. Sich über Tools und Tricks auf dem Laufenden zu halten, die zur Sicherheit beitragen, gehört zum Alltag eines Entwicklers dazu. Behalten Sie praktische Abwehrmaßnahmen im Hinterkopf und stellen Sie die Sicherheit bei der Veröffentlichung stets in den Vordergrund.
