npm-Pakete gegen Supply-Chain-Angriffe absichern: Typosquatting, gestohlene Tokens und kompromittierte Abhängigkeiten erkennen

Montagmorgen, kurz vor dem Release: Ein Entwickler aktualisiert eine scheinbar harmlose npm-Abhängigkeit, die Pipeline läuft grün und die Anwendung geht online. Wenige Stunden später fällt auf, dass das neue Paket beim Installieren ein Skript ausführt und Zugangsdaten aus der Build-Umgebung abgreift. Solche Vorfälle beginnen selten mit einer spektakulären Sicherheitslücke in der eigenen Anwendung. Häufig reicht ein Paketname, der einem bekannten Projekt täuschend ähnlich sieht, ein gestohlenes Maintainer-Token oder ein kompromittiertes Update einer etablierten Bibliothek.

Für Entwicklungsteams bedeutet das: Jede externe Abhängigkeit ist Teil der eigenen Lieferkette. npm-Pakete verdienen daher dieselbe Sorgfalt wie eigener Code. Du musst nicht jedes Paket vollständig auditieren. Aber du brauchst klare Prüfungen, eingeschränkte Berechtigungen und einen geübten Ablauf für verdächtige Updates.

Infografik zu npm-Pakete gegen Supply-Chain-Angriffe absichern: Typosquatting, gestohlene Tokens und kompromittierte Abhängigkeiten erkennen (KI-generiert).

Warum npm-Abhängigkeiten ein attraktives Ziel sind

Ein einzelnes Paket kann in Tausenden Projekten landen. Wer ein weit verbreitetes Paket oder das Konto eines Maintainers kompromittiert, erreicht potenziell viele Unternehmen zugleich. Besonders kritisch sind Pakete, die in Build-Prozessen, Frontends, Backend-Diensten oder Entwicklerwerkzeugen verwendet werden.

Typische Angriffswege sind:

• Typosquatting: Angreifer veröffentlichen Pakete mit Namen, die bekannten Bibliotheken ähneln, etwa durch vertauschte Buchstaben oder zusätzliche Bindestriche.
• Account-Übernahmen: Gestohlene Passwörter, fehlende Mehrfaktor-Authentifizierung oder langlebige Tokens ermöglichen unberechtigte Veröffentlichungen.
• Kompromittierte Updates: Ein legitimes Paket erhält eine manipulierte Version, beispielsweise nach Übernahme eines Maintainer-Kontos.
• Bösartige Installationsskripte: Skripte wie preinstall, install oder postinstall führen beim Installieren Code aus.
• Unsichere CI/CD-Zugänge: Tokens mit zu vielen Rechten können über Build-Logs, Artefakte oder kompromittierte Abhängigkeiten abfließen.

Diese Risiken ergänzen klassische Schwachstellen. Auch ein Paket ohne bekannte CVE kann gefährlich sein, wenn Herkunft, Veröffentlichung oder Installationsverhalten nicht vertrauenswürdig sind. Grundlegende Prinzipien sicherer Entwicklung gelten deshalb auch für die Lieferkette, wie wir im Beitrag Sichere Webentwicklung: die wichtigsten Prinzipien erläutern.

Neue Abhängigkeiten vor der Aufnahme prüfen

Die wichtigste Entscheidung fällt vor npm install. Behandle neue Pakete nicht als bloße technische Abkürzung, sondern als neue Vertrauensbeziehung. Gerade bei kleinen Hilfsbibliotheken ist die Versuchung groß, einen wenig bekannten Treffer aus der Suche zu übernehmen.

Prüfe bei jedem neuen Paket mindestens diese Punkte:

• Stimmt der Paketname exakt mit der offiziellen Projektseite oder Herstellerdokumentation überein?
• Ist klar erkennbar, wer das Paket veröffentlicht und pflegt?
• Gibt es ein nachvollziehbares Repository, eine Lizenz und aussagekräftige Versionshistorie?
• Wie viele direkte und transitive Abhängigkeiten bringt das Paket mit?
• Benötigst du das Paket wirklich oder reicht eine kleine, selbst gepflegte Funktion?
• Enthält das Paket Installationsskripte oder fordert es ungewöhnliche Berechtigungen?
• Ist die Version aktuell genug, ohne dass ein gerade erst erschienenes Update ungeprüft übernommen wird?

Ein hoher Downloadwert ist kein Echtheitsbeweis. Ebenso ist ein aktives Repository allein kein Garant für Sicherheit. Entscheidend ist das Gesamtbild: Passt der Name, ist die Herkunft nachvollziehbar, wirkt die Projektpflege konsistent und ist der Funktionsumfang angemessen?

