Abschnitt 5 · Lektion 5
Ein Paket bewerten
Ein npm install dauert zwei Sekunden, und danach läuft fremder Code auf deinem Rechner, in deiner
Pipeline und auf deinem Server. Er darf alles, was dein Programm darf: Dateien lesen, ins Netz gehen,
deine Umgebungsvariablen sehen.
Deshalb lohnen sich zwei Minuten vorher. Nicht bei jedem Paket dieselbe Gründlichkeit, aber ein Blick.
Die Fragen, die in zwei Minuten zu beantworten sind
Wann war der letzte Commit? Ein Paket, an dem seit drei Jahren niemand gearbeitet hat, ist nicht automatisch schlecht. Kleine, fertige Werkzeuge brauchen keine Pflege. Bei etwas, das mit Netzwerk oder Verschlüsselung zu tun hat, ist derselbe Befund ein Warnzeichen.
Wie viele offene Fehlerberichte liegen wie lange? Interessant ist nicht die Zahl, sondern ob jemand antwortet.
Wie viele Abhängigkeiten bringt es mit?
npm view slugify name version license dependencies slugify bringt keine mit. Auf die Frage nach dependencies antwortet npm view mit gar nichts,
weil es dort nichts zu nennen gibt. Was du dir installierst, ist genau dieses eine Paket.
npm view express dependencies express bringt 28 direkte mit, und die bringen wieder eigene mit. In Lektion 5.4 hast du gesehen,
was daraus wird: 68 Pakete im Ordner.
Für einen Webserver ist das vertretbar, das Ding leistet auch einiges. Für eine Aufgabe, die du in zwanzig Zeilen selbst schreiben könntest, ist es ein schlechtes Geschäft. Jedes Paket in diesem Baum ist ein Konto, das übernommen werden kann, und ein Betreuer, der die Lust verlieren kann.
Wie viele Downloads, und passt die Zahl zum Alter? Ein zwei Wochen altes Paket mit zwei Millionen Downloads ist merkwürdig.
Sieht der Name einem bekannten verdächtig ähnlich? Das ist Typosquatting: lodahs statt lodash,
crossenv statt cross-env. Diese Pakete existieren wirklich, und sie warten auf Tippfehler. Prüf
den Namen bei einem npm install genauso wie bei einer Überweisung.
Was npm audit leistet und was nicht
npm audit vergleicht deinen Abhängigkeitsbaum mit einer Datenbank bekannter Sicherheitslücken
und sagt dir, welche davon dich betreffen.
Das ist nützlich und gehört in jede Pipeline. Aber die Grenze muss man kennen:
npm audit findet nur, was schon jemand gemeldet hat. Ein Paket, das gestern übernommen und mit
bösartigem Code neu veröffentlicht wurde, steht in keiner Datenbank. Da meldet npm audit fröhlich
„found 0 vulnerabilities”.
Genau so laufen die Angriffe, über die man in den Nachrichten liest: nicht über eine bekannte Lücke, sondern über ein übernommenes Betreuerkonto und eine frische Version. Zwischen Veröffentlichung und Entdeckung liegen manchmal Stunden, manchmal Wochen, und in dieser Zeit hilft dir kein Audit.
Der beste Schutz dagegen ist das Lockfile aus Lektion 5.4. Wer feste Versionen installiert, bekommt die frisch veröffentlichte Fassung gar nicht erst.
Die Faustregel
Je kleiner die Aufgabe, desto strenger die Prüfung. Ein Paket, das dir ein echtes Problem abnimmt, darf etwas mitbringen. Ein Paket, das eine Zeile Code ersetzt, sollte nichts mitbringen und am besten gar nicht erst installiert werden.
Und wenn du es doch nimmst: Bau eine eigene kleine Datei zwischen das Paket und deinen Code, so wie in Lektion 5.6. Dann kostet der Austausch später eine Datei und nicht zwanzig.
Ausführlicher steht das alles in einem Artikel auf mitmario.dev über vergiftete Repositories. Dort geht es um denselben Angriffsweg, nur eine Stufe früher: nicht das Paket, sondern das Projekt, aus dem du gerade etwas kopierst.
Warum es zu dieser Lektion keine Aufgabe gibt
Jede ehrliche Aufgabe zu diesem Thema müsste in die Registry und auf GitHub schauen. Wie alt ist der letzte Commit wirklich, wie viele Downloads sind es heute, wer sind die Betreuer.
Die Sandbox kann beides nicht, und das ist richtig so: Sie hat kein Netz, keine Sekunde lang. Eine Aufgabe, die stattdessen mit erfundenen Daten arbeitet, würde das Bewerten nur nachspielen.
Nimm stattdessen beim nächsten echten npm install zwei Minuten und geh die Fragen von oben durch.
Das ist die Übung zu dieser Lektion, und sie findet nicht hier statt.
Zum Mitnehmen
npm audit findet bekannte Lücken. Bösartigen Code, der gestern hochgeladen wurde, findet es nicht.
Jetzt du
Basis Konto, kostenlosIm Editor änderst du die Beispiele dieser Lektion und lässt sie gleich laufen. So merkst du am schnellsten, ob es sitzt.
Dafür brauchst du das Basis Konto. Es kostet nichts, und ein Passwort gibt es auch nicht.
In diesem Kurs läuft dein Code auf einem Server. Dafür hat das Basis Konto 1 Stunde im Monat, mehr Zeit gibt es mit dem Premium Konto.
Was in dieser Lektion steckt
-
Artikel mit 2 Beispielen zum Ausprobieren
Steht hier, ohne Konto lesbar.