NPM-Sicherheit: Angriffe auf die Software-Lieferkette verhindern

NPM-Sicherheit ist in den letzten Jahren häufig Thema in den Medien gewesen – meist mit Bezug auf npm-Pakete im Ökosystem und weniger auf die npm-Registry selbst. Das zunehmende Sicherheitsrisiko für Entwickler und die von uns entwickelte Software macht es umso wichtiger, zu verstehen, wie Sie Angriffe auf die Software-Lieferkette verhindern und andere Sicherheitslücken im Softwareentwicklungslebenszyklus vermeiden können.

Angriffe auf die Software-Lieferkette treten in vielen Formen auf – etwa als Dependency-Confusion-Angriffe, durch das Einschleusen von Backdoors mit Schadcode in Open-Source-Pakete oder durch die Kompromittierung der Build-Pipeline-Infrastruktur. Die Sicherheitsrisiken in Open-Source-Bibliotheken und Ökosystemen stellen eine unmittelbare Bedrohung für Entwickler dar.

Welche Software-Sicherheitskontrollen können wir einsetzen, um unsere Sicherheitslage zu verbessern? In diesem Beitrag stelle ich Ihnen npm-Sicherheitspraktiken und Tools zur Absicherung der Software-Lieferkette vor, die Ihnen als JavaScript-Entwickler zur Verfügung stehen (auch TypeScript-Entwickler sind willkommen).

Der aktuelle Stand von Angriffen auf die Software-Lieferkette im Jahr 2022

Es gibt immer mehr Belege dafür, dass Entwickler eine Schlüsselrolle für die Anwendungssicherheit spielen. Entwickler sind maßgeblich an der Entstehung von Sicherheitsvorfällen beteiligt, etwa beim peacenotwar-Modul, dem Dependency-Confusion-Angriff auf gmx-reference und den Dependency-Confusion-Angriffen mit Cobalt Strike – nur einige Beispiele für aktuelle npm-Sicherheitsmeldungen.

Wie viele npm-Abhängigkeiten und unterschiedliche Maintainer haben Ihre Projekte Ihrer Einschätzung nach? Eine am 7. Juni 2019 veröffentlichte wissenschaftliche Studie lieferte interessante Erkenntnisse zu diesem Thema:

Bei der Installation eines durchschnittlichen npm-Pakets vertrauen Sie implizit 79 Paketen von Drittanbietern und 39 Maintainerinnen und Maintainer – dadurch entsteht eine überraschend große Angriffsfläche.

Akteure, die sich auf Angriffe auf die Software-Lieferkette konzentrieren, finden immer wieder neue Wege, in ein Ökosystem einzudringen und dort Malware zu platzieren. Ein gutes Beispiel dafür ist ein aktueller Sicherheitsforschungsbericht aus dem Jahr 2021, der Folgendes aufdeckte:

2.818 E-Mail-Adressen von Maintainerinnen und Maintainer waren mit abgelaufenen Domains verknüpft. Dadurch hätte ein Angreifer 8.494 Pakete kapern können, indem er die npm-Konten übernommen hätte. […] Wir stellten fest, dass 58,7 % der Pakete und 44,3 % der Maintainer in der npm-Registry inaktiv sind.

Trotz dieser Bedenken leistet Open-Source-Software einen wichtigen Beitrag zu vielen innovativen Technologien und hilft Unternehmen, Geschäftsergebnisse schneller zu erzielen. So sehr Open-Source-Software ein Geschenk an die Welt ist: Es ist dennoch wichtig, auf die Risiken von Softwarebibliotheken von Drittanbietern und deren potenzielle Auswirkungen hinzuweisen, wenn sie in unsere Anwendungen eingebunden werden.

Was ist die Sicherheit der Software-Lieferkette?

Entwickler betrachten die Sicherheit der Open-Source-Software-Lieferkette häufig im Zusammenhang mit direkten Berührungspunkten, etwa den npm-Paketen, die wir installieren (npm install event-stream) und in unsere Projekte importieren (import colors). Die Angriffsfläche der Software-Lieferkette ist jedoch viel größer.

Was ist ein Angriff auf die Software-Lieferkette?

In der Softwareentwicklung liegt ein Angriff auf die Software-Lieferkette vor, wenn Angreifer Malware, Backdoors oder andere Angriffskomponenten in Softwarekomponenten oder die zugehörige Infrastruktur einschleusen, die anschließend zur Entwicklung anderer funktionsfähiger Software verwendet werden. Mit anderen Worten: Angreifer greifen keine Schwachstellen im Quellcode der Zielsoftware direkt an und suchen dort auch nicht danach.