Nutze bevorzugt offizielle Paketnamen und klar erkennbare Scopes wie @organisation/paket, wenn ein Hersteller diese anbietet. Suchergebnisse, Blogbeiträge oder kopierte Installationsanweisungen können auf Typosquatting-Pakete verweisen. Übernimm Paketnamen deshalb nicht blind aus fremden Snippets.

package.json bewusst pflegen

Die package.json ist nicht nur eine technische Manifestdatei. Sie dokumentiert, welche externen Komponenten dein Projekt bewusst akzeptiert. Halte direkte Produktions- und Entwicklungsabhängigkeiten sauber getrennt und entferne nicht mehr benötigte Pakete zeitnah.

Versionsbereiche sind dabei eine Abwägung. Ein weiter Bereich kann kompatible Updates automatisch zulassen, erhöht aber die Wahrscheinlichkeit, dass eine neue Version ohne bewusste Prüfung in einen Build gelangt. Exakte Versionen schaffen mehr Kontrolle, erhöhen jedoch den Pflegeaufwand. Für besonders kritische Pakete lohnt sich eine restriktive Versionierung mit geregelten Update-Fenstern.

Wichtiger als die Schreibweise der Versionsnummer ist ein nachvollziehbarer Prozess:

• Neue Abhängigkeiten benötigen eine Code-Review.
• Updates werden als eigene Änderung behandelt, nicht zwischen Funktionsänderungen versteckt.
• Kritische Pakete erhalten feste Verantwortliche im Team.
• Abhängigkeiten ohne aktiven Nutzen werden entfernt.
• Lizenz, Herkunft und Wartungsstatus werden bei wichtigen Komponenten dokumentiert.

Vermeide außerdem Installationsbefehle, die Änderungen an package.json und Lockfile unkontrolliert erzeugen. Ein Entwickler sollte nachvollziehen können, warum sich welche Abhängigkeit geändert hat.

Lockfiles als Sicherheitsgrenze nutzen

Ein Lockfile hält nicht nur Versionen fest. Es dokumentiert auch die konkrete Abhängigkeitsauflösung und Integritätsinformationen für installierte Pakete. Für reproduzierbare Builds gehört es ins Repository und in die Code-Review.

In der CI/CD-Umgebung ist npm ci in der Regel die bessere Wahl als ein gewöhnliches npm install. Der Befehl installiert anhand des vorhandenen Lockfiles und bricht ab, wenn package.json und Lockfile nicht zusammenpassen. Damit verhindert er, dass die Pipeline stillschweigend eine neue Auflösung erzeugt.

Achte auf diese Regeln:

• Versioniere package-lock.json gemeinsam mit dem Anwendungscode.
• Prüfe Lockfile-Änderungen im Pull Request bewusst.
• Erzeuge das Lockfile nicht erst während eines produktiven Deployments.
• Verwende in Build, Test und Produktion denselben Paketmanager und dieselbe Lockfile-Strategie.
• Stelle sicher, dass die CI sauber startet und keine lokalen Cache-Reste das Ergebnis verfälschen.

Ein Lockfile schützt nicht, wenn bereits eine schädliche Version darin festgeschrieben wurde. Es begrenzt aber spontane Änderungen und macht die Herkunft einer Installation besser nachvollziehbar. Gerade bei auffälligen Updates ist diese Nachvollziehbarkeit entscheidend.

Installationsskripte und transitive Abhängigkeiten im Blick behalten

Installationsskripte sind nicht grundsätzlich verdächtig. Manche Pakete benötigen sie legitim, etwa um plattformspezifische Komponenten bereitzustellen. Sie erweitern jedoch die Angriffsfläche erheblich, weil Code bereits beim Installieren ausgeführt werden kann.

Für eine erste technische Prüfung eines verdächtigen Pakets kannst du die Installation in einer isolierten Umgebung ohne Skriptausführung vornehmen. Das ersetzt keine Analyse, verhindert aber, dass du beim bloßen Nachsehen unerwartet Code ausführst. Prüfe insbesondere Änderungen an Skripten, auffällige Netzwerkzugriffe und Zugriffe auf Umgebungsvariablen.

Transitive Abhängigkeiten verdienen ebenfalls Aufmerksamkeit. Dein Team installiert vielleicht nur zehn direkte Pakete, erhält aber mehrere hundert indirekte Komponenten. Setze daher Werkzeuge zur Inventarisierung und Schwachstellenprüfung ein. Ergebnisse aus npm audit können hilfreich sein, ersetzen aber keine Priorisierung. Ein Fund ist erst dann handlungsrelevant, wenn du Nutzung, Erreichbarkeit, Auswirkung und verfügbare Gegenmaßnahmen bewertest. Wie du Schwachstellen sinnvoll einordnest, beschreiben wir in Schwachstellen bewerten und priorisieren.

npm-Tokens und Maintainer-Konten absichern

Ein npm-Token ist ein Schlüssel zur Lieferkette. Gelangt er in ein Repository, Build-Log oder Ticket-System, kann ein Angreifer unter Umständen Pakete veröffentlichen, Einstellungen ändern oder private Pakete lesen. Behandle ihn daher wie ein Produktionsgeheimnis.

Für Maintainer und automatisierte Veröffentlichungen gelten klare Mindestmaßnahmen:

• Aktiviere Mehrfaktor-Authentifizierung für alle Konten mit Veröffentlichungsrechten.
• Verwende getrennte Konten für Personen und Automatisierung.
• Erstelle Tokens nur mit dem minimal notwendigen Umfang.
• Begrenze Laufzeit und Einsatzbereich von Tokens, soweit es der Prozess zulässt.
• Speichere Tokens ausschließlich in einem dafür vorgesehenen Secret-Speicher der CI/CD-Plattform.
• Gib Secrets weder in Logs noch in Fehlermeldungen aus.
• Entferne Tokens sofort, wenn Mitarbeitende Rollen wechseln oder Projekte enden.
• Überprüfe regelmäßig, welche Konten veröffentlichen dürfen.

Für Veröffentlichungen aus der Pipeline braucht der Build nur die Rechte, die er tatsächlich benötigt. Ein Token, das nur ein bestimmtes Paket veröffentlichen darf, ist deutlich weniger riskant als ein weitreichender Zugang für mehrere Organisationen. Auch Workflows selbst müssen geschützt werden. Im Beitrag GitHub Actions sicher konfigurieren: Secrets schützen, Rechte minimieren, Supply-Chain-Risiken senken zeigen wir, worauf es bei Berechtigungen, externen Actions und Secrets ankommt.

Verdächtige Paket-Updates schnell eindämmen

Warnzeichen sind plötzlich neue Maintainer, ungewöhnliche Versionssprünge, neue Installationsskripte, unerwartete Netzwerkkommunikation oder Änderungen, die nicht zur beschriebenen Funktion passen. Auch Hinweise aus Sicherheitsmeldungen oder auffällige Fehler in der Pipeline können Anlass sein, ein Update zu stoppen.

Wenn du einen Verdacht hast, handle strukturiert:

1. Stoppe weitere Rollouts und pausiere automatisierte Updates des betroffenen Pakets.
2. Ermittle, welche Anwendungen, Branches und Build-Artefakte die Version enthalten.
3. Sperre die bekannte gute Version im Lockfile und erstelle einen reproduzierbaren Build.
4. Prüfe CI-Protokolle auf mögliche Secret-Ausgaben und unübliche Prozessschritte.
5. Widerrufe vorsorglich Tokens, die während der Installation oder des Builds erreichbar waren.
6. Analysiere betroffene Systeme isoliert und sichere Logs sowie Lockfiles als Belege.
7. Informiere Entwicklung, Betrieb und Security mit einer klaren technischen Lagebeschreibung.
8. Entscheide erst nach Prüfung über Bereinigung, Neuaufbau und erneutes Deployment.

Ein Paket aus dem Cache zu löschen oder nur die Anwendung neu zu starten genügt nicht, wenn Zugangsdaten abgeflossen sein könnten. Dann gehört die Rotation der betroffenen Secrets zwingend dazu. Für den strukturierten Umgang mit einem bestätigten oder wahrscheinlichen Sicherheitsvorfall hilft unser Leitfaden Incident Response: was tun im Ernstfall.

Eine praxistaugliche Routine für dein Team

Supply-Chain-Sicherheit entsteht nicht durch eine einmalige Prüfung, sondern durch wiederholbare Gewohnheiten. Plane regelmäßige Update-Zyklen, in denen ihr Änderungen kontrolliert einspielt. Kritische Updates werden vor dem Produktiveinsatz getestet, Lockfile-Differenzen geprüft und auffällige Pakete nicht unter Zeitdruck übernommen.

Logging hilft dir zusätzlich, ungewöhnliche Installations- und Build-Vorgänge später einzuordnen. Erfasse nachvollziehbar, welcher Commit welches Artefakt mit welchem Lockfile erzeugt hat. Hinweise zur sinnvollen Erkennung und Auswertung findest du in Angriffe früh erkennen: Logging und Monitoring.

Passende Seminare und Termine für sichere Entwicklung, Pentests und praxisnahe IT-Sicherheit findest du bei uns auf cmt.de.