Das JavaScript-Paket-Ökosystem, insbesondere npm, war schon immer eine lebendige, wenn auch gelegentlich chaotische, Grenze. Aber während wir 2025 ausklingen lassen, liegt eine andere Art von Energie in der Luft: ein spürbarer, dringender Drang nach einer sichereren Software-Lieferkette. Jüngste, hochkarätige Angriffe haben die Diskussion von "ob" zu "wie" verschoben, wir unsere Abhängigkeiten gemeinsam stärken. Ich habe mich tief in die Materie vertieft, das neueste Tooling getestet und die Entwicklung der Landschaft beobachtet, und ehrlich gesagt, einige der Fortschritte sind wirklich beeindruckend, auch wenn der Weg zur vollständigen Akzeptanz immer noch mit einigen kniffligen Dornen gepflastert ist.
Es geht hier nicht nur um das Patchen; es handelt sich um eine grundlegende Neubewertung von Vertrauen, Provenance und den eigentlichen Mechanismen, wie wir Code konsumieren und veröffentlichen. Die gute Nachricht? Wir sehen echte, greifbare Bemühungen vom Kern-npm-Team, GitHub und der breiteren Community, um diese systemischen Schwachstellen zu beheben.
Der Aufstieg von npm provenance und Sigstore: Vertrauen an der Quelle
Dies ist wirklich beeindruckend, da es eine der heimtückischsten Bedrohungen angeht: eine kompromittierte Build- oder Publishing-Umgebung. Seit Jahren verlassen wir uns auf das Feld integrity in package.json für Prüfsummen, aber das verifiziert nur das heruntergeladene Paket anhand dessen, was das Registry sollte sein. Es sagt uns nicht, ob das Paket von dem legitimen Maintainer in einer vertrauenswürdigen Umgebung erstellt und veröffentlicht wurde. Hier kommt npm provenance ins Spiel, das seit Oktober 2023 allgemein verfügbar ist, mit erheblichem Schwung durch 2024 und 2025.
npm provenance ist die Implementierung des Supply-chain Levels for Software Artifacts (SLSA)-Frameworks durch npm, die die Leistungsfähigkeit von Sigstore nutzt. Die Kernidee besteht darin, überprüfbare Attestierungen darüber zu erstellen, wie und wo ein Paket erstellt und veröffentlicht wurde. Wenn Sie ein Paket mit --provenance veröffentlichen, arbeitet die npm CLI mit Ihrem CI/CD-Anbieter (derzeit werden GitHub Actions und GitLab CI/CD unterstützt), um eine Provenance-Attestierung zu generieren. Diese Attestierung enthält Details wie die Quellrepository-URI, den Commit-Hash und die Build-Anweisungen.
Hier ist die architektonische Eleganz: Anstatt langfristige Signierschlüssel zu verwalten, verwendet Sigstore kurzlebige, ephemere Zertifikate, die von einer Zertifizierungsstelle (Fulcio) ausgestellt werden, die sich mit Ihrem OIDC-Anbieter föderiert. Dieses Zertifikat wird dann verwendet, um die Provenance-Anweisung zu signieren, und sowohl das Zertifikat als auch die Signatur werden in einem öffentlichen, manipulationssicheren Transparenzprotokoll (Rekor) aufgezeichnet. Das bedeutet, Sie signieren den Build, verwerfen den privaten Schlüssel und der gesamte Prozess ist öffentlich überprüfbar.
Um mit Provenance zu veröffentlichen, ist es so einfach wie das Hinzufügen eines Flags:
npm publish --provenance --access public
Und zur Verifizierung? Der Befehl npm audit signatures, der im Juli 2022 eingeführt wurde, ist jetzt unser bester Freund dafür. Er verifiziert ECDSA-Signaturen und gibt einen Fehler aus, wenn Pakete fehlende oder ungültige Signaturen aufweisen, was auf eine mögliche Manipulation hindeutet.
npm audit signatures
Dies ist ein monumentaler Schritt nach vorn. Es garantiert zwar nicht die Abwesenheit von bösartigem Code, bietet aber eine kryptografische Verbindung zurück zur Quelle und Build-Umgebung und ermöglicht Entwicklern, fundierte Vertrauensentscheidungen zu treffen. Die Einschränkung besteht derzeit in der Abhängigkeit von Cloud-gehosteten Runnern und bestimmten CI/CD-Anbietern. Für diejenigen von uns mit selbstgehosteten Runnern oder alternativen CI-Systemen ist die Akzeptanz immer noch etwas umständlich und erfordert manuelle Workarounds oder das Warten auf eine breitere Unterstützung. Aber die Richtung ist klar und robust.
Absicherung des Publishers: 2FA, granulare Token und Trusted Publishing
Die Welle von Supply-Chain-Angriffen im Jahr 2025, einschließlich des Wurms "Shai-Hulud" im September und nachfolgender Typosquatting-Kampagnen im Oktober, diente als brutaler Weckruf. Angreifer kompromittierten Maintainer-Konten durch ausgeklügelte Phishing-Angriffe, was zu bösartigen Paket-Injektionen führte. GitHub, das npm besitzt, hat mit aggressiven, notwendigen Änderungen an Authentifizierung und Publishing reagiert, die weitgehend zwischen Oktober und Mitte November 2025 ausgerollt wurden.
Die wichtigsten Veränderungen sind:
- Obligatorische 2FA für lokales Publishing: Dies ist ein großer Gewinn. Kein Publishing mehr von einer lokalen Maschine nur mit einem Passwort. Wenn Sie aus Ihrer Entwicklungsumgebung veröffentlichen, ist 2FA erforderlich. Dies geht direkt auf die Phishing-Vektoren zu, die Maintainer heimgesucht haben.
- Abschaffung von Legacy Classic Tokens: Klassische npm-Token, die oft langfristig und breit gefasst sind, werden abgeschafft. Dies ist entscheidend, da kompromittierte, langfristige Token ein primärer Angriffsvektor waren.
- Begrenzte Lebensdauer für granulare Token: Neue granulare Token, die feinere Berechtigungen ermöglichen, haben eine maximale Lebensdauer von sieben Tagen (mit einem Maximum von 90 Tagen in einigen Fällen). Dies reduziert die Zeitspanne für Angreifer drastisch, falls ein Token gestohlen wird.
- Erweiterung von Trusted Publishing: Die Unterstützung von npm für Trusted Publishing, das im Juli 2025 eingeführt wurde, beseitigt die Notwendigkeit, API-Token in CI/CD-Systemen vollständig zu verwalten. Stattdessen können CI/CD-Anbieter (wie GitHub Actions) direkt die Identität des Publishers bestätigen, und npm verifiziert diese Bestätigung. Dies ist der Goldstandard, da er das Token als Geheimnis in Ihrer Build-Pipeline eliminiert.
Der Übergang hat zwar einige Workflow-Unterbrechungen für Entwickler verursacht, die an ältere Praktiken gewöhnt sind. Die Abschaffung von TOTP 2FA zugunsten von FIDO-basierter 2FA (wie WebAuthn/Passkeys) ist ebenfalls ein bedeutender Schritt, da phishingresistente Authentifizierung gegenüber ausgeklügelten Angriffen nachweislich TOTP überlegen ist. Während einige Entwickler den Wechsel zu Passkeys aufgrund der Gerätekompatibilität als schwierig empfinden könnten, sind die Sicherheitsvorteile unbestreitbar.
Für diejenigen, die von CI aus veröffentlichen, wird empfohlen, npm publish --provenance mit Trusted Publishers-Konfiguration zu verwenden, wodurch die Notwendigkeit expliziter Token in Ihrer CI-Umgebung vollständig umgangen wird. Für lokales Publishing stellen Sie sicher, dass Ihre 2FA auf dem neuesten Stand ist und phishingresistent ist.
Jenseits von npm audit: Die sich entwickelnde Landschaft der Dependency-Scanning
npm audit ist seit 2018 ein fester Bestandteil und erledigt einen ordentlichen Job bei der Kennzeichnung bekannter Schwachstellen in Ihrem Abhängigkeitsbaum, indem es die npm Public Advisories Database überprüft. Und obwohl es eine schnelle, integrierte Möglichkeit ist, Probleme zu identifizieren, haben jüngste Ereignisse seine Grenzen aufgezeigt. Ein npm audit funktioniert nur bei bekannten Schwachstellen. Es erkennt keine neuartigen Malware, subtile Supply-Chain-Angriffe, die legitime Pakete modifizieren, oder Schwachstellen in Ihrem eigenen Code.
Der Wurm "Shai-Hulud" beispielsweise kompromittierte Pakete und veröffentlichte sie mit Malware neu. Während npm audit die neuen bösartigen Versionen möglicherweise erkennen würde, wenn Advisories veröffentlicht werden, kann sich die anfängliche Verbreitung schnell vollziehen. Dies unterstreicht die Notwendigkeit eines mehrschichtigen Ansatzes.
Hier glänzen spezialisierte Tools wirklich. Lösungen wie Snyk und SonarQube gehen viel tiefer. Snyk bietet beispielsweise eine Echtzeit-Schwachstellenerkennung in Abhängigkeiten, eine kontinuierliche Überwachung und sogar automatisierte Pull-Requests zur Anwendung von Korrekturen. SonarQube, während es einen breiteren Umfang für die Codequalität hat, bietet auch eine umfassende Sicherheitsanalyse für JavaScript und Node.js, die Builds unterbrechen kann, wenn Sicherheitsgrenzwerte nicht erfüllt werden.
Die Integration dieser Tools in CI/CD-Pipelines ist nicht mehr ein "Nice-to-have", sondern ein "Must-have". Eine typische Einrichtung könnte Folgendes umfassen:
- Pre-Commit-Hooks: Ausführen grundlegender Linter und statischer Analyse, um offensichtliche Probleme frühzeitig zu erkennen.
- CI-Build-Schritt: Ausführen von
npm auditfür eine schnelle Überprüfung, aber vor allem Integration eines robusten SCA (Software Composition Analysis)-Tools wie Snyk oder eines SAST (Static Application Security Testing)-Tools wie SonarQube. - Post-Deployment-Überwachung: Kontinuierliches Scannen von bereitgestellten Anwendungen und ihren Abhängigkeiten auf neu entdeckte Schwachstellen.
Die Realitätsprüfung ist, dass npm audit zugänglich ist, aber eine Basislinie darstellt. Sich 2025 ausschließlich darauf zu verlassen, ist wie das Mitbringen eines Buttermessers zu einem Schusswechsel. Die kommerziellen und fortschrittlichen Open-Source-Tools erfordern zwar mehr Einrichtung und möglicherweise Kosten, bieten aber die Tiefe, die erforderlich ist, um moderne Anwendungen wirklich zu sichern.
Laufzeitsicherheit neu gedacht: Denos Berechtigungen und JSRs Vision
Während npm der dominierende Paketmanager für Node.js ist, erlebt das breitere JavaScript-Ökosystem eine faszinierende Entwicklung in Bezug auf Laufzeiten, wobei Deno und Bun die Hegemonie von Node.js herausfordern. Was aufregend ist, ist, wie ihre Philosophien die Sicherheit beeinflussen. Das Verständnis der Unterschiede zwischen Node.js, Deno, Bun in 2025: Choosing Your JavaScript Runtime ist jetzt eine Voraussetzung für eine sichere Architektur.
Deno: Sicherheit geht vor
Deno, erstellt vom Node.js-Gründer Ryan Dahl, hat Sicherheit von Grund auf integriert. Im Gegensatz zu Node.js, das Skripten standardmäßig uneingeschränkten Zugriff auf das System gewährt, arbeitet Deno mit einem sandkastenartigen Berechtigungsmodell. Das bedeutet, dass ein Deno-Programm nicht ohne explizite Erlaubnis auf das Dateisystem, das Netzwerk oder Umgebungsvariablen zugreifen kann.
Um beispielsweise Netzwerkzugriff und das Lesen aus dem Dateisystem zu ermöglichen, würden Sie Ihr Deno-Skript mit Flags ausführen:
deno run --allow-net --allow-read app.ts
Dieses explizite Berechtigungsmodell ist ein Game-Changer für die Verhinderung von Supply-Chain-Angriffen, bei denen bösartige Pakete oft versuchen, Daten zu exfiltrieren oder das Hostsystem zu kompromittieren. Wenn eine kompromittierte Abhängigkeit versucht, Daten von einer nicht autorisierten Domäne abzurufen oder sensible Dateien zu lesen, wird Deno dies einfach verweigern, es sei denn, Sie haben diese Erlaubnis explizit erteilt.
JSR: Ein neues Registry für modernes JavaScript
JSR (JavaScript Registry), das im März 2024 in der öffentlichen Beta eingeführt wurde, ist Denos Antwort auf ein modernes Paket-Registry. JSR soll npm nicht forken, sondern auf seinem Erfolg aufbauen, ESM, native TypeScript-Unterstützung und einen Fokus auf Sicherheit und Entwicklererfahrung nutzen.
Eines der herausragenden Sicherheitsmerkmale von JSR ist "sicheres, tokenloses Publishing". Ähnlich wie npm's Trusted Publishing zielt JSR darauf ab, Supply-Chain-Angriffe zu verhindern, indem die Notwendigkeit langfristiger Token während des Publishing-Prozesses beseitigt wird. JSR konzentriert sich auch auf die vollständige Provenance für veröffentlichte Pakete und stellt so überprüfbare Build-Informationen sicher.
Bun: Geschwindigkeit mit sich entwickelnder Sicherheit
Bun, der neue Player, der in Zig entwickelt wurde, priorisiert in jedem Aspekt rohe Geschwindigkeit: Laufzeitausführung, Paketinstallation, Bündelung und Tests. Während Bun unglaublich schnell ist und npm-Kompatibilität bietet, ist sein Sicherheitsmodell derzeit eher dem von Node.js ähnlich, mit standardmäßig uneingeschränktem Zugriff.
Der schnelle Entwicklungszyklus von Bun deutet jedoch darauf hin, dass in Zukunft möglicherweise explizitere Sicherheitsfunktionen hinzugefügt werden. Wenn Sie die unglaubliche Leistung von Bun nutzen, ist es entscheidend, Ihre Sicherheit mit robustem Dependency-Scanning und CI/CD-Sicherheitsvorkehrungen zu verstärken, da seine native Sandboxing nicht so ausgereift ist wie die von Deno.
Die entscheidende Rolle von package-lock.json und SRI: Integrität, die Sie nicht ignorieren können
Die Datei package-lock.json ist viel mehr als nur eine Liste mit festgelegten Versionen; sie ist ein kryptografisches Manifest Ihres Abhängigkeitsbaums. Ihr Feld integrity enthält insbesondere einen Subresource Integrity (SRI)-Hash, typischerweise SHA512, für jedes Paket. Dieser Hash ist ein eindeutiger Fingerabdruck des Paketinhalts, wie er ursprünglich im Registry veröffentlicht wurde.
Wenn Sie npm install (oder npm ci in CI/CD, was für die Reproduzierbarkeit sehr empfehlenswert ist) ausführen, lädt npm das Paket herunter, berechnet seinen Hash neu und vergleicht ihn mit dem integrity-Wert in Ihrer package-lock.json. Wenn sie nicht übereinstimmen, schlägt die Installation fehl und signalisiert eine mögliche Manipulation. Dies ist unsere erste und oft kritischste Verteidigungslinie gegen böswillige Akteure, die Pakete im Registry oder während des Transports modifizieren.
Dieser Mechanismus ist jedoch nicht narrensicher gegen alle Supply-Chain-Angriffe. Der Angriffvektor "Lockfile Poisoning" demonstriert dies: Wenn ein Angreifer die Kontrolle über das Konto eines Maintainers erlangt, kann er eine bösartige Version eines Pakets veröffentlichen und dann die package-lock.json im legitimen Repository mit dem neuen, bösartigen Integrity-Hash aktualisieren. Wenn diese kompromittierte package-lock.json committet wird und dann npm install oder npm ci ausgeführt wird, wird das bösartige Paket installiert, da der Integrity-Hash mit der Version des Angreifers übereinstimmt.
Aus diesem Grund ist npm provenance als zusätzliche Verteidigungsschicht so entscheidend, da es beweist, wer das Paket veröffentlicht hat und wie es erstellt wurde. Es fügt eine "Wahrheitsquelle" über den Hash hinaus hinzu.
Entwickler sollten immer:
package-lock.jsoncommitten: Dies gewährleistet deterministische Installationen und stellt die Integrity-Hashes zur Überprüfung bereit.package-lock.json-Diffs in PRs überprüfen: Achten Sie auf unerwartete Änderungen, insbesondere an Paketversionen oder Integrity-Hashes, die auf einen böswilligen Akteur hindeuten könnten, der versucht, eine kompromittierte Abhängigkeit einzuschleusen.- Sicherstellen, dass SHA-512 verwendet wird: Ältere
package-lock.json-Dateien verwenden möglicherweise SHA-1, das kryptografisch schwach und anfällig für Kollisionsangriffe ist. Moderne npm-Versionen verwenden standardmäßig SHA-512, aber wenn Sie an einem älteren Projekt arbeiten, kann eine neuenpm installnach dem Löschen vonnode_modulesundpackage-lock.json(und dann dem Committen der neuen Datei) diese Hashes aktualisieren.
# Um eine Aktualisierung auf SHA512 zu erzwingen (mit Vorsicht verwenden, Änderungen nach dem Commit!)
rm -rf node_modules package-lock.json
npm install
Verteidigung gegen Lifecycle-Script-Angriffe: Die stille Bedrohung
Eine der leistungsstärksten – und gefährlichsten – Funktionen von npm-Paketen sind Lifecycle-Skripte. Dies sind beliebige Shell-Befehle, die in package.json (z. B. preinstall, install, postinstall, prepack, prepare) definiert sind und in verschiedenen Phasen des Paketinstallations- oder Publishing-Prozesses ausgeführt werden. Während sie unglaublich nützlich für die Kompilierung, Einrichtung oder das Erstellen nativer Module sind, sind sie auch ein erstklassiger Vektor für Supply-Chain-Angriffe.
Ein bösartiges postinstall-Skript kann beispielsweise nach der Installation eines Pakets beliebigen Code auf der Maschine eines Benutzers ausführen. Dies kann von dem Stehlen von Umgebungsvariablen und Anmeldeinformationen bis hin zur Installation zusätzlicher Malware reichen. Die Typosquatting-Angriffe im Oktober 2025, die mehrstufige Infostealer verwendeten und versteckte Terminals starteten, um Systempasswörter und Browser-Cookies zu extrahieren, nutzten stark Postinstall-Skripte.
Die Verteidigung dagegen erfordert einen vielschichtigen Ansatz:
--ignore-scripts-Flag: Für Produktionsbereitstellungen oder beim Überprüfen neuer Abhängigkeiten kann das Ausführen vonnpm install --ignore-scriptsverhindern, dass diese Skripte ausgeführt werden. Dies ist eine entscheidende Sicherheitsmaßnahme, insbesondere in CI/CD-Umgebungen, in denen Sie die Ausführungsoberfläche minimieren möchten.npm install --ignore-scripts # Oder über Umgebungsvariable für globale Wirkung NPM_CONFIG_IGNORE_SCRIPTS=true npm install- Sorgfältige Überprüfung von
package.json: Wenn Sie neue Abhängigkeiten hinzufügen, inspizieren Sie immer derenpackage.jsonauf verdächtige Lifecycle-Skripte. Wenn ein einfaches Utility-Paket ein komplexespostinstall-Skript hat, ist das ein Warnsignal. - Sandboxed Environments: Das Ausführen von
npm installin sandboxed Environments oder Containern kann den Schadensradius eines bösartigen Skripts begrenzen. - Statische Analyse: Erweiterte Sicherheitstools können oft verdächtige Muster in Lifecycle-Skripten erkennen.
Der Weg nach vorn: Ein widerstandsfähigeres Ökosystem
Wenn wir auf 2024 und 2025 zurückblicken, ist klar, dass das JavaScript-Paket-Ökosystem durch den Wind gegangen ist, aber es geht stärker daraus hervor. Die jüngsten Angriffe waren zwar schmerzhaft, haben aber die Akzeptanz kritischer Sicherheitsfunktionen beschleunigt. Wir bewegen uns auf Folgendes zu:
- Stärkere Identität & Provenance:
npm provenanceund Sigstore sind Game-Changer und bieten überprüfbare Verbindungen vom veröffentlichten Paket zurück zur Quelle und zum Build. Dies verlagert das Vertrauen von "Ich hoffe, das ist gut" zu "Ich kann überprüfen, dass dies wie erwartet erstellt wurde". - Gehärtete Publishing-Workflows: Obligatorische 2FA, kurzlebige Token und Trusted Publishing erschweren es Angreifern, Maintainer-Konten zu kompromittieren und bösartigen Code einzuschleusen. Dies ist eine praktische, robuste Verteidigung gegen Phishing.
- Anspruchsvolles Scanning: Während
npm auditweiterhin nützlich ist, führt die zunehmende Abhängigkeit von fortschrittlichen SCA- und SAST-Tools, die tief in den SDLC integriert sind, zu einer Erkennung sowohl bekannter als auch neuartiger Bedrohungen. - Laufzeitsicherheit auf neuem Niveau: Denos integriertes Sicherheitsmodell und JSRs sicherheitsorientiertes Registry verschieben die Grenzen dessen, was in einer sicheren JavaScript-Umgebung möglich ist. Dies sind nicht nur "Alternativen", sondern "Innovationen", die das gesamte Ökosystem beeinflussen werden.
Wir sind jedoch noch nicht aus dem Schneider. Der schiere Umfang des npm-Ökosystems (allein 2024 4,5 Billionen Anfragen) macht es zu einem Hauptziel. Die Akzeptanz dieser neuen Sicherheitsfunktionen ist nicht universell, und Legacy-Projekte werden weiterhin Herausforderungen darstellen. Die Entwicklererfahrung kann immer noch umständlich sein, wenn neue Sicherheitsmaßnahmen integriert werden, und die Dokumentation für einige experimentelle Funktionen (wie Node.js's experimentelles Permissions Model, das sich noch weiterentwickelt) kann spärlich sein.
Meine Meinung? Nehmen Sie diese Veränderungen mit Begeisterung an. Integrieren Sie npm publish --provenance in Ihre CI/CD. Fordern Sie phishingresistente 2FA für Ihr Team. Verlassen Sie sich nicht nur auf npm audit; investieren Sie in tiefergehendes Scanning. Überprüfen Sie package-lock.json und denken Sie zweimal darüber nach, bevor Sie Lifecycle-Skripte aus unbekannten Quellen aktivieren. Das JavaScript-Ökosystem ist widerstandsfähiger denn je, aber seine Stärke hängt letztendlich von unserer kollektiven Wachsamkeit und unserer Bereitschaft ab, diese praktischen, effizienten Sicherheitsmaßnahmen zu ergreifen. Wir bauen die Zukunft, und es sicher zu machen, ist unsere gemeinsame Verantwortung.
Quellen
🛠️ Related Tools
Erkunden Sie diese DataFormatHub-Tools, die sich auf dieses Thema beziehen:
- JSON Formatter - Format package.json
- Hash Generator - Überprüfen Sie die Paketintegrität