10 Best Practices für npm-Sicherheit

Besorgen Sie sich wegen npm-Schwachstellen? Für Frontend- und Backend-Entwickler ist es wichtig, Best Practices für die npm-Sicherheit zu berücksichtigen. Prüfungen der Open-Source-Sicherheit sind ein entscheidender Bestandteil davon, Sicherheit frühzeitig in den Entwicklungsprozess zu integrieren. Auch die Sicherheit von npm-Paketen sollte höchste Priorität haben, denn selbst das offizielle npm-Befehlszeilentool wurde bereits als anfällig eingestuft.

In dieser Ausgabe unseres Spickzettels konzentrieren wir uns auf zehn Best Practices für npm-Sicherheit und Tipps zur Produktivität – für Open-Source-Maintainer und Entwickler. Legen wir also mit unserer Liste der 10 Best Practices für npm-Sicherheit los. Den Anfang macht ein klassischer Fehler: Passwörter werden in den veröffentlichten npm-Paketen abgelegt!

1. Veröffentlichen Sie keine Secrets in der npm-Registry

Ganz gleich, ob Sie API-Schlüssel, Passwörter oder andere Secrets verwenden: Sie können leicht in die Versionsverwaltung oder sogar in ein Paket gelangen, das in der öffentlichen npm-Registry veröffentlicht wird. Möglicherweise befinden sich Secrets in Ihrem Arbeitsverzeichnis in dafür vorgesehenen Dateien wie .env. Diese sollten Sie in eine .gitignore aufnehmen, damit sie nicht in ein SCM-Repository gelangen. Aber was passiert, wenn Sie ein npm-Paket aus dem Projektverzeichnis heraus veröffentlichen?

Die npm-CLI packt ein Projekt in ein tar-Archiv (Tarball), um es in die Registry hochzuladen. Welche Dateien und Verzeichnisse in den Tarball aufgenommen werden, hängt von den folgenden Kriterien ab:

• Wenn eine .gitignore- oder .npmignore-Datei vorhanden ist, werden deren Inhalte beim Vorbereiten des Pakets für die Veröffentlichung als Ausschlussmuster verwendet.

• Sind beide Ausschlussdateien vorhanden, wird alles, was nicht in .npmignore aufgeführt ist, in der Registry veröffentlicht. Diese Konstellation sorgt häufig für Verwirrung und kann dazu führen, dass Secrets offengelegt werden. Entwickler aktualisieren möglicherweise die Datei .gitignore, vergessen aber, auch .npmignore anzupassen. Dann wird eine potenziell vertrauliche Datei zwar nicht in die Versionsverwaltung übernommen, aber dennoch in das npm-Paket aufgenommen.

Eine weitere gute Vorgehensweise ist die Verwendung der Eigenschaft files in package.json. Sie dient als Positivliste und legt fest, welche Dateien in das zu erstellende und zu installierende Paket aufgenommen werden (während die Ausschlussdatei als Negativliste funktioniert). Die Eigenschaft files und eine Ausschlussdatei lassen sich gemeinsam verwenden, um festzulegen, welche Dateien ausdrücklich in das Paket aufgenommen beziehungsweise daraus ausgeschlossen werden sollen. Werden beide verwendet, hat die erstgenannte Eigenschaft, also files in package.json, Vorrang vor der Ausschlussdatei.

Bei der Veröffentlichung eines Pakets zeigt die npm-CLI ausführlich das erstellte Archiv an. Gehen Sie auf Nummer sicher und fügen Sie Ihrem Publish-Befehl das Argument --dry-run hinzu. So können Sie zunächst prüfen, wie der Tarball erstellt wird, ohne ihn tatsächlich in der Registry zu veröffentlichen.

Im Januar 2019 teilte npm in einem Blogbeitrag mit, dass ein Mechanismus hinzugefügt wurde, der ein Token automatisch widerruft, wenn erkannt wird, dass es zusammen mit einem Paket veröffentlicht wurde.

2. Erzwingen Sie die Verwendung der Lockdatei

Wir haben Lockdateien für Pakete begeistert begrüßt. Sie ermöglichen deterministische Installationen in unterschiedlichen Umgebungen und stellen sicher, dass die erwarteten Abhängigkeiten bei der Zusammenarbeit im Team verwendet werden. Alles bestens! Dachte ich zumindest … Was wäre passiert, wenn ich eine Änderung in die package.json-Datei des Projekts übernommen, aber vergessen hätte, die Lockdatei ebenfalls zu committen?