Die Supply-chain Levels for Software Artifacts, kurz SLSA, bieten eine gute Orientierung zu anfälligen Integrationspunkten, an denen Risiken lauern. Die folgende Darstellung stammt aus dem Whitepaper von Snyk zur Sicherheit der Software-Lieferkette:

Wenn wir uns ansehen, wie wir heute Software entwickeln, erkennen wir viele vertraute Meilensteine, die tatsächlich einer realen Bedrohungslage ausgesetzt sind. Der folgende Artikel im Sicherheitsblog von Google zeigt anhand mehrerer Beispiele reale Sicherheitsvorfälle an den einzelnen Meilensteinen der Softwarebereitstellung.

NPM-Sicherheit und vorbeugende Maßnahmen zur Absicherung der Software-Lieferkette

(1) Einschleusen in NPM-Lockfiles verhindern

Im September 2019 veröffentlichte ich meine Sicherheitsforschung, in der ich die grundlegenden Sicherheitsrisiken von Package-Lockfiles im npm-Ökosystem beschrieb. Sowohl Yarn als auch npm, zwei JavaScript-Paketmanager, erwiesen sich als anfällig.

Die Sicherheitsbedrohung entsteht, wenn Angreifer Zugriff erhalten und Änderungen am Quellcode beitragen können – etwa über Pull Requests, wie sie auf GitHub häufig zur Mitarbeit an Open-Source-Projekten verwendet werden. In diesem Fall könnten sie ein Lockfile wie package-lock.json oder yarn.lock ändern, um eine neue npm-Paketabhängigkeit hinzuzufügen oder einfach die Quell-URL eines bestehenden Pakets zu ersetzen. Jeder Aufruf zur Paketinstallation (etwa npm install oder yarn install) würde dann die betreffende Malware herunterladen.

Der folgende Screenshot zeigt, wie ich über einen Pull Request, den ich für ein Open-Source-Paket auf npm erstellt habe, ein schädliches Paket eingeschleust habe. Sehen Sie genau hin – erkennen Sie es?

Vielleicht gehen Sie gerade die folgende Checkliste durch:

• Die von mir hinzugefügten Pakete sind im Ökosystem bekannt und frei von Schwachstellen – geprüft.

• Es gibt keine Typosquatting-Versuche in diesen Paketnamen – geprüft.

• Es handelt sich um gültige Versionen dieser Pakete, die an sich nicht schädlich sind – geprüft.

Trotzdem würden Sie den Angriff kaum entdecken.

Versuchen Sie, die Datei yarn.lock zu vergrößern. Das Lockfile eines Paketmanagers wird maschinell generiert und ist nicht dafür gedacht, von Menschen gelesen oder gepflegt zu werden. Dadurch sind Änderungen wie die folgende schädliche Ergänzung, die ich eingeschleust habe, nur sehr schwer zu entdecken:

Darüber hinaus ermöglichen JavaScript-Paketmanager die Installation von Paketen aus sehr ungewöhnlichen Quellen, etwa einem GitHub-Gist oder direkt aus einem Quellcode-Repository.

Das bedeutet, dass ich das Lockfile einfach ändern und einen neuen Quellort angeben kann (etwa im Schlüssel resolved), über den ich als Angreifer die volle Kontrolle habe. Außerdem kann ich den SHA512-Integritätswert entsprechend festlegen, sodass kein Alarm ausgelöst wird.

Wird dieser Pull Request zusammengeführt, erhält der nächste Projektmitarbeiter, der yarn install ausführt, effektiv mein schädliches Paket. Tatsächlich muss ein Entwickler nicht einmal mit dem Projekt interagieren – denn viele etablierte Open-Source-Projekte verfügen über eine Continuous-Integration-Umgebung (CI).

Sehr wahrscheinlich wird schon nach dem Erstellen des Pull Requests automatisch ein Build gestartet, der auf GitHub Actions (oder vielleicht CircleCI) ausgeführt wird. Beim Erstellen dieses Pull Requests wird der npm-Installationsprozess ausgelöst. Dabei kann ich möglicherweise auf sensible Informationen wie CI-Umgebungsgeheimnisse, API-Schlüssel und mehr zugreifen und sie stehlen.

