Zum Hauptinhalt springen

Der Befehl „check“

Verwendung

Der Check-Befehl ist die zweite Säule von NDM. Er führt eine statische Analyse der Paketinformationen durch.

Wie wird er ausgeführt?​

Zuerst müssen Sie NDM installieren und anschließend den Check-Befehl ausführen:

ndm check

Sie werden nach einem Paketnamen gefragt. Nach der Eingabe eines gültigen Namens fragt NDM, welche Version Sie analysieren möchten. Sie können auch die neueste Version auswählen. Danach werden die Paketinformationen im Terminal angezeigt, und Sie müssen bestätigen, dass es sich um das richtige Paket handelt.

Sobald dieser Schritt erfolgreich abgeschlossen ist, beginnt die Überprüfung.

info

verwende

ndm check <package> <version>

als einen shortcut

Überprüfung (Check)​

NDM führt eine Reihe automatisierter Sicherheits- und Qualitätsprüfungen für npm-Pakete durch. Jede Prüfung basiert auf echten Metadaten aus der npm-Registry (registry.npmjs.org) und spiegelt typische Muster wider, die bei Vorfällen in der JavaScript-Lieferkette (Supply Chain) beobachtet wurden.

NDM implementiert derzeit zehn Prüfungen, die jeweils im Folgenden detailliert beschrieben werden.

Alter des Repositorys (Repository Age)​

NDM bewertet, wie lange ein Paket bereits in der npm-Registry existiert. Diese Prüfung nutzt das Feld time.created aus den Registry-Metadaten.

Viele schädliche Pakete, die auf npm hochgeladen werden, sind neu und dienen nur kurzfristigen Angriffszwecken. NDM weist diesen Paketen im Bereich repoAge eine „Warnstufe“ zu, wenn sie jünger als 22 Tage sind.

Letzte Aktualisierung (Last Update)​

NDM bewertet anhand des Feldes time.modified, wie kürzlich die ausgewählte Version geändert wurde.

Ist die ausgewählte Version weniger als zwei Tage alt, warnt NDM den Benutzer. Liegt das Alter der Version zwischen 21 und 51 Tagen, gibt NDM eine Warnung bezüglich eines möglichen Verlassens des Paketes oder ungepatchter Sicherheitslücken aus. Ist die Version älter als 50 Tage, markiert NDM das Paket im Bereich lastupdate als „kritisch“.

Dies ist wichtig, da neue Versionen oft noch nicht getestet wurden und schädliche Pakete meist innerhalb der ersten 48 Stunden entdeckt werden. Alte Pakete können zudem Sicherheitslücken enthalten.

Änderungen der Betreuer (Maintainer Changes)​

Abhängig von der Anzahl der vorhandenen Versionen prüft NDM, ob sich die Betreuer der ausgewählten Version von denen der vorangegangenen 5 bis 10 Versionen unterscheiden. Es sortiert die Versionen nach Zeitpunkten und vergleicht dann die ausgewählte Version mit den fünf bis zehn nächstälteren Versionen. NDM versucht zudem, schädliche Versionen zu identifizieren, indem es prüft, ob die Angaben zum Maintainer (Betreuer) unvollständig sind.

NDM vergleicht die Maintainer nicht über die gesamte Historie hinweg. Es vergleicht lediglich die ausgewählte Version mit ihren 5 bis 10 Vorgängerversionen.

Ein Wechsel der Maintainer deutet auf Folgendes hin:

  • Kompromittierung des Kontos
  • Eigentumsübertragung
  • Übernahme durch unbekannte Akteure

Ein Wechsel der Maintainer allein ist jedoch noch kein starkes Indiz für ein schädliches Paket. Es ist lediglich ein Teil des Puzzles.

Snyk-Schwachstellen​

NDM fragt die Snyk-Schwachstellendatenbank nach bekannten CVEs ab, die das Paket betreffen. Anschließend wird geprüft, ob die ausgewählte Version betroffen ist. Falls Schwachstellen gefunden werden, erfolgt eine entsprechende Ausgabe im Terminal.

Versionsspezifische Schwachstellen & Deprecation​

Versionsspezifische Metadaten werden aus der npm-Registry abgerufen. Das Paket wird auf den Status „deprecated“ (veraltet/nicht mehr unterstützt) sowie auf in der Registry verzeichnete Schwachstellen hin überprüft.

Dies ist wichtig, da wir alle verfügbaren Informationen über ein Paket nutzen müssen, anstatt uns nur auf eine einzige Quelle zu verlassen.

OSV-Sicherheitsinformationen​

NDM nutzt die Open Source Vulnerabilities (OSV)-Datenbank, um zu prüfen, ob eine Paketversion von bekannten Sicherheitsproblemen betroffen ist.

