Sind Ihre Knotenmodule sicher?

Mit über 200k Paketen ist npm die weltweit größte Registrierung von Open-Source-Paketen. Jeden Monat werden dort mehrere Millionen Pakete heruntergeladen. Die Popularität von npm ist eine direkte Folge der Popularität von JavaScript. Ursprünglich war npm der Paketmanager für Node.js, die serverseitige JavaScript-Laufzeitumgebung. Da Node.js-Entwickler meist der Unix-Philosophie folgen, enthält die npm-Registry viele sehr kleine Bibliotheken, die auf einen bestimmten Zweck zugeschnitten sind. Seit der Einführung von Browserify sind viele dieser Bibliotheken plötzlich für die Verwendung im Webbrowser geeignet. Dadurch ist npm nicht nur der Paketmanager für Node.js, sondern für das gesamte JavaScript-Ökosystem geworden. Aus diesem Grund ist npm auch keine Abkürzung für Node Package Manager, sondern eine rekursive bacronymische Abkürzung für "npm ist kein Akronym". Wow. Wenn Sie ernsthaft JavaScript entwickeln, können Sie nicht ohne Bibliotheken auskommen, daher ist npm eine unverzichtbare Ressource. Jedes Projekt von nennenswerter Größe wird schnell auf mehrere Dutzend Bibliotheken angewiesen sein. Wenn man bedenkt, dass diese Bibliotheken oft selbst eine Handvoll Abhängigkeiten haben, hängt Ihre Anwendung indirekt von Hunderten von Paketen ab. Meistens klappt das ganz gut, aber manchmal ist es auch nicht so toll. Es stellt sich heraus, dass es eine ziemliche Herausforderung sein kann, all diese Abhängigkeiten auf dem neuesten Stand zu halten. Selbst wenn Sie Ihre Abhängigkeiten regelmäßig auf Aktualisierungen überprüfen, gibt es keine Garantie dafür, dass die Autoren Ihrer Abhängigkeiten dasselbe tun. Bei dem Tempo, in dem neue JavaScript-Pakete veröffentlicht werden, ist es nahezu unmöglich, alles immer auf dem neuesten Stand zu halten.

In den meisten Fällen ist es kein Problem, sich auf eine ältere Version eines Pakets zu verlassen. Wenn Ihr Paket mit einer veralteten Abhängigkeit gut funktioniert, gibt es keinen zwingenden Grund für ein Upgrade. Warum etwas reparieren, das nicht kaputt ist? Leider ist es nicht so einfach zu erkennen, ob es kaputt ist. Ihr Paket könnte ohne Ihr Wissen kaputt gegangen sein. Das Problem liegt in der Definition von "kaputt". Sie können darunter verstehen, dass Ihre Anwendung in irgendeiner Weise nicht funktioniert, aber was ist mit den Nicht-Funktionen? Haben Sie bedacht, dass Sie sich möglicherweise auf Pakete verlassen, die Sicherheitslücken in Ihr System einbringen? Wie jede Software sind auch Node.js und JavaScript nicht vor Sicherheitsproblemen gefeit. Man könnte sogar sagen, dass JavaScript aufgrund seiner dynamischen Natur von Natur aus weniger sicher ist. Das Node Security Project wurde gegründet, um dieses Problem zu lösen. Es führt eine Datenbank mit bekannten Sicherheitslücken im Node-Ökosystem und ermöglicht es jedem, diese zu melden. Obwohl NSP ein Kommandozeilen-Tool zur Verfügung stellt, mit dem Sie Ihre Abhängigkeiten auf Sicherheitslücken überprüfen können, hat ein neues Unternehmen namens Snyk vor kurzem ein Tool veröffentlicht, mit dem Sie das Gleiche und mehr tun können. Snyk, die Abkürzung für "so now you know", findet auf der Grundlage der NSP-Datenbank und anderer Quellen Sicherheitsschwachstellen in Ihrem gesamten Abhängigkeitsbaum. Das CLI-Tool ist unglaublich einfach zu installieren und zu verwenden. Einfach npm install snyk eingeben und los geht's. Sie können es gegen Ihr eigenes Projekt oder gegen jedes npm-Paket einsetzen: [code]

snyk test azure âœ- Sicherheitslücke gefunden auf validator@3.1.0 Info: https://app.snyk.io/vuln/npm:validator:20130705 Von: azure@0.10.6 > azure-arm-website@0.10.0 > azure-common@0.9.12 > validator@~3.1.0 Dieses Problem kann nicht durch ein direktes Abhängigkeitsupgrade behoben werden. Führen Sie snyk protect -i aus, um diese Sicherheitslücke zu schließen Alternativ können Sie auch ein manuelles Upgrade der tiefen Abhängigkeit validator@~3.1.0 auf validator@3.2.0 ... Ich habe Azure auf bekannte Sicherheitslücken getestet und 32 Sicherheitslücken gefunden. [/code] Es hat sich herausgestellt, dass die Node.js-Bibliothek für Azure nicht ganz sicher ist. Snyk kann die Sicherheitslücke automatisch für Sie patchen, aber die eigentliche Lösung besteht darin, das Paket azure-common zu aktualisieren, um die neuere Version von validator zu verwenden. Wie Sie sehen, sind die meisten der von Snyk gemeldeten Sicherheitsprobleme bereits von den Autoren der betroffenen Bibliothek behoben worden. Das ist der eigentliche Grund, warum Sie Ihre Abhängigkeiten auf dem neuesten Stand halten sollten. Ich betrachte Snyk als eine weitere Art der Code-Qualitätsprüfung. Genau wie Ihre Unit-Tests sollte auch Ihr Build fehlschlagen, wenn Sie versehentlich eine unsichere Abhängigkeit hinzugefügt haben. Eine wirklich einfache Möglichkeit, dies zu erzwingen, ist die Verwendung eines Pre-Commit-Hooks in Ihrer package.json: [code language="javascript"] "scripts": { "lint": "eslint src test", "snyk": "snyk test", "test": "mocha test/spec", }, "pre-commit": ["lint", "test", "snyk"] [/code] Der pre-commit-Hook wird automatisch ausgeführt, wenn Sie versuchen, eine Übergabe an Ihr Git-Repository durchzuführen. Er führt die angegebenen npm-Skripte aus und bricht die Übergabe ab, wenn eines von ihnen fehlschlägt. Beachten Sie bitte, dass Snyk standardmäßig nur Ihre Produktionsabhängigkeiten testet. Wenn Sie möchten, dass es auch Ihre devDependencies testet, können Sie es mit dem Flag --dev ausführen.