Um diese Art von Lockfile-Injection-Angriff zu verhindern, können Sie lockfile-lint verwenden. Mit lockfile-lint können Entwickler ihre Lockfiles auf Fehler prüfen und sicherstellen, dass diese maschinell generierten Snapshots der festgelegten Abhängigkeiten einer bestimmten Vertrauensrichtlinie entsprechen.

Sie können lockfile-lint beispielsweise so konfigurieren, dass der Prozess fehlschlägt, wenn das Lockfile yarn.lock Quellen für npm-Pakete enthält, die nicht vom offiziellen yarnpkg.org-Mirror installiert werden:

Zusammenfassung der vorbeugenden Maßnahmen gegen dieses potenzielle Sicherheitsrisiko:

1. Verwenden Sie lockfile-lint in Ihrer Entwicklungsumgebung und in Ihrer CI.

2. Erlauben Sie externen Mitwirkenden nicht, das Lockfile zu ändern.

3. Verwenden Sie automatisierte Bots für Dependency-Upgrades, die das Lockfile auf automatisierte und vertrauenswürdige Weise für Sie aktualisieren (sie beziehen Pakete aus der offiziellen Registry). Ein Hinweis: Der Snyk-Bot übernimmt das für Sie.

(2) Beliebige Befehlsausführung verhindern

Hoffentlich ist es kein Geheimnis, dass der Befehl npm install dazu führen kann, dass installierte Pakete während der Installation beliebige Befehle ausführen.

Wenn Sie zu einem bestimmten Zeitpunkt den folgenden Befehl ausgeführt hätten:

1npm install @vue/cli

Dann wären Sie Opfer des Angriffs über das npm-Paket node-ipc geworden. Dabei änderte der Maintainer sein Paket so, dass Befehle ausgeführt wurden, die Dateien in Ihrem Desktop-Ordner erstellten. In anderen Versionen des npm-Pakets node-ipc ging der Maintainer noch weiter und ließ unter anderem Dateien auf Ihrer Festplatte durchsuchen und vollständig löschen.

Abhängigkeiten können beliebige Befehle ausführen, weil der npm-Paketmanager im Rahmen der Installation einer Abhängigkeit einen install-Lifecycle-Hook bereitstellt. Meist nutzen Modul-Maintainer ihn aus legitimen Gründen – etwa um Installationsartefakte vorzubereiten, Ressourcendateien abzurufen oder nach der Installation aufzuräumen. Er kann auch für die Cross-Kompilierung nativer Modulbindungen verwendet werden, die auf dem Hostsystem kompiliert werden müssen, auf dem sie installiert werden.

Die zuvor erwähnte Studie What are Weak Links in the npm Supply Chain? liefert Erkenntnisse zur Verwendung von Installations-Hooks im Ökosystem:

Wir stellten fest, dass 2,2 % (33.249) der Pakete Installationsskripte verwenden. Das deutet darauf hin, dass sich 97,8 % der Pakete an die npm-Empfehlung halten könnten, aus Sicherheitsgründen auf Installationsskripte zu verzichten.

Zusammenfassung der vorbeugenden Maßnahmen, die Sie ergreifen sollten:

1. Ergänzen Sie den Befehl npm install um das Flag --ignore-scripts, damit die Ausführung beliebiger Befehle durch npm-Paketabhängigkeiten übersprungen wird.

2.  Ziehen Sie in Betracht, dieses Flag in die Konfigurationsdatei .npmrc Ihres Projekts aufzunehmen, damit auch andere Entwickler, die mit Ihnen am Projekt arbeiten, geschützt sind.

3. Beachten Sie, dass mit diesem Flag möglicherweise legitime Anwendungsfälle von npm-Paketen nicht mehr ausgeführt werden können und der npm-Installationsprozess fehlschlagen kann.

4. Beachten Sie, dass das Flag --ignore-scripts nicht für Pakete gilt, die aus lokalen Dateien installiert werden, oder wenn ein npm-Paket aus einem Git-Repository installiert wird.

(3) Keine unüberlegten NPM-Paket-Upgrades durchführen

Manche Entwickler aktualisieren im Rahmen eines Continuous-Integration-Prozesses (CI) ausdrücklich alle Abhängigkeiten auf die neuesten Versionen. Sie führen dazu Tests und Testfälle für den Happy Path aus, um sicherzustellen, dass ihre Anwendungen auch nach der Veröffentlichung neuer Abhängigkeitsversionen weiterhin wie erwartet funktionieren. So stellen sie die Vorwärtskompatibilität sicher und verhindern, dass eine Anwendung dadurch beeinträchtigt wird.