Für jedes Paket fragt NDM OSV ab und weist einen Schweregrad gemäß der folgenden Priorisierung zu:

  • malicious (schädlich), wenn das Paket von OSV als schädlich eingestuft ist
  • critical (kritisch), wenn der höchste gemeldete CVSS-Score bei 9,0 oder höher liegt
  • warning (Warnung), wenn eine Schwachstelle gemeldet wird
  • ok, wenn keine Schwachstellen gefunden werden

Beliebtheit​

Die Beliebtheit des ausgewählten Pakets wird anhand der Nutzung im letzten Monat bewertet.

Schwellenwerte:

  • Über 5.000.000 Downloads → ausgezeichnet
  • Über 500.000 Downloads → gut
  • Unter 10.000 Downloads → Warnung

Dies ist von Bedeutung, da bei Paketen mit geringer Beliebtheit weniger Nutzer den Code im Blick haben. Dies bedeutet jedoch nicht automatisch, dass ein Paket mit über 5.000.000 Downloads pro Monat sicher ist. So wurde beispielsweise auch Axios kompromittiert, obwohl es zu diesem Zeitpunkt etwa 100.000.000 Downloads pro Woche verzeichnete.

Erkennung von Typosquatting​

NDM prüft, ob der Paketname einem beliebten Paket verdächtig ähnlich ist. Zudem bewertet NDM Pakete mit ähnlichen Namen, die hohe Downloadzahlen aufweisen.

  • Über 500.000 Downloads pro Monat → ok
  • Über 50.000 Downloads pro Monat → Warnung
  • Andernfalls → kritisch

Typosquatting ist einer der häufigsten Angriffsvektoren bei NPM. Beispiele hierfür sind lodash und lodas.

Installationsskripte​

NDM prüft, ob das Paket Installationsskripte definiert, wie zum Beispiel:

  • preinstall
  • install
  • postinstall

NDM prüft lediglich das Vorhandensein von Installationsskripten. Der Inhalt der Skripte wird nicht analysiert.

Dies ist wichtig, da ein Installationsskript Folgendes tun kann:

  • beliebigen Code ausführen
  • Binärdateien herunterladen
  • Systemdateien verändern
  • Shell-Befehle ausführen

Dies ist ein Angriffsvektor mit hohem Risiko, der bei tatsächlichen Angriffen genutzt wird. NDM kennzeichnet jedes Installationsskript als potenzielle – nicht zwangsläufig als tatsächliche – Bedrohung.

Abhängigkeitsrisiko​

NDM bewertet die Anzahl der direkten Abhängigkeiten (dependencies) und direkten Entwicklungsabhängigkeiten (devDependencies), die ein Paket deklariert.

Schwellenwerte:

  • Über 80 → kritisch
  • Über 40 → Warnung
  • Unter 40 → ok

Jede Abhängigkeit stellt eine potenzielle Angriffsfläche dar. Derzeit prüft NDM nur direkte Abhängigkeiten, nicht den gesamten Abhängigkeitsbaum.

Paketgröße​

Die Größe des entpackten Pakets wird überprüft. Hierfür wird dist.unpackedSize verwendet.

Schwellenwerte:

  • Über 10.000.000 → kritisch (10 MB): Nur extrem große Frameworks oder Pakete, die Binärdateien enthalten, erreichen diese Größe. Alles, was darüber hinausgeht, ist höchst ungewöhnlich und könnte auf versteckte Payloads, verschleierten Code oder unnötige Dateien hinweisen.
  • Über 5.000.000 → Warnung (5 MB): Die meisten npm-Pakete sind kleiner als 1 MB. Große Frameworks wie Next.js, Angular und Prisma liegen im Bereich von 2–5 MB. Alles über 5 MB ist ungewöhnlich und sollte untersucht werden.
  • Darunter → ok: Dies ist der typische Bereich für 90 % aller npm-Pakete.

Dies ist wichtig, da große Pakete Folgendes verbergen können:

  • verschleierten Code
  • unnötige Binärdateien
  • schädliche Payloads

NDM stuft ungewöhnlich große Pakete als Hochrisiko-Pakete ein.

Bewertungen (Scores)​

Nach der Durchführung dieser Prüfungen berechnet NDM zwei Bewertungen (Scores).

Risikobewertung (Risk Score):​

Die Risikobewertung misst das potenzielle Sicherheitsrisiko auf der Grundlage der durchgeführten Prüfungen. Zur Berechnung des Werts werden die jeweiligen Stufen genutzt, um die Bewertung zu erhöhen oder zu verringern. Nicht alle Prüfungen führen zu denselben Abzügen oder Zuschlägen, da einige wichtiger sind als andere.

Gesundheitsbewertung (Health Score):​

Die Gesundheitsbewertung misst die Qualität des Pakets. Auch hierfür werden die Prüfungen herangezogen. Einigen Prüfungen wird hier jedoch eine andere Priorität eingeräumt als bei der Risikobewertung. Dies liegt daran, dass manche Prüfungen für das Sicherheitsrisiko wichtiger sind als für den Gesundheitszustand des Pakets.