Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Jedes npm install ist ein Akt des Vertrauens. Hast du schon einmal dein node_modules Ordner und fragte sich, Was ist hier eigentlich drin?? In der modernen Softwareentwicklung befinden wir uns in einer seltsamen Situation: Wir sind für einen unsichtbaren Eisberg aus Code verantwortlich, den wir nicht selbst geschrieben haben. Ein Großteil davon kommt in Form von transitiven Abhängigkeiten ins Spiel – Pakete, die niemand im Team direkt ausgewählt hat. Wenn dieser Code in die Produktion geht, verwandelt sich diese Verantwortung in Angst. SecureChain bietet eine Schutzebene, um einen Teil dieses Drucks durch Dritte zu bewältigen.
Der Eisberg der transitiven Abhängigkeiten
Bevor Sie ein Paket installieren, das als direkte Abhängigkeit vorliegt, sollten Sie sich vielleicht die GitHub-Stars, das Profil des Betreuers und die Profile der Mitwirkenden ansehen. Die Bibliothek steht selten für sich allein. Ein transitives Paket kommt mit ins Boot, weil eine direkte Abhängigkeit es benötigt. Stellen Sie sich das wie „Pakete Ihrer Pakete“ vor, ja sogar wie „Pakete von Paketen Ihrer Pakete“. Diese können mehrere Ebenen tief sein und dennoch unberührt bleiben.
Dieser Eisberg reicht tief ins Innere – das Wortspiel ist durchaus beabsichtigt. Eine „einfache“ Web-App kann die Marke von 1.000 Paketen in Ihrem Repository leicht sprengen. node_modules. Genau in diesen tief verborgenen transitiven Abhängigkeiten lauern häufig Angriffe auf die Lieferkette. Sie erweitern den von Ihnen übernommenen Code von Drittanbietern erheblich, und manuelle Prüfungen reichen selten so tief hinein.
Das Problem ist nicht, dass transitive Abhängigkeiten schlecht sind; die moderne Softwareentwicklung ist auf sie angewiesen. Das Problem ist, dass der Code, den man übernimmt, schneller wächst als der Code, den man überprüft.
Wenn das Bösartige seriös wirkt
Die Besorgnis rührt von jenen Paketen her, die zwar seriös erscheinen, aber in Wirklichkeit bösartig sind. Als Entwickler verlassen wir uns bei unserer Arbeit stark auf unsere „muskuläre Erinnerung“. Und dank KI ist das für die Erledigung der Arbeit mittlerweile gar nicht mehr nötig. Programmierassistenten schlagen manchmal Paketnamen vor, die gar nicht existieren. Das eröffnet einen neuen Ansatz namens „Slopsquatting“: Man registriert den Namen, den ein Modell immer wieder „halluziniert“, und wartet ab.
Im Folgenden finden Sie eine Liste der häufigsten Beispiele.
Typosquatting
Bei Typosquatting-Angriffen registrieren Angreifer Pakete mit Namen, die von legitimen, beliebten Bibliotheken kaum zu unterscheiden sind, und setzen darauf, dass jemand sich vertippt, den Text nur flüchtig überfliegt oder einem Vorschlag vertraut. Diese Pakete ahmen oft die Funktionalität des Ziels nach, sodass auf den ersten Blick nichts auffällt. Zu den gängigen Taktiken gehören:
- Zeichenersetzung: Buchstaben vertauschen, wie in
lodashundlodahs, ein echtes Schadprogramm, das es auf Kryptowährungs-Wallets abgesehen hatte. Neue npm-Namen müssen aus Kleinbuchstaben bestehen und URL-sicher sein, daher greifen Fälschungen auf Tricks zurück, die diese Regeln umgehen, wie zum Beispiel ein1anstelle einesl. - Nachahmung von Namespaces oder Gültigkeitsbereichen: Registrierung von Paketen mit begrenztem Gültigkeitsbereich, deren Namen offiziellen Bibliotheken stark ähneln; dies ist zu unterscheiden von dem unten beschriebenen Angriff durch Registrierungsauflösung.
- Formatvarianten: Durch den Einsatz von Silbentrennungstricks (z. B.
crossenvvs.cross-env) oder die Pluralbildung zu ändern.
Da diese Pakete während der Installation beliebigen Code ausführen können, sind sie in der Lage, API-Schlüssel, Umgebungsvariablen oder AWS-Anmeldedaten zu stehlen, bevor jemand den Quellcode zur Überprüfung einsehen kann.
Verwirrung hinsichtlich der Abhängigkeiten
„Dependency Confusion“-Angriffe zielen auf Unternehmen ab, die eine Mischung aus öffentlichen und privaten Registries verwenden. Ein Angreifer kann diese Konfiguration ausnutzen, indem er ein schädliches Paket mit demselben Namen wie ein internes Paket veröffentlicht und diesem in der Regel eine höhere Versionsnummer zuweist. Wenn Ihre Build-Konfiguration nicht streng isoliert ist, kann es vorkommen, dass das System den Paketnamen nicht mit Ihrer internen Version, sondern mit der öffentlichen Version des Angreifers verknüpft und den schädlichen Code bei der Installation automatisch ausführt.
Das ist keineswegs reine Theorie. Alex Birsan hat dies im Jahr 2021 bewiesen, indem er Pakete veröffentlichte, die nach internen Bibliotheken benannt waren, und beobachtete, wie diese innerhalb der Systeme von Apple, Microsoft und Dutzenden anderer Unternehmen aufgelöst wurden.
Für diejenigen, die damit noch nicht vertraut sind: Scoped-Pakete (z. B. @my-org/cool-package) verwende ein @ Symbol für Namespace-Abhängigkeiten. Ob Ihre Organisation anfällig ist, hängt oft davon ab, wie Sie Ihr Registry, Ihren Scope, Ihre Proxys und Ihre Lockfiles konfigurieren. Systeme, deren Routing-Verhalten noch nie überprüft wurde, sind am stärksten gefährdet. Um Ihre Pipeline zu sichern, stellen Sie sicher, dass Ihre Paketauflösung deterministisch ist. Ordnen Sie private Scopes Ihrem internen Registry in .npmrc ausdrücklich, damit Ihr Paketmanager diesen Bereich nicht unerwartet über das öffentliche Register auflöst:
@my-org:registry=https://registry.internal.example.com/Das Beanspruchen übereinstimmender Scopes auf npmjs.com verhindert zudem, dass Angreifer unter einer Identität veröffentlichen, die Sie bereits besitzen. Beachten Sie, dass die Scope-Vergabe in erster Linie eine Namenskonvention und keine Sicherheitsmaßnahme ist. Wenn derselbe Abhängigkeitsname von zwei verschiedenen Orten aus aufgelöst werden kann, trifft jemand anderes diese Entscheidung für Sie.
Lebenszyklus-Skripte
Package.json Lebenszyklus-Hooks wie beispielsweise preinstall, install,und postinstall wird automatisch während der Installation der Abhängigkeiten ausgeführt, lange bevor sich jemand aus dem Entwicklerteam überhaupt angesehen hat, was darin enthalten ist.
Diese Schadcodes zielen gezielt auf die wertvollsten Ziele ab: Bankinfrastruktur, Build-Server und Ähnliches. Sie entlocken kritische Geheimnisse, darunter .env Dateien, AWS-Token und SSH-Schlüssel: genau die Dinge, von denen uns immer gesagt wird, dass wir sie niemals in die Versionskontrolle einpflegen dürfen.
Bestimmte Skripte sondieren zunächst die Umgebung, um festzustellen, ob es sich um Sandboxen oder streng überwachte Systeme handelt, und warten mit der Ausführung, bis sie an einem weniger gut geschützten Ort landen.
Shai-Hulud hat gezeigt, welche Ausmaße dies annimmt. Die Welle vom September 2025 nutzte postinstall um npm-Token und Cloud-Zugangsdaten aus Hunderten von Paketen abzugreifen und sich anschließend mit den gestohlenen Daten erneut zu veröffentlichen. Die Angriffswelle im November führte dazu, dass die Ausführung früher stattfand, nämlich preinstall, sodass die Payload ausgeführt wurde, bevor die Installation abgeschlossen war. Spätere Varianten versteckten sich in optionalen Abhängigkeiten, führten die Payload aus und lösten anschließend einen Fehler aus, der von npm toleriert wird.
Allerdings hat sich das Standardverhalten nun endlich geändert. pnpm In Version 10 werden die Skripte für den Lebenszyklus der Abhängigkeiten nicht mehr automatisch ausgeführt; alles, was kompiliert werden muss, muss in onlyBuiltDependencies. npm v12, veröffentlicht am 8. Juli 2026, vertrat denselben Standpunkt: Abhängigkeitsskripte werden nur ausgeführt, wenn das Stammpaket allowScripts sofern die Richtlinien dies zulassen, und npm approve-scripts --allow-scripts-pending listet alles auf, was auf eine Entscheidung wartet.
Es gibt jedoch einen Haken. Ein nicht genehmigtes Skript wird mit einer Warnung übersprungen, und die Installation beendet sich dennoch mit dem Status 0, was dazu führen kann, dass eine native Abhängigkeit nur teilweise erstellt wird und der Fehler später in Ihrem Build oder zur Laufzeit auftritt. Committen Sie das allowScripts Blockieren und festlegen strict-allow-scripts=true In CI führen nicht geprüfte Skripte daher stattdessen zu einem Fehlschlag beim Build. Wenn Sie npm 11 oder älter verwenden, übernimmt das folgende Flag dies für Sie:
npm install --ignore-scriptsNützlich, ja. Vollständig, nein. Nichts davon befasst sich mit der Ausführung zum Zeitpunkt des Imports, und ein bösartiges Paket, dessen Code auf oberster Ebene in dem Moment ausgelöst wird, in dem Ihre App require() umgeht die Sicherheitsvorkehrungen des Installationsskripts mühelos.
Es lastet ein enormer Druck auf uns, wenn es um die Verantwortung für den Code geht, den wir veröffentlichen. Im „2026 Open Source Landscape Report“ von TuxCare gaben 61,4 % der Befragten, deren Organisationen einen Cybersicherheitsvorfall gemeldet hatten, an, dass ein Patch VERFÜGBAR gewesen sei, aber nie installiert worden sei. Diese Zahl sollte extrem niedrig sein. Das Wissen um ein Risiko ist nicht dasselbe wie dessen Beseitigung.
Die Abhängigkeitstiefe erschwert dies. Eine Korrektur, die weiter oben im Code vorgenommen wurde, hat keinerlei Auswirkungen auf die Kopie, die vier Ebenen tiefer in Ihrer Struktur verankert ist.
Die manuelle Überprüfung ist nach wie vor ein wichtiger Bestandteil des Prozesses, doch eine manuelle Prüfung eines Diagramms dieser Größe ist nicht realistisch. Wenn Sie keinen Überblick darüber haben, was Sie ausliefern, kann und wird dies letztendlich die Sicherheit Ihrer Systemarchitektur gefährden.
Angstzustände mit SecureChain überwinden
Das Management von Abhängigkeitsrisiken muss Teil der Richtlinie sein. Die Umsetzung dieses Managements in großem Maßstab kann jedes Team überfordern. SecureChain verändert den Verwendungsweg. Anstatt direkt aus dem öffentlichen Register abzurufen, beziehen Ihre Builds Pakete aus einem von TuxCare verwalteten Register, in dem die Pakete nach einem veröffentlichten Zeitplan neu kompiliert, signiert und gepatcht wurden.
Jede Registrierung ist nach wie vor eine Vertrauensentscheidung. Was sich ändert, ist, dass ein größerer Teil dieses Vertrauens überprüfbar wird.
Quellcode-Härtung
Jedes Paket, einschließlich transitiver Abhängigkeiten, wird in abgesicherten, isolierten Umgebungen aus dem Quellcode neu kompiliert und auf bekannte Malware sowie verdächtigen Code überprüft, anstatt einfach die vom Upstream veröffentlichten Artefakte weiterzuverbreiten.
Kontinuierliche Fehlerbehebung
SecureChain stellt im Rahmen des SLA Korrekturen bereit, sobald CVEs bekannt werden. Bei Paketen, deren Lebenszyklus beim Upstream-Anbieter abgelaufen ist, sorgt der „Endless Lifecycle Support“ (ELS) dafür, dass kritische und hochgradig schwerwiegende Korrekturen weiterhin auf die von Ihnen bereits verwendeten Versionen zurückportiert werden.
Richten Sie Ihren Paketmanager auf SecureChain aus oder auf den von Ihnen bereits verwendeten Repository-Manager, der mit Artifactory und Nexus kompatibel ist. Das Ergebnis sind Herkunftsdaten, die eine nachprüfbare SLSA-Level-3-Konformität gewährleisten, VEX-Dokumente, aus denen hervorgeht, welche CVEs eine Paketversion betreffen, sowie maschinenlesbare SBOMs für alle unterstützten Komponenten – wobei der Umfang stetig erweitert wird. Nichts davon ersetzt jedoch gute Sicherheitspraktiken. Sie benötigen weiterhin Lockfiles, bereichsbezogene Registry-Regeln und CI-Anmeldedaten mit minimalen Berechtigungen.
Das Fazit
Sie können einen Teil der Unsicherheit ausräumen, wenn Sie Code veröffentlichen, den Sie nicht selbst geschrieben haben. Sicherheit ist eine fortlaufende Aufgabe und Richtlinie. Es handelt sich niemals um eine Denkweise oder Vorgehensweise nach dem Motto „Einmal einrichten und dann vergessen“. Das Verständnis transitiver Abhängigkeiten und das Bewusstsein für die damit verbundenen Probleme helfen Ihnen dabei, fehlerfreien Produktionscode zu veröffentlichen.
Das Ziel ist nicht, Open Source nicht mehr zu vertrauen. Wir alle sind darauf angewiesen. Das Ziel ist, dieses Vertrauen nicht länger als selbstverständlich hinzunehmen.
Der Einsatz von Tools wie SecureChain kann uns einen Teil dieser schweren Last abnehmen, die wir alle zu tragen haben. Seien Sie immer einen Schritt voraus und sichern Sie IHRE Lieferkette.