Sie können auf die neueste npm-Version aktualisieren, indem Sie folgenden Befehl ausführen:

1npm update

Oder Sie verwenden das dafür vorgesehene npm-Paket:

1npx npm-check-updates -u

Auch wenn es gute Gründe für solche unüberlegten npm-Paket-Upgrades gibt, können sie potenzielle Sicherheitsvorfälle begünstigen. Wie wir gerade erfahren haben, ist die Ausführung von npm install mit erheblichen Risiken verbunden.

Unüberlegte Upgrades Ihrer Abhängigkeiten bergen das grundlegende Sicherheitsrisiko, sich unnötig Bedrohungen auszusetzen – etwa Dependency-Confusion-Angriffen und anderen Vorfällen, von denen wir in den vergangenen Jahren erfahren haben, wie dem Sicherheitsvorfall mit colors oder dem Sicherheitsvorfall mit node-ipc.

Vorbeugende Maßnahmen, mit denen Sie Ihre Abhängigkeiten aktuell halten:

1. Verwenden Sie ein intelligentes Tool zur automatisierten Aktualisierung von Abhängigkeiten. Solche Tools verfügen häufig über integrierte Funktionen zur automatischen Aktualisierung von Manifesten und Lockfiles.

2. Prüfen Sie das Changelog und die Release-Artefakte sorgfältig. Stellen Sie sicher, dass sich der Maintainer nicht geändert hat – oder dass es dafür einen guten Grund gibt. Achten Sie darauf, dass für die neue Version auch der zugehörige Quellcode verfügbar ist.

Besonders wichtig ist es, auf automatische Upgrades und das Risiko hinzuweisen, ein schädliches npm-Paket einzubinden. Snyk empfiehlt nicht, auf Versionen zu aktualisieren, die weniger als 21 Tage alt sind. So vermeiden Sie Versionen, die funktionale Fehler enthalten und anschließend wieder zurückgezogen werden, oder Versionen, die über ein kompromittiertes Konto veröffentlicht werden (dessen Inhaber die Kontrolle an jemanden mit böswilligen Absichten verloren hat).

Weitere Informationen dazu finden Sie in der Snyk-Dokumentation zum Aktualisieren von Abhängigkeiten mit automatisierten PRs.

(4) Dependency-Confusion-Angriffe verhindern

Dependency Confusion ist eine Angriffsart, bei der ein Paket erstellt und intern in einer Organisation über einen privaten Proxy oder Hosting-Dienst verwendet wird, der Paketname aber weiterhin zur Registrierung in der npm Registry verfügbar ist.

Leider sind lokale Tools schnell falsch konfiguriert. Zusammen mit der Funktionsweise des npm-Paketmanagers ergibt sich folgende Situation: Existiert ein Paket mit demselben Namen in der öffentlichen npm Registry und ist dort eine höhere Version verfügbar als die installierte, installiert npm diese.

Wenn ein Microsoft-Mitarbeiter nicht sorgfältig vorgegangen wäre oder sein npm-Paketmanager und interner Proxy-Server falsch konfiguriert gewesen wären, hätte dies zu einem Dependency-Confusion-Angriff führen können, der die interne Infrastruktur des Unternehmens infiltriert:

1npm install azure-core-tracing-samples-js

Tatsächlich besteht dasselbe Risiko auch dann, wenn Mitarbeiter diesen vertrauenswürdigen Befehl zum Aktualisieren von npm-Paketen ausführen:

1npm update

Der Grund dafür liegt in der Funktionsweise von Dependency-Confusion-Angriffen. Obwohl diese Methode 2021 als öffentliche Forschung offengelegt wurde, hat das Snyk-Sicherheitsteam Belege dafür gefunden, dass Bedrohungsakteure mit dieser Angriffsmethode die Infrastruktur von Unternehmen ins Visier nehmen. Außerdem hat der Sicherheitsforscher Nishant Jaint einen weiteren möglichen Angriffsvektor beschrieben: Dependency Confusion mithilfe von npm-Paketaliasen.

Um Dependency-Confusion-Angriffe zu erkennen und zu verhindern, können Sie das kostenlose Open-Source-Tool snync von Snyk verwenden. Hier sehen Sie ein Beispiel für die Ausführung:

1npx snync --directory ~/my-app --private “superlaser”
2
3Testing project at ~/my-app
4Reviewing your dependencies...
5
6Checking dependency: death-star-hyper-reactor
7   -> ⚠️ vulnerable
8Checking dependency: superlaser
9   -> ❌ suspicious

