Moderne Softwareprojekte bestehen meist aus Open-Source-Code. Die Entdeckung der Log4Shell-Schwachstelle wirft die äußerst sicherheitskritische Frage auf, wer diesen Code wirklich kontrolliert und wer für die Erkennung und Behebung von Sicherheitsproblemen in der Software-Lieferkette verantwortlich ist.
In einem Beispiel aus jüngerer Zeit wurden die sehr beliebten npm-Pakete absichtlich kompromittiert. Marak Squires, Entwickler der JavaScript-Bibliotheken Faker und Colors, führte Änderungen ein, die diese Pakete unbrauchbar machten und zum Aufhängen von Anwendungen führten, die eines dieser Pakete verwendeten. Der eingeführte Fehler war kosmetischer Natur und zieht lediglich die Notwendigkeit der Reparatur zahlreicher Tools nach sich, die nicht mehr funktionieren. Jedoch zeigt dieses Szenario ein tieferes und besorgniserregendes Problem. Genauso leicht hätte der Entwickler bösartigen Code einschleusen können, der auf Hunderttausenden von Rechnern ausgeführt worden wäre.
Die zutiefst beunruhigende Tatsache ist, dass unter vielen Umständen neuer Code aus einem Repository gezogen, in einem Projekt verwendet und auf dem Rechner ausgeführt werden kann, und zwar auf eine Weise, die für den Entwickler fast unsichtbar ist. Das Vertrauen in den Code aus öffentlichen Repositories ist bei vielen Paketmanagern tief verwurzelt, aber dieses Vertrauen ist möglicherweise fehl am Platz. Dieser Vorfall zeigt uns, wie Vertrauen, das jahrelang aufgebaut und etabliert wurde, eines Tages gebrochen werden kann, so dass selbst neue Versionen eines robusten Pakets nicht mehr vertrauenswürdig sind.
Das potenzielle Risiko bei der Installation von npm-Paketen
Die übliche Methode, um die Verwendung bestimmter Versionen der npm-Abhängigkeiten in einem Projekt zu konstituieren, ist die Verwendung der package-lock.json-Datei, die die erlaubten Versionen der Bibliotheken festlegt. Die Empfehlung lautet, package-lock.json zu verwenden und die genauen Versionen der Abhängigkeiten anzugeben, wann immer dies möglich ist. Es ist jedoch eine wenig bekannte Tatsache, dass das aktuelle npm-Installationsprogramm – wenn es ein Paket global installiert (npm wird mit -g oder -global ausgeführt) – die Datei package-lock.json nicht beachtet und arglos die neueste verfügbare Version jeder Paketabhängigkeit herunterlädt, entsprechend den in der Datei package.json angegebenen Abhängigkeiten. Das ist der Grund, warum Benutzer feststellen, dass ihre Anwendungen gekaperte Versionen des colors-Pakets verwenden, obwohl sie sicher waren, dass sie durch package-lock.json „geschützt“ waren.
Die Installation der neuesten Version eines npm-Pakets (einer Abhängigkeit) ohne vorherige Überprüfung kann gefährlich sein (z. B. wenn das Paket in seiner neuesten Version gekapert wurde, wie im Fall von Faker und Colors) und weil es den Code, der die Abhängigkeit nutzt, zerstören kann (z. B. aufgrund von API-Änderungen in der neuesten Version der Abhängigkeit).
Neu erschienene OSS-Tools für npm-Pakete
Als Reaktion auf Fälle wie die zuvor genannten, hat das JFrog Security Research Team drei OSS-Tools veröffentlicht, die darauf abzielen, die Installation von möglicherweise fehlerhaften npm-Paketen zu erkennen und zu verhindern:
- package_checker
Ein Tool, das einen Hinweis darauf gibt, ob einer bestimmten Version eines bestimmten Pakets vertraut werden kann. Das Tool sucht nach verräterischen Anzeichen für Pakete, die für Angriffe auf die Lieferkette verwendet werden. Es kann außerdem eingesetzt werden, um potenzielle Risiken mit neu veröffentlichten Versionen zu identifizieren.
- npm-secure-installer
Ein sicherer Wrapper für npm install, der sich weigert, Pakete global zu installieren, die keine npm-shrinkwrap Lock-Datei enthalten.
- package_issues_history
Ein experimentelles Tool, das darauf abzielt, problematische Paket-Aktualisierungen zu überwachen, um sie zu finden, noch bevor entdeckt wird, dass eine bestimmte Paketversion eine bösartige Änderung eingeführt hat. Bösartige Änderungen können auf unterschiedliche Weise auftreten, und abgesehen von extremen (und wahrscheinlich seltenen) Fällen ist es schwierig, eine Regel für solche Änderungen zu definieren, die nicht auch durch gutartige Änderungen ausgelöst werden.
Fazit
Die Sicherheitsforscher sehen in diesen Tools einen kleinen Schritt in die richtige Richtung, um kritische Probleme in der modernen Software-Lieferkette und gleichzeitig entsprechende Lösungswege aufzuzeigen. Zusätzlich zur Unterstützung der Entwickler-Community mit Informationen und Open-Source-Tools, um mit den neuesten Software-Sicherheitsbedrohungen umzugehen, bietet JFrog Entwicklern und Sicherheitsteams fortschrittliche Software-Supply-Chain-Sicherheitsfunktionen mit JFrog Xray.
