Stellen Sie sich vor, Sie geben einem völlig Fremden den Schlüssel zu Ihrer Wohnung. Er darf in jeden Schrank schauen, das Telefon benutzen und durch alle Schubladen gehen. Klingt unvorstellbar? Genau das tun Sie im Grunde jedes Mal, wenn Sie npm install eintippen. Sie holen sich Programmcode in Ihr Projekt, den ein Mensch geschrieben hat, den Sie noch nie getroffen haben, und dieser Code läuft anschließend mit allen Rechten, die Ihr Programm besitzt.

In diesem Artikel zeigen wir Ihnen Schritt für Schritt, wie Sie ein npm-Paket bewerten, bevor Sie es einbauen. Das Ganze dauert fünf bis zehn Minuten und ersetzt das schnelle Schielen auf die Anzahl der Sterne durch eine bewusste Entscheidung.

Warum jedes npm install ein kleines Vertrauensexperiment ist

Die meisten Entwicklerinnen und Entwickler verlassen sich auf zwei Zahlen: die wöchentlichen Downloads und die GitHub-Sterne. Das ist ungefähr so aussagekräftig, wie ein Restaurant nur danach zu beurteilen, wie voll der Parkplatz ist. Voll heißt nicht automatisch sauber, ehrlich oder gut gewartet.

Hinzu kommt eine reale Gefahr: sogenannte Supply-Chain-Angriffe. Bekannte Beispiele wie event-stream oder ua-parser-js zeigen ein wiederkehrendes Muster. Ein beliebtes, völlig harmloses Paket wird übernommen, etwa weil der Betreuer hereingelegt wurde oder weil sich ein Schädling tief in der Abhängigkeitskette versteckt. Sie selbst können alles richtig machen und werden trotzdem über ein Paket getroffen, das Sie nie direkt installiert haben.

Die neue Falle: erfundene Paketnamen

Seit KI-Assistenten beim Programmieren helfen, gibt es eine zusätzliche Spielart. Diese Werkzeuge erfinden manchmal Paketnamen, die plausibel klingen, aber gar nicht existieren. Angreifer beobachten diese Vorschläge und registrieren die Namen schnell selbst, man nennt das Slopsquatting. Folgen Sie dem Vorschlag ungeprüft, installieren Sie womöglich Schadcode.

Mein Rat: Schlägt Ihnen ein KI-Werkzeug ein Paket vor, das Sie noch nie gehört haben, prüfen Sie zuerst, ob es überhaupt eine echte Vergangenheit hat. Und wenn Sie KI-Werkzeuge automatisiert arbeiten lassen, verlassen Sie sich nicht auf "Daran denke ich schon", sondern auf eine technische Sperre, die unbekannte Pakete blockiert.

Schritt 0: Brauchen Sie das Paket überhaupt?

Bevor Sie irgendetwas prüfen, stellen Sie sich die einfachste Frage zuerst: Muss diese Abhängigkeit überhaupt sein?

Viele Vorfälle werden nicht deshalb gefährlich, weil ein einzelnes Paket so schlimm wäre, sondern weil ein winziges Hilfspaket über Dutzende Dienste hinweg kopiert wird, bis es überall steckt. Wird es dann kompromittiert oder plötzlich vom Netz genommen, ist Ihr Schaden nicht mehr klein.

Der gedankliche Entfernungstest

Spielen Sie kurz durch: Wäre das Paket morgen verschwunden, wie aufwendig wäre der Ersatz? Lautet die Antwort "Wir müssten das halbe Projekt umbauen", behandeln Sie es als Hochrisiko-Fall und schauen besonders genau hin.

Bei winzigen Helferlein lohnt eine zweite Frage: Können Sie dieselbe Funktion nicht in wenigen Zeilen selbst schreiben? Für eine einzige Hilfsfunktion eine ganze Abhängigkeit hereinzuholen, ist das langfristige Risiko oft nicht wert. Werfen Sie zusätzlich einen Blick darauf, wie viele weitere Pakete mitkommen. Wenige Abhängigkeiten bedeuten eine kleinere Angriffsfläche.

Wird das Paket aktiv gepflegt?

Ein ungepflegtes Paket ist wie ein Haus, in dem niemand mehr wohnt: Sicherheitslücken werden nicht geschlossen, die Kompatibilität bröckelt, und irgendwann sitzen Sie auf einer veralteten Version fest.

Woran Sie echte Pflege erkennen

Das offensichtliche Signal sind aktuelle Commits, aber Vorsicht, das täuscht leicht. Ein Commit von letzter Woche kann auch nur eine belanglose Anpassung an der Bauumgebung sein. Schauen Sie deshalb genauer hin:

• Issues-Tab auf GitHub: Sehen Sie sich die ältesten offenen Meldungen an. Hat jemand vor anderthalb Jahren einen Fehler gemeldet und nie eine Antwort bekommen? Das verrät Ihnen, wie die Betreuung im Ernstfall aussieht.
• Commits-Tab: Filtern Sie Bot- und Routine-Einträge heraus. Wann hat zuletzt ein Mensch eine echte Änderung am eigentlichen Programmcode vorgenommen?
• Wer macht die Arbeit? Stammt fast alles von einer einzigen Person, hängt Ihr Risiko an der Energie und Verfügbarkeit dieses einen Menschen. Das ist nicht automatisch schlecht, viele großartige Pakete werden von Einzelpersonen betreut –, aber Sie sollten es wissen.

Ein weiterer schöner Hinweis ist das Changelog. Listet es nur kryptische Versionsnummern auf, ist es nutzlos. Erklärt es dagegen verständlich, was sich geändert hat und warum, schreibt hier jemand, dem seine Nutzer am Herzen liegen.

Können Sie dem trauen, was auf npm liegt?

Die Wartung betrifft die Zukunft. Jetzt geht es um etwas Unmittelbareres: Ist das, was gerade auf npm liegt, wirklich das, was der Autor veröffentlichen wollte?

Standardmäßig gibt es keine Prüfung. Wenn Sie ein Paket installieren, vertrauen Sie darauf, dass die Bytes, die Sie erhalten, zum Quellcode auf GitHub passen. Beim event-stream-Vorfall 2018 wurde genau dieses Vertrauen ausgenutzt: Niemand hackte GitHub oder npm, die Angreifer bekamen schlicht die Zugangsdaten zum Veröffentlichen.

Das Provenance-Abzeichen als Echtheitssiegel

Die moderne Antwort darauf heißt Provenance. Stellen Sie es sich wie ein versiegeltes Echtheitszertifikat vor: Es verknüpft kryptografisch das ausgelieferte Paket mit einem bestimmten Commit in einem bestimmten Repository, gebaut von einem bestimmten Arbeitsablauf. Das lässt sich überprüfen, und es ist öffentlich.

So gehen Sie vor:

1. Öffnen Sie npmjs.com/package/<paketname>.
2. Achten Sie neben der Version auf ein grünes Provenance-Abzeichen.
3. Klicken Sie darauf und auf den Detail-Link. Dort sehen Sie Repository, Commit und den Arbeitsablauf, der das Paket veröffentlicht hat, alles nachklickbar.

Fehlt das Abzeichen, ist das nicht automatisch verdächtig (viele Pakete sind älter als diese Funktion), aber Sie können die Kette vom Quellcode zur Veröffentlichung dann nicht überprüfen. Auf der Kommandozeile hilft übrigens npm audit signatures: Der Befehl prüft die Signaturen aller installierten Pakete auf einen Schlag.

Vorsicht bei Install-Skripten

Eine Sache läuft auf Ihrem Rechner, bevor Sie auch nur eine Zeile gelesen haben: die Install-Skripte. Die Einträge preinstall, install und postinstall in der package.json werden im Moment des npm install ausgeführt. Die meisten seriösen Pakete brauchen so etwas gar nicht. Sehen Sie ein solches Skript ohne erkennbaren Grund, sollten Sie verstehen, was es tut, bevor Sie weitermachen.

Ist die CI-Pipeline echt oder nur Deko?

Ein grünes Abzeichen in der README ist schnell verdient, ohne dass es viel bedeutet. Ein Projekt kann drei Tests auf dem einfachsten Pfad laufen lassen und "100 % bestanden" melden, technisch korrekt und völlig nutzlos.

Sie wollen wissen, ob die Tests den Code tatsächlich schützen:

• Im Actions-Tab prüfen Sie, ob die Tests bei Pull Requests laufen, nicht erst nach dem Zusammenführen.
• Öffnen Sie einen kürzlich zusammengeführten Pull Request. Wurde dort wirklich getestet, oder ging es 30 Sekunden nach dem Öffnen durch?
• In der Testkonfiguration (etwa vitest.config.js) suchen Sie nach Schwellenwerten für die Testabdeckung. Sind sie gesetzt, scheitert der Bau, wenn zu wenig getestet wird. Fehlen sie, könnte jemand die Hälfte der Tests löschen, und niemand merkt es.

Ist die Codequalität sichtbar?

Sie werden nicht den ganzen Quellcode jedes Pakets lesen, das ist unrealistisch. Aber es gibt Signale, die man auf einen Blick erkennt und die erfahrungsgemäß mit guter Qualität einhergehen.

Schauen Sie, ob es eine Linting-Konfiguration gibt; sie sorgt automatisch für Sauberkeit und fängt offensichtliche Fehler ab. Bei TypeScript-Paketen werfen Sie einen Blick in die tsconfig.json: Ist dort strict: true gesetzt, wird eine ganze Klasse von Fehlern schon beim Übersetzen abgefangen statt erst im laufenden Betrieb. Tauchen dagegen Dutzende any- oder @ts-ignore-Einträge auf, sind die Typen eher Kosmetik als echte Sicherheit.

Was passiert, wenn etwas schiefgeht?

Jedes nennenswerte Paket bekommt irgendwann eine Sicherheitslücke. Entscheidend ist, wie der Autor damit umgeht.

Suchen Sie nach einer SECURITY.md-Datei. Sie sollte erklären, wie man eine Lücke vertraulich meldet. Fehlt sie, haben Sie im Ernstfall keinen sauberen Meldeweg. Im Security-Tab sehen Sie veröffentlichte Hinweise: Eine gut gehandhabte Lücke aus der Vergangenheit ist sogar ein gutes Zeichen, sie zeigt, dass der Autor einen verantwortungsvollen Ablauf kennt.

Für bekannte Schwachstellen lohnt ein Blick auf osv.dev oder snyk.io. Noch einen Schritt weiter geht socket.dev: Dieser Dienst untersucht das Verhalten eines Pakets, greift es aufs Netzwerk zu, fasst es das Dateisystem ungewöhnlich an, enthält es verschleierten Code? In sicherheitskritischen Umgebungen kann eine Lösung wie Socket Firewall verdächtige Pakete sogar schon bei der Installation blockieren.

Die Kurz-Checkliste für den Alltag

Nicht alle Prüfungen wiegen gleich schwer. Wenn Sie nur Zeit für drei Dinge haben:

1. Brauchen Sie es wirklich? Was Sie ersetzen oder weglassen können, müssen Sie gar nicht erst absichern.
2. Gibt es Provenance? Das ist der klarste Hinweis, dass das veröffentlichte Paket auch das beabsichtigte ist.
3. Gibt es unerklärte Install-Skripte? Code läuft hier im Moment der Installation.

Ist das Paket geschäftskritisch, kommt ein vierter Punkt hinzu: Reagiert der Betreuer zuverlässig?

Risiko ist keine Ja-Nein-Frage

Nichts davon ist ein simpler Bestanden-oder-durchgefallen-Test. Ein Paket, das in der Oberfläche nur Datumsangaben formatiert, hat ein anderes Risikoprofil als ein HTTP-Baustein zwischen Ihrem Dienst und einer Behörden-Schnittstelle. Ein Paket mit 50 Millionen Downloads pro Woche hat mehr Augenpaare auf sich als eines mit 500.

Das Ziel ist nicht das perfekte Paket. Das Ziel ist, bewusst zu verstehen, worauf Sie sich einlassen, und diese Entscheidung absichtlich zu treffen statt nebenbei.

Fazit

Ein npm-Paket einzubinden, ist eben doch mehr als ein Mausklick. Wer sich angewöhnt, vor dem npm install ein paar gezielte Fragen zu stellen, Brauche ich es? Wird es gepflegt? Ist die Veröffentlichung beglaubigt? Was passiert im Notfall? –, schützt sein Projekt mit erstaunlich wenig Aufwand. Diese fünf bis zehn Minuten garantieren keine absolute Sicherheit, denn die gibt es nirgends. Aber sie verwandeln eine optimistische Annahme in eine fundierte Entscheidung. Und genau das ist der Unterschied zwischen Glück und Können.

Häufig gestellte Fragen (FAQs)

Bedeutet eine fehlende Provenance, dass ein Paket unsicher ist?

Nein. Sehr viele Pakete sind älter als diese Funktion und wurden daher ohne Beglaubigung veröffentlicht. Eine fehlende Provenance heißt lediglich, dass Sie die Kette vom Quellcode bis zur Veröffentlichung nicht selbst überprüfen können. Bei einem unscheinbaren Hilfspaket ist das verkraftbar, bei einem geschäftskritischen Baustein sollten Sie umso genauer auf die übrigen Signale achten.

Wie erkenne ich, ob ein von der KI vorgeschlagenes Paket erfunden ist?

Prüfen Sie zuerst, ob es auf npmjs.com überhaupt existiert und eine echte Versionshistorie besitzt. Achten Sie auf eine plausible Zahl an Veröffentlichungen über die Zeit, ein verknüpftes Repository und idealerweise eine Provenance. Ein Paket, das erst vor wenigen Tagen unter einem auffällig "passenden" Namen aufgetaucht ist und keinerlei Vergangenheit hat, sollte Sie misstrauisch machen.

Muss ich diese ganze Prüfung wirklich für jedes einzelne Paket durchführen?

Nicht in voller Tiefe. Für unkritische Werkzeuge in einem internen Projekt reichen oft die drei wichtigsten Fragen aus der Kurz-Checkliste. Die vollständige Prüfung lohnt sich, wenn der Einsatz heikler wird, etwa bei Paketen, die in jedem Dienst laufen, sensible Daten verarbeiten oder geschäftskritische Aufgaben übernehmen. Der Aufwand sollte immer zum tatsächlichen Risiko passen.