(5) npm-Sicherheit: Proaktiver Schutz vor Malware

Wahrscheinlich haben Sie schon einmal den Befehl npm install ausgeführt, um ein npm-Paket zu installieren, und dabei eine Ausgabe wie die folgende erhalten:

1$ npm install amp-html
2
3added 1166 packages from 1172 contributors and audited 39128 packages in 112.505s
4found 93911 high severity vulnerability

Das Problem dabei: Zwar wurden Sicherheitslücken in den Paketen gefunden, davon erfahren Sie jedoch erst, nachdem Sie diese anfälligen Pakete installiert haben. Was steckt im npm-Paket amp-html? Bevor wir darauf eingehen, sehen wir uns eine bessere Möglichkeit an, Pakete zu installieren und die Kontrolle zurückzugewinnen.

Stellen Sie sich vor, Sie könnten vor der Installation nützliche Informationen zum Zustand Ihrer Abhängigkeiten sammeln und dann fundiert entscheiden, ob Sie das npm-Paket zu Ihrem Projekt hinzufügen oder auf npmjs.org „weiter suchen“.

Hier möchte ich Ihnen mein Open-Source-Projekt npq vorstellen. Mit npq können Sie proaktive Sicherheitsmaßnahmen ergreifen und anhand von Signalen fundiert entscheiden, ob Sie ein Paket installieren möchten – etwa danach, ob das Projekt eine README-Datei, eine Lizenz und ein zugehöriges GitHub-Repository hat.

Das Tool npq ist vollständig in Snyk integriert. Wenn Sie sich für ein kostenloses Konto registrieren, erkennt es das in Ihrer Umgebung verfügbare Snyk-API-Token und fragt die Snyk Vulnerability Database ab.

In meiner Entwicklungsumgebung habe ich den Befehl npm wie folgt als Alias für npq definiert:

1alias npm=npq

Wenn ich jetzt npm install ausführe, ruft der Befehl tatsächlich npq auf, um zunächst Prüfungen durchzuführen und das Paket zu validieren. Wenn ich fortfahren möchte, übergibt npq den Vorgang an die npm-Paketmanager-CLI, damit die Installation weiterläuft:

Sie können npq auch installieren und als Ad-hoc-Tool zum Prüfen auf Sicherheitslücken verwenden:

1npq install amp-html

Eine weitere Möglichkeit, den Zustand der Abhängigkeiten von npm-Paketen einzuschätzen, ist Snyk Advisor. Mit diesem praktischen Tool können Sie nach npm-Paketen sowie nach Alternativen oder ähnlichen Paketen suchen und sich über deren Wartung und Sicherheitsstatus informieren.

So wird das npm-Paket amp-html in Snyk Advisor angezeigt:

(6) Trojan-Source-Angriffe

Trojan-Source-Angriffe lautet der Titel eines kürzlich veröffentlichten Sicherheitsforschungsartikels, der sich mit dem Problem unsichtbarer Schwachstellen im Quellcode befasst.

Hier sehen Sie einen Codeausschnitt aus einem Backend-Node.js-Projekt, das Teile des bereitgestellten Admin-Zugriffs auf eine bestimmte Seitenroute verwaltet. Darin ist tatsächlich ein Trojan-Source-Angriff enthalten. Entdecken Sie das Problem?

1module.exports = fastify => (req, res, next, access = {}) => {
2 if (!req.query.token && access.login) { // Redirect to login
3   return fastify.login.view(req, res);
4 }
5
6 // Debug login for issue #1812
7 if (req.session.user != "user‮ ⁦// Check if admin⁩ ⁦") {
8    console.log("You are an admin.");
9 }
10
11 if (!req.query.token) { // Private access without token.
12   return res.code(401).send(new Error('Missing token.'));
13 }
14
15 …

Ich aktiviere die JavaScript-Syntaxhervorhebung in meiner IDE, damit Sie den Ausschnitt leichter verstehen. Hier ist ein Screenshot des obigen Codes:

Achten Sie auf die zweite Bedingung zum Debug login for issue #1812. Um besser zu verstehen, was dort passiert, übertragen wir den Code in ein ausführbares Node.js-Skript:

1#!/usr/bin/env node
2
3const accessLevel = "user";
4
5 // Debug login for issue #1812
6 if (accessLevel != "user‮ ⁦// Check if admin⁩ ⁦") {
7    console.log("You are an admin.");
8 }

Wenn Sie diesen Code mit node test.js ausführen, wird die folgende Ausgabe angezeigt:

1You are an admin.

Aber warum? Sie fragen sich sicher schon, woran das liegt.

Der Grund ist, dass der obige Quellcodeausschnitt Steuerzeichen enthält. Diese sind auf den ersten Blick unsichtbar, verändern den tatsächlichen Quellcode jedoch grundlegend. Die Zeichen ändern die Leserichtung des Textes von links nach rechts und von rechts nach links. Dadurch entsteht beim Lesen durch einen Interpreter oder Compiler eine andere Bedeutung als beim unbemerkten Lesen mit dem menschlichen Auge.

Wie können Entwickler solche Probleme erkennen und verhindern, dass sie bei Code-Reviews übersehen werden, wenn Code zu ihrem Projekt beigetragen wird?

Wenn Sie Snyk Code zur Überwachung Ihres Quellcodes verwenden, meldet das Tool erkannte Sicherheitslücken wie SQL-Injection oder unsichere Code-Injections. Darüber hinaus meldet Snyk Code auch Probleme im Zusammenhang mit Trojan-Source-Angriffen im Code:

Auf der Projektübersichtsseite zeigt Snyk außerdem auf einen Blick die Trojan-Source-Schwachstelle zusammen mit den übrigen Schwachstellen an, die im Projekt gefunden wurden:

Zum Glück wurden Visual Studio Code und die GitHub-Plattform aktualisiert und zeigen jetzt visuelle Hinweise an, wenn Sie Quellcodedateien mit unsichtbaren Steuerzeichen aufrufen.

Ein weiteres Open-Source-Tool, mit dem sich Trojan-Source-Angriffe in JavaScript-Codebasen mithilfe von ESLint erkennen und eindämmen lassen, ist das ESLint-Plugin eslint-plugin-anti-trojan-source.

npm-Sicherheit: Wie geht es weiter?

Die Risiken für die Software-Supply-Chain-Sicherheit nehmen stetig zu. Und als wäre das nicht schon besorgniserregend genug, zielen Angriffe inzwischen gezielt auf Entwickler und ihre Ökosysteme ab.

Ich empfehle Ihnen sehr, auch diese Artikel zu lesen, um sich weiter über Best Practices für npm-Sicherheit und verwandte Themen zu informieren:

1. Schädliche Pakete und Supply-Chain-Angriffe mit Snyk verhindern von Daniel Berman.

2. Was ist eine Backdoor? Wir erstellen eine mit Node.js von Ulises Gascón

3. 10 Best Practices für npm-Sicherheit von Liran Tal und Juan Picado.

Wenn Sie sich über sicheres Programmieren informieren möchten, empfehle ich Ihnen außerdem eine der praxisorientierten Lektionen zur JavaScript-Sicherheit auf Snyk Learn. Sie sind kurz und völlig kostenlos!

Können npm-Pakete schädlich sein?

Die bedauerliche Wahrheit ist: npm-Pakete können tatsächlich schädlich sein. Mit verschiedenen Techniken wie Typosquatting-Angriffen oder Social Engineering, um eine Backdoor in event-stream einzuschleusen, lässt sich schädlicher Code einschleusen, der in der Entwicklerumgebung ausgeführt wird. Manche schädlichen Pakete gingen sogar auf Maintainer zurück, die ihre eigenen npm-Pakete mit schädlichem Code sabotierten – wie im Fall von node-ipc.

Wie können Sie die Sicherheit von npm-Paketen überprüfen?

Snyk entdeckt regelmäßig schädliche npm-Pakete und meldet sie, darunter auch mehr als 200 schädliche npm-Pakete. Um die Sicherheit von npm-Paketen zu überprüfen, können Sie mit Snyk Advisor den Zustand von Open-Source-Paketen bewerten oder mit der (kostenlosen) Snyk CLI und Repository-Integration nach schädlichen Paketen suchen und diese überwachen.

Welche Folgen können npm-Schwachstellen haben?

Sicherheitslücken in npm-Paketen können Ihre Anwendung beeinträchtigen und Sie erheblichen Risiken aussetzen. Wenn Sie eine ungepatchte Version des npm-Pakets websocket-extensions verwenden, sind Sie anfällig für Denial-of-Service-Angriffe durch reguläre Ausdrücke. Wenn Sie eine ungepatchte Version des npm-Pakets st verwenden, um mit Ihrer Node.js-Anwendung statische Dateien zu hosten und bereitzustellen, sind Sie anfällig für Directory-Traversal-Angriffe.