Wie viel wissen wir wirklich darüber, wie sich Pakete in der npm-Registry verhalten?
22. April 2019
0 Min. LesezeitIm Bericht „State of Open Source Security Report 2019“ haben wir die Details zum Wachstum sprachbasierter Paket-Repositorys in den vergangenen Jahren vorgestellt. Wie wir gezeigt haben, liegt npm jedes Jahr mit großem Abstand an der Spitze.
Zum Zeitpunkt der Veröffentlichung dieses Artikels umfasste npm mehr als 960.000 Pakete. Allein im Jahr 2018 kamen über 250.000 Pakete hinzu.
Haben Sie sich vor diesem Hintergrund schon einmal gefragt, wie viel Sie über das Verhalten von Paketen im npm-Ökosystem wissen? Wie viele Pakete sind miteinander verbunden?
Entdecken wir die größte Open-Source-Paket-Registry von heute!
In ihrer kürzlich veröffentlichten Forschungsarbeit untersuchen K. Vaidya, Ruturaj & De Carli, Lorenzo & Davidson, Drew & Rastogi, Vaibhav (2019) die Arbeit Security Issues in Language-based Sofware [sic] Ecosystems Sicherheitsangriffe auf sprachbasierte Open-Source-Repositorys wie npm und PyPI. Im Mittelpunkt stehen schädliche Pakete und die Frage, wie sich die besonderen Merkmale der jeweiligen Sprachökosysteme auf sie auswirken.
Ich fand die Studie sehr interessant und wollte einige ihrer Daten in Fragen umwandeln, die ich auf einer öffentlichen Plattform wie Twitter stellen kann. So wollte ich herausfinden, wie JavaScript-Entwicklerinnen und -Entwickler den Zustand von Paketen im npm-Ökosystem und deren Verbindungen zu anderen Paketen einschätzen.
Irrtümer über Pakete in der npm-Registry
Aus dieser Forschungsarbeit habe ich Datenpunkte zu den folgenden Fragen herausgearbeitet, die ich als allgemeine Umfrage veröffentlichen wollte:
Wie viel Prozent der Pakete auf npm haben weder Abhängigkeiten noch abhängige Pakete?
Wie groß ist die durchschnittliche Tiefe einer Paketabhängigkeitskette auf npm?
Wie viele Pakete auf npm könnte man als *aufgegeben betrachten? (* basierend auf einer Kennzahl wie dem Ausbleiben von Paketveröffentlichungen in den vergangenen zwölf Monaten)
Nachdem ich diese interessanten Fragen ausgewählt hatte, veröffentlichte ich Umfragen auf Twitter und sammelte die Antworten.
Verwaiste Pakete auf npm
Erste Frage: Wie viel Prozent der Pakete auf npm haben weder Abhängigkeiten noch abhängige Pakete?
959.567? auf npm
Wie viel Prozent der Pakete auf #npm haben weder Abhängigkeiten noch abhängige Pakete?#javascript #nodejs #npmjsBitte RT!— Liran Tal (@liran_tal) 15. April 2019
Die richtige Antwort lautet: 28 % der Pakete auf npm haben weder Abhängigkeiten noch abhängige Pakete.
Wie sich zeigt, glauben 66 % der Befragten, dass die npm-Registry ein stark verschlungenes Netz aus Paketverbindungen ist. Laut der Forschungsarbeit haben jedoch nur 28 % aller Pakete in der npm-Registry weder Abhängigkeiten noch abhängige Pakete – das wählten lediglich 7 % der Befragten.
Im PyPI-Repository steigt dieser Anteil auf 36 %.
Tiefe der Abhängigkeitsketten auf npm
Zweite Frage: Wie groß ist die durchschnittliche Tiefe einer Paketabhängigkeitskette auf npm?
#npmjs umfasst 961.600
Die durchschnittliche Tiefe einer Paketabhängigkeitskette auf npm beträgt:#javascript #nodejs #npmjsBitte RT!— Liran Tal (@liran_tal) 17. April 2019
Die richtige Antwort lautet: Die Paketabhängigkeitskette auf npm ist durchschnittlich 4,39 Pakete tief.
Dem Bericht zufolge ist der Abhängigkeitsbaum – gemessen an der Länge der längsten Abhängigkeitskette – durchschnittlich mehr als vier Pakete tief. Bei PyPI liegt dieser Wert dagegen nur bei 1,7.

Daraus können wir schließen, dass JavaScript-Entwicklerinnen und -Entwickler kleinere, wiederverwendbare Codeeinheiten bevorzugen und diese tatsächlich projektübergreifend wiederverwenden.
Aufgegebene Pakete auf npm
Dritte Frage: Wie viele Pakete auf npm könnte man als aufgegeben betrachten?
Noch eine letzte, interessante Umfrage!
Wie viele Pakete auf #npm könnte man als aufgegeben betrachten[1]?[1] basierend auf einer Kennzahl wie dem Ausbleiben einer Veröffentlichung in den vergangenen zwölf Monaten. Bitte RT. #javascript #nodejs #npmjs #opensource— Liran Tal (@liran_tal) 18. April 2019
Die richtige Antwort lautet: 61 % der Pakete auf npm haben in den vergangenen zwölf Monaten keine neue Version veröffentlicht.
Wie in früheren Forschungsarbeiten wurden aufgegebene Pakete in dieser Studie anhand ihrer Veröffentlichungsaktivität definiert. Anders gesagt: Ein Paket galt als aufgegeben, wenn seine Maintainerin oder sein Maintainer in den vergangenen zwölf Monaten keine neue Version veröffentlicht hatte.
Nicht mehr gepflegte Pakete von funktionsfertigen Paketen zu unterscheiden, die einfach einen Reifegrad erreicht haben, der keine weiteren Veröffentlichungen erfordert, ist keine leichte Aufgabe. Auch wenn manche diese Kennzahl infrage stellen mögen, sind die tatsächlichen Zahlen beeindruckend.
Laut Bericht hatten etwa 496.000 Pakete auf npm (von insgesamt rund 801.000 zum Zeitpunkt der Studie) in den vergangenen zwölf Monaten keine neue Version veröffentlicht. Das sind 61 % aller Pakete auf npm.
Im PyPI-Repository ist der Anteil ähnlich: 57 % aller Pakete hatten in den vergangenen zwölf Monaten keine neue Version.
Werden aufgegebene Pakete seltener heruntergeladen? Nicht wirklich.
Wie der Bericht außerdem zeigt, gehen die kumulierten Downloadzahlen in beiden Ökosystemen in die Milliarden.
Die folgende Grafik zeigt 20 der am häufigsten heruntergeladenen Pakete, die laut Bericht als aufgegeben gelten. Diese Pakete, darunter wordwrap und is-object, verzeichnen jährlich Hunderte Millionen Downloads.

Zusammenfassung
Mit dem Wachstum von Open-Source-Software können wir weitere Studien zu öffentlichen sprachbasierten Paket-Repositorys und deren Sicherheit erwarten.

Die Studie kommt zu folgendem Schluss:
Empfohlen werden Verbesserungen an Paket-Repositorys und Paketmanagern. Im Zusammenhang mit Typosquatting-Angriffen sollten Nutzerinnen und Nutzer beispielsweise gewarnt werden, wenn sie versehentlich Pakete installieren, die sie ursprünglich gar nicht installieren wollten.
Die Beschaffenheit dieser Ökosysteme legt nahe, dass sie „ein leichtes Ziel für Angriffe sind und die Zahl der Vorfälle in Zukunft nur weiter steigen wird“, wie es im Bericht heißt.
Nutzen Sie Open Source. Bleiben Sie sicher.
Starten Sie mit Capture-the-Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.