Yarn und npm verhalten sich bei der Installation von Abhängigkeiten gleich. Wenn sie eine Abweichung zwischen der package.json des Projekts und der Lockdatei feststellen, gleichen sie diese anhand des Manifests package.json aus und installieren andere Versionen als die in der Lockdatei erfassten.

Eine solche Situation kann in Build- und Produktionsumgebungen gefährlich sein: Es könnten unbeabsichtigte Paketversionen eingebunden werden, wodurch der gesamte Nutzen einer Lockdatei verloren geht.

Zum Glück können Sie sowohl Yarn als auch npm anweisen, die in der Lockdatei festgelegten Abhängigkeiten und Versionen zu verwenden. Bei jeder Abweichung wird die Installation abgebrochen. Der Befehl lautet:

• Wenn Sie Yarn verwenden, führen Sie yarn install --frozen-lockfile aus.

• Wenn Sie npm verwenden, führen Sie npm ci aus.

3. Minimieren Sie die Angriffsfläche, indem Sie Run-Scripts ignorieren

Die npm-CLI unterstützt Package-Run-Scripts. Wenn Sie schon einmal npm start oder npm test ausgeführt haben, haben Sie auch Package-Run-Scripts verwendet. Die npm-CLI basiert auf Skripten, die ein Paket deklarieren kann. So können Pakete Skripte definieren, die während der Installation eines Pakets in einem Projekt an bestimmten Einstiegspunkten ausgeführt werden. Einige dieser Skript-Hooks können beispielsweise postinstall-Skripte sein, die ein installiertes Paket ausführt, um Aufräumarbeiten zu erledigen.

Mit dieser Funktion können Angreifer Pakete erstellen oder verändern, um bei der Installation beliebige Befehle für böswillige Zwecke auszuführen. Beispiele dafür sind der bekannte Vorfall mit eslint-scope, bei dem npm-Tokens abgegriffen wurden, und der Vorfall mit crossenv sowie 36 weiteren Paketen, die einen Typosquatting-Angriff auf die npm-Registry ausnutzten.

Befolgen Sie diese Best Practices für npm-Sicherheit, um die Angriffsfläche durch schädliche Module zu minimieren:

Prüfen Sie Module von Drittanbietern, die Sie installieren, stets sorgfältig und nehmen Sie eine angemessene Due-Diligence-Prüfung vor, um ihren Zustand und ihre Vertrauenswürdigkeit zu bestätigen.

• Aktualisieren Sie nicht blind auf neue Versionen. Warten Sie, bis neue Paketversionen eine Weile verfügbar sind, bevor Sie sie ausprobieren.

• Prüfen Sie vor dem Upgrade das Änderungsprotokoll und die Versionshinweise für die neue Version.

• Fügen Sie beim Installieren von Paketen das Suffix --ignore-scripts hinzu, um die Ausführung von Skripten durch Drittanbieterpakete zu deaktivieren.

• Erwägen Sie, ignore-scripts in die Projektdatei .npmrc oder in Ihre globale npm-Konfiguration aufzunehmen.

4. Prüfen Sie den Zustand Ihres npm-Projekts

Veraltete Abhängigkeiten

Abhängigkeiten ständig auf die neuesten Versionen zu aktualisieren, ist nicht unbedingt sinnvoll, wenn Sie dabei nicht die Versionshinweise und Codeänderungen prüfen und neue Upgrades nicht umfassend testen. Gleichzeitig ist es ebenfalls problematisch, veraltete Abhängigkeiten beizubehalten und sie gar nicht oder erst nach langer Zeit zu aktualisieren.

Die npm-CLI kann Informationen dazu liefern, wie aktuell Ihre Abhängigkeiten im Verhältnis zu ihren Versionsbereichen gemäß Semantic Versioning sind. Führen Sie npm outdated aus, um zu sehen, welche Pakete veraltet sind:

„Abhängigkeiten in Gelb entsprechen der semantischen Versionierung, die im package.json-Manifest angegeben ist. Rot dargestellte Abhängigkeiten weisen auf ein verfügbares Update hin. Außerdem zeigt die Ausgabe die neueste Version jeder Abhängigkeit an.“

Rufen Sie den Arzt

Bei der Vielzahl von Node.js-Paketmanagern und den verschiedenen Node.js-Versionen, die möglicherweise in Ihrem Pfad installiert sind: Wie überprüfen Sie, ob Ihre npm-Installation und Arbeitsumgebung einwandfrei funktionieren? Ganz gleich, ob Sie die npm-CLI in einer Entwicklungsumgebung oder in einer CI-Umgebung nutzen – es ist wichtig, sicherzustellen, dass alles wie erwartet funktioniert.

Rufen Sie den Arzt! Die npm-CLI enthält ein Tool zur Zustandsprüfung, mit dem Sie Ihre Umgebung diagnostizieren und die ordnungsgemäße Verwendung von npm überprüfen können. Führen Sie npm doctor aus, um Ihre npm-Konfiguration zu überprüfen:

• Prüft, ob die offizielle npm-Registry erreichbar ist, und zeigt die aktuell konfigurierte Registry an.

• Prüft, ob Git verfügbar ist.

• Überprüft die installierten npm- und Node.js-Versionen.

• Führt Berechtigungsprüfungen für verschiedene Ordner durch, etwa für lokale und globale node_modules-Ordner sowie für den Ordner, der als Paket-Cache dient.

• Prüft die lokale npm-Modul-Cache auf korrekte Prüfsummen.

5. Prüfen Sie Open-Source-Abhängigkeiten auf Schwachstellen

Das npm-Ökosystem ist die größte Sammlung von Anwendungsbibliotheken unter allen Ökosystemen für Programmiersprachen. Die Registry und die darin enthaltenen Bibliotheken sind für JavaScript-Entwickler von zentraler Bedeutung: Sie können die Arbeit anderer nutzen und in ihre Codebasis integrieren. Die zunehmende Verwendung von Open-Source-Bibliotheken in Anwendungen erhöht jedoch auch das Risiko, Sicherheitslücken einzuführen.

Bei vielen beliebten npm-Paketen wurden Schwachstellen festgestellt. Ohne angemessene Sicherheitsprüfungen Ihrer Projektabhängigkeiten können sie ein erhebliches Risiko darstellen. Beispiele dafür sind npm request, superagent, mongoose und sogar sicherheitsbezogene Pakete wie jsonwebtoken und npm validator.

Sicherheit endet nicht damit, bei der Installation eines Pakets lediglich nach Schwachstellen zu suchen. Damit sie während des gesamten Softwareentwicklungszyklus wirksam umgesetzt wird, muss sie auch in Entwickler-Workflows eingebunden werden. Zudem muss der Code nach der Bereitstellung kontinuierlich überwacht werden.

Auf Schwachstellen prüfen

Befolgen Sie Best Practices für npm-Sicherheit und prüfen Sie mit Snyk auf Schwachstellen. Verwenden Sie dazu:

npm install -g snyk
snyk test

Bei einem Snyk-Test meldet Snyk die gefundenen Schwachstellen und zeigt die betroffenen Abhängigkeitspfade an. So können Sie den Abhängigkeitsbaum nachverfolgen und herausfinden, welches Modul eine Schwachstelle eingeführt hat. Besonders wichtig: Snyk bietet konkrete Empfehlungen zur Behebung. Sie können auf eine gepatchte Version aktualisieren – über einen automatischen Pull Request, den Snyk in Ihrem Repository erstellt – oder einen von Snyk bereitgestellten Patch anwenden, um die Schwachstelle zu entschärfen, falls noch keine Korrektur verfügbar ist. Snyk empfiehlt ein intelligentes Upgrade und schlägt für das anfällige Paket das kleinstmögliche semantische Versions-Upgrade vor.

Überwachen Sie Open-Source-Bibliotheken auf neu entdeckte Schwachstellen

Die Sicherheitsarbeit endet hier nicht.

Was ist mit Sicherheitslücken, die erst nach der Bereitstellung einer Anwendung in ihren Abhängigkeiten entdeckt werden? Genau hier zeigt sich, wie wichtig Sicherheitsüberwachung und eine enge Integration in den Entwicklungszyklus des Projekts sind.

Wir empfehlen, Snyk in Ihr Quellcodeverwaltungssystem (SCM) wie GitHub oder GitLab zu integrieren, damit Snyk Ihre Projekte aktiv überwacht und:

• automatisch Pull Requests erstellt, um anfällige Abhängigkeiten für Sie zu aktualisieren oder zu patchen

• Open-Source-Bibliotheken auf Schwachstellen prüft und solche erkennt, die durch einen Pull Request eingeführt worden sein könnten

Wenn Sie Snyk nicht in ein SCM integrieren können, lassen sich auch Momentaufnahmen Ihrer Projekte überwachen, die über das Snyk-CLI-Tool übermittelt werden. Führen Sie dazu einfach Folgendes aus:

snyk monitor

Wie unterscheidet sich Snyk von npm audit?

1. Wir empfehlen Ihnen, einen Blogbeitrag von Nearform zu lesen, der die Unterschiede zwischen npm audit und Snyk vergleicht.

2. Die Schwachstellendatenbank von Snyk bietet über ihr Threat-Intelligence-System umfassende Informationen zu Schwachstellen. Sie sorgt für eine größere Abdeckung und kann Schwachstellen erkennen und melden, für die noch keine CVE vergeben wurde. So wurden beispielsweise 72 % der Schwachstellen in den npm-Sicherheitshinweisen zuerst in der Snyk Open Source-Schwachstellendatenbank erfasst.

6. Verwenden Sie einen lokalen npm-Proxy

Die npm-Registry ist die größte verfügbare Paketsammlung für JavaScript-Entwickler und zugleich die Heimat der meisten Open-Source-Projekte für Webentwickler. Manchmal haben Sie jedoch besondere Anforderungen an Sicherheit, Bereitstellung oder Leistung. In diesem Fall können Sie bei npm zu einer anderen Registry wechseln:

Wenn Sie npm install ausführen, stellt npm automatisch eine Verbindung zur Haupt-Registry her, um alle Abhängigkeiten aufzulösen. Wenn Sie eine andere Registry verwenden möchten, geht das ganz einfach:

1. Legen Sie mit npm set registry eine Standard-Registry fest.

2. Verwenden Sie das Argument --registry, um eine Registry nur für einen einzelnen Befehl festzulegen.

Verdaccio ist eine einfache, schlanke private Registry, die keine Konfiguration erfordert. Die Installation ist ganz einfach:

npm install --global verdaccio

Noch nie war es so einfach, eine eigene Registry zu hosten! Sehen wir uns die wichtigsten Funktionen dieses Tools an:

• Es unterstützt das npm-Registry-Format einschließlich Funktionen für private Pakete, Scope-Unterstützung, Paket-Zugriffskontrolle und authentifizierte Benutzer in der Weboberfläche.

• Es bietet die Möglichkeit, Remote-Registries einzubinden und Abhängigkeiten an unterschiedliche Registries weiterzuleiten sowie Tarballs zwischenzuspeichern. Um doppelte Downloads zu vermeiden und Bandbreite auf Ihren lokalen Entwicklungs- und CI-Servern zu sparen, sollten Sie alle Abhängigkeiten über einen Proxy leiten.

• Standardmäßig verwendet es htpasswd zur Authentifizierung, unterstützt aber auch Gitlab, Bitbucket und LDAP. Sie können auch Ihren eigenen Anbieter verwenden.

• Die Skalierung ist mit einem anderen Speicheranbieter ganz einfach.

• Wenn Ihr Projekt auf Docker basiert, ist die Verwendung des offiziellen Images die beste Wahl.

• Damit lassen sich Testumgebungen sehr schnell starten. Außerdem ist es praktisch, um große Monorepo-Projekte zu testen.

Die Ausführung ist ganz einfach:

verdaccio --config /path/config --listen 5000

Wenn Sie verdaccio als lokale private Registry verwenden, sollten Sie eine Konfiguration für Ihre Pakete einrichten, die Veröffentlichungen in der lokalen Registry erzwingt und versehentliche Veröffentlichungen in einer öffentlichen Registry durch Entwickler verhindert. Fügen Sie dazu Folgendes zu package.json hinzu:

“publishConfig”: {
  “registry”: "https://localhost:5000"
}

Ihre Registry läuft – ja! Um jetzt ein Paket zu veröffentlichen, verwenden Sie einfach den npm-Befehl npm publish. Schon können Sie es mit der Welt teilen.

7. Sicherheitslücken verantwortungsvoll offenlegen

Werden Sicherheitslücken entdeckt, können sie eine ernsthafte Bedrohung darstellen, wenn sie ohne vorherige Warnung oder geeignete Schutzmaßnahmen für die Nutzer öffentlich gemacht werden.

Sicherheitsforscher sollten ein Responsible-Disclosure-Programm befolgen. Dabei handelt es sich um eine Reihe von Prozessen und Richtlinien, die Forscher mit dem Anbieter oder Maintainer des betroffenen Assets zusammenbringen sollen, damit sie die Sicherheitslücke, ihre Auswirkungen und ihre Relevanz mitteilen können. Sobald die Sicherheitslücke korrekt bewertet wurde, stimmen Anbieter und Forscher eine Fehlerbehebung und einen Veröffentlichungstermin ab. So erhalten betroffene Nutzer die Möglichkeit, ein Upgrade durchzuführen oder die Lücke zu beheben, bevor das Sicherheitsproblem öffentlich bekannt wird.

Sicherheit ist zu wichtig, um sie nachträglich zu berücksichtigen oder unethisch zu behandeln. Bei Snyk schätzen wir die Security-Community sehr und sind überzeugt, dass die verantwortungsvolle Offenlegung von Sicherheitslücken in Open-Source-Paketen dazu beiträgt, die Sicherheit und den Datenschutz der Nutzer zu gewährleisten.

Das Security-Research-Team von Snyk arbeitet regelmäßig mit der Community zusammen, zum Beispiel bei Bug-Bounty-Programmen wie im Fall von f2e-server, der zu Hunderten von Meldungen aus der Community führte. Auch pflegt Snyk eine enge Partnerschaft mit akademischen Forschern, etwa mit Virginia Tech. So stellen wir Sicherheitsexpertise bereit und können uns mit Anbietern und Community-Maintainern abstimmen.

Wir laden Sie zur Zusammenarbeit ein und unterstützen Sie gerne beim Offenlegungsprozess:

• Melden Sie Sicherheitslücken verantwortungsvoll unter https://snyk.io/vulnerability-disclosure oder per E-Mail an security@snyk.io

• Unsere Offenlegungsrichtlinie finden Sie hier.

8. Aktivieren Sie 2FA

Im Oktober 2017 kündigte npm offiziell die Unterstützung der Zwei-Faktor-Authentifizierung (2FA) für Entwickler an, die die npm-Registry zum Hosten ihrer geschlossenen und Open-Source-Pakete nutzen.

Obwohl die npm-Registry 2FA schon seit einiger Zeit unterstützt, wird die Funktion offenbar nur langsam angenommen. Ein Beispiel dafür ist der Vorfall mit eslint-scope Mitte 2018: Ein gestohlenes Entwicklerkonto aus dem ESLint-Team führte dazu, dass Angreifer eine manipulierte Version von eslint-scope veröffentlichten.

** DRINGENDE SICHERHEITSWARNUNG ** Bitte teilen.

Heute wurde festgestellt, dass Version 3.7.2 von eslint-scope (https://t.co/Gkc9XhDRN6) schädlichen Code enthält, der Ihre NPM-Zugangsdaten stiehlt. Ergreifen Sie sofort Maßnahmen, wenn Sie Version 3.7.2 verwenden.

Snyk-DB-Eintrag: https://t.co/dAhhA3cZQP

— Snyk (@snyksec) 12. Juli 2018

2FA zu aktivieren, ist eine einfache und wirkungsvolle Maßnahme für mehr npm-Sicherheit. Die Registry unterstützt zwei Modi zur Aktivierung von 2FA für ein Benutzerkonto:

• Nur Autorisierung – wenn sich ein Benutzer über die Website oder die CLI bei npm anmeldet oder andere Aktionen ausführt, etwa Profilinformationen ändert.

• Autorisierung und Schreibzugriffe – Aktionen am Profil und bei der Anmeldung sowie Schreibaktionen wie die Verwaltung von Tokens und Paketen; außerdem eingeschränkte Unterstützung für Informationen zur Sichtbarkeit von Teams und Paketen.

Richten Sie eine Authentifizierungs-App ein, etwa Google Authentication, die Sie auf einem Mobilgerät installieren können. Dann können Sie loslegen. Eine einfache Möglichkeit, den erweiterten 2FA-Schutz für Ihr Konto einzurichten, bietet die npm-Benutzeroberfläche. Dort lässt sich die Funktion ganz einfach aktivieren. Wenn Sie lieber mit der Befehlszeile arbeiten, können Sie 2FA auch mit einer unterstützten npm-Client-Version (>=5.5.1) aktivieren:

npm profile enable-2fa auth-and-writes

Folgen Sie den Anweisungen in der Befehlszeile, um 2FA zu aktivieren und Notfall-Authentifizierungscodes zu speichern. Wenn Sie 2FA nur für Anmeldungen und Profiländerungen aktivieren möchten, ersetzen Sie im obigen Code auth-and-writes durch auth-only.

9. Verwenden Sie npm-Author-Tokens

Jedes Mal, wenn Sie sich mit der npm-CLI anmelden, wird ein Token für Ihr Benutzerkonto erstellt, das Sie bei der npm-Registry authentifiziert. Mit Tokens lassen sich Aktionen rund um die npm-Registry einfach in CI- und automatisierten Abläufen ausführen, etwa der Zugriff auf private Module in der Registry oder das Veröffentlichen neuer Versionen während eines Build-Schritts.

Tokens lassen sich über die Website der npm-Registry und mit dem npm-Befehlszeilen-Client verwalten. So erstellen Sie beispielsweise mit der CLI ein schreibgeschütztes Token, das auf einen bestimmten IPv4-Adressbereich beschränkt ist:

npm token create --read-only --cidr=192.0.2.0/24

Um zu überprüfen, welche Tokens für Ihr Benutzerkonto erstellt wurden, oder Tokens im Notfall zu widerrufen, verwenden Sie npm token list beziehungsweise npm token revoke.

Befolgen Sie diese npm-Sicherheitsmaßnahme: Schützen Sie Ihre npm-Tokens und minimieren Sie deren Offenlegung.

10. Machen Sie sich mit Namenskonventionen für Module und Typosquatting-Angriffen vertraut

Einen Modulnamen festzulegen, ist oft der erste Schritt beim Erstellen eines Pakets. Bevor Sie sich für einen Namen entscheiden, sollten Sie jedoch die Regeln von npm beachten, die Paketnamen erfüllen müssen:

• Maximal 214 Zeichen

• Darf nicht mit einem Punkt oder Unterstrich beginnen

• Keine Großbuchstaben im Namen

• Keine nachgestellten Leerzeichen

• Nur Kleinbuchstaben

• Einige Sonderzeichen sind nicht erlaubt: „~\’!()*”)’

• Darf nicht mit . oder _ beginnen

• node_modules und favicon.ico sind verboten

Auch wenn Sie diese Regeln einhalten, sollten Sie bedenken, dass npm beim Veröffentlichen neuer Pakete einen Spam-Erkennungsmechanismus verwendet. Dieser berücksichtigt einen Score und prüft, ob ein Paketname gegen die Nutzungsbedingungen verstößt. Bei Verstößen kann die Registry die Anfrage ablehnen.

Typosquatting ist ein Angriff, der sich Tippfehlern und anderen Versehen von Nutzern zunutze macht. Dabei veröffentlichen Angreifer schädliche Module in der npm-Registry, deren Namen beliebten vorhandenen Modulen zum Verwechseln ähnlich sehen.

Wir haben Dutzende schädliche Pakete im npm-Ökosystem verfolgt, die auch in der PyPI-Python-Registry aufgetaucht sind. Zu den bekanntesten Vorfällen zählen cross-env, event-stream und eslint-scope.

Ein wichtiges Ziel von Typosquatting-Angriffen sind Zugangsdaten, denn jedes Paket kann über die globale Variable process.env auf Umgebungsvariablen zugreifen. Ein weiteres Beispiel aus der Vergangenheit ist event-stream: Der Angriff hatte es auf Entwickler abgesehen und sollte schädlichen Code einschleusen, und zwar in den Quellcode einer Anwendung.

Zum Abschluss unserer Liste mit zehn npm-Sicherheitsmaßnahmen finden Sie hier einige Tipps, mit denen Sie das Risiko solcher Angriffe senken:

• Seien Sie besonders vorsichtig, wenn Sie Installationsanweisungen für Pakete in das Terminal kopieren. Überprüfen Sie im Quellcode-Repository und in der npm-Registry, ob es sich tatsächlich um das Paket handelt, das Sie installieren möchten. Mit npm info können Sie Paketmetadaten abrufen und weitere Informationen zu den Mitwirkenden und den neuesten Versionen erhalten.

• Arbeiten Sie im Alltag standardmäßig abgemeldet bei npm, damit Ihre Zugangsdaten nicht zur Schwachstelle werden, über die Ihr Konto leicht kompromittiert werden kann.

• Fügen Sie bei der Installation von Paketen --ignore-scripts hinzu, um das Risiko der Ausführung beliebiger Befehle zu senken. Zum Beispiel: npm install my-malicious-package --ignore-scripts

Drucken Sie den Spickzettel aus und hängen Sie ihn gut sichtbar auf. So erinnern Sie sich an einige der npm-Sicherheitsmaßnahmen, die Sie als JavaScript-Entwickler beachten sollten – oder wenn Sie einfach gerne npm verwenden.