Warum npm-Pakete zur Sicherheitsfalle werden – und was Sie tun können
Stellen Sie sich vor, Sie bauen eine Küche. Statt jeden Schrank, jede Schraube und jede Schubladenführung selbst herzustellen, kaufen Sie Fertigteile ein. Das spart Zeit und Geld. Aber was, wenn einer der Zulieferer heimlich fehlerhafte Teile einbaut? Was, wenn er nicht merkt, dass seine Produktion kompromittiert wurde?
Genau so funktioniert ein wachsender Teil der Angriffe auf moderne Software. Nicht der eigene Code wird gehackt. Der Angreifer setzt tiefer an: bei den Fertigteilen.
Was npm ist und warum fast jede moderne Web-App davon abhängt
npm steht für "Node Package Manager". Es ist eine Plattform, auf der Entwickler fertige Code-Bausteine veröffentlichen und teilen. Diese Bausteine heißen Pakete.
Ein Paket kann eine Funktion haben, die Datumswerte formatiert. Oder eines, das Formulardaten prüft. Oder eines, das Verbindungen zu Datenbanken herstellt. Statt solche Funktionen von Grund auf selbst zu schreiben, binden Entwickler ein fertiges Paket ein. Das ist sinnvoll, effizient und in der gesamten Branche üblich.
Das npm-Ökosystem umfasst heute mehr als drei Millionen veröffentlichte Pakete. Es ist das größte Software-Repository der Welt. JavaScript-Anwendungen, also alles, was im Browser läuft oder auf Node.js-Basis im Hintergrund arbeitet, nutzen dieses System intensiv.
Eine typische mittelgroße Web-Anwendung hat nicht zehn oder zwanzig solcher Pakete. Sie hat häufig mehrere hundert. Warum so viele? Weil Pakete selbst wieder andere Pakete nutzen. Ein Paket, das Sie direkt einbinden, bringt oft fünf weitere mit. Diese fünf bringen wieder weitere. So entsteht ein Baum aus Abhängigkeiten. Fachleute sprechen von einer Dependency-Tree.
Das ist kein Fehler und kein Zeichen schlechter Entwicklung. Es ist der normale Stand bei moderner Software. Das Problem entsteht nicht durch die Abhängigkeiten selbst, sondern durch mangelnde Kontrolle darüber.
Warum dieser Baukasten ein attraktives Angriffsziel ist
Wenn Tausende von Anwendungen das gleiche Paket nutzen, ist dieses Paket ein lohnenswertes Ziel. Ein Angreifer muss nur einmal erfolgreich sein. Der Schaden verbreitet sich von selbst, überall dort, wo das Paket im Einsatz ist.
Diesen Angriffsweg nennt man Supply-Chain-Angriff. Der Begriff stammt aus der Logistik: Wer die Lieferkette kontrolliert, kontrolliert das Endprodukt. Bei Software läuft das genauso.
Ein Beispiel, das 2021 weltweit für Aufregung sorgte, war die Bibliothek "colors.js". Der Entwickler, der dieses weitverbreitete Paket pflegte, baute absichtlich schädlichen Code ein. Innerhalb von Stunden brachen Tausende von Anwendungen zusammen, die dieses Paket nutzten. In anderen Fällen übernehmen Kriminelle Accounts von Entwicklern und veröffentlichen infizierte Versionen, ohne dass der ursprüngliche Autor davon weiß.
Der entscheidende Punkt: Keine dieser Anwendungen hatte selbst einen Fehler im eigenen Code. Der Schaden kam von außen, über einen Baustein, dem man vertraut hatte.
Die häufigsten Angriffswege im npm-Ökosystem
Typosquatting: der Schreibfehler als Falle
Typosquatting nutzt menschliche Tippfehler aus. Ein Angreifer veröffentlicht ein Paket mit einem Namen, der einem bekannten Paket zum Verwechseln ähnlich sieht. Statt "lodash" heißt das Schadpaket "1odash" (mit einer Eins statt dem kleinen L) oder "loadash". Wer unachtsam tippt, bindet das falsche Paket ein, und mit ihm Schadcode.
Das klingt nach einem seltenen Fehler. In Wirklichkeit passiert es regelmäßig. Besonders in größeren Teams, in denen nicht jeder Einbau eines neuen Pakets geprüft wird.
Kompromittierte Maintainer-Accounts
Viele npm-Pakete werden von einzelnen Personen gepflegt, oft ehrenamtlich und nebenbei. Ein schwaches Passwort, eine Phishing-Mail, ein geleakter Token: Wenn ein Angreifer Zugang zum Account des Paketpflegers bekommt, kann er eine neue Paketversion veröffentlichen. Diese neue Version enthält dann Schadcode. Sie landet in allen Projekten, die automatisch auf die neueste Version aktualisieren.
Das Perfide daran: Die neue Version trägt den Namen und die Signatur des echten Entwicklers. Für automatische Prüfsysteme sieht alles normal aus.
Veraltete Pakete mit bekannten Sicherheitslücken
Nicht jeder Angriff ist so aufwändig. Der häufigste Weg ist einfacher. Wenn in einem Paket eine Sicherheitslücke bekannt wird, erscheint dazu eine CVE-Nummer. CVE steht für "Common Vulnerabilities and Exposures", also eine öffentliche Datenbank bekannter Schwachstellen.
Ab dem Moment, in dem eine CVE veröffentlicht ist, wissen Angreifer, wonach sie suchen. Sie scannen automatisiert das Netz nach Anwendungen, die die verwundbare Paketversion noch nutzen. Wer das betroffene Paket nicht aktualisiert hat, ist ein offensichtliches Ziel.
Das Problem: In vielen Unternehmen werden Pakete einmal eingebunden und dann vergessen. Die Anwendung läuft, also fasst niemand sie an. Monate oder Jahre später enthält sie Dutzende Pakete mit bekannten Lücken, und niemand hat es bemerkt.
Warum die Angriffszahlen steigen
Das npm-Ökosystem wächst schnell. Jeden Tag kommen tausende neue Pakete dazu. Gleichzeitig sinkt der Aufwand für Angreifer. Werkzeuge, die das Erstellen und Verbreiten von Schadpaketen automatisieren, werden zugänglicher.
Dazu kommt: Viele Sicherheitsteams prüfen den eigenen Code, aber nicht die Abhängigkeiten. Das ist eine Lücke, die Angreifer kennen und ausnutzen.
Ein weiterer Faktor ist Automatisierung auf Entwicklerseite. Viele Projekte nutzen Tools, die Pakete automatisch aktualisieren. Das ist grundsätzlich sinnvoll. Wenn aber ein kompromittiertes Update erscheint, fährt die Automatisierung es sofort ein.
Die Sicherheitsfirma Sonatype hat in ihrem jährlichen State-of-the-Supply-Chain-Bericht dokumentiert, dass die Zahl absichtlich bösartiger npm-Pakete von Jahr zu Jahr stark ansteigt. Die Wachstumsrate liegt regelmäßig im dreistelligen Prozentbereich. Das ist kein langsamer Trend. Es ist ein Beschleunigen.
Warum alte Software besonders gefährdet ist
Dieser Punkt ist für viele Entscheider überraschend: Das Problem betrifft nicht nur neue Anwendungen. Es betrifft besonders jene Software, die seit Jahren läuft und nie aktualisiert wurde.
Eine Anwendung, die vor fünf Jahren entwickelt wurde, nutzt Pakete, die vor fünf Jahren aktuell waren. Seitdem sind viele dieser Pakete aktualisiert worden, weil Lücken gefunden wurden. Die alte Anwendung zieht diese Updates aber nicht automatisch nach. Sie läuft weiter mit der alten, verwundbaren Version.
Diese Situation ist in deutschen Mittelstandsunternehmen weit verbreitet. Eine Software, die funktioniert, wird nicht angefasst. Das ist betriebswirtschaftlich nachvollziehbar, sicherheitstechnisch aber riskant. Mit jeder neu entdeckten CVE in einer dieser alten Abhängigkeiten wächst die Angriffsfläche.
Hinzu kommt: Je älter die Abhängigkeiten, desto schwieriger wird das Aktualisieren. Wenn fünf Jahre keine Updates eingespielt wurden, ist ein einfacher Update-Durchlauf oft nicht mehr möglich. Pakete haben sich weiterentwickelt, Schnittstellen haben sich geändert, und die Anwendung verträgt die neuen Versionen nicht mehr ohne Anpassungen am Code. Aus einem Sicherheits-Update wird dann ein größeres Projekt.
Das ist kein Grund, gar nicht zu handeln. Es ist ein Grund, jetzt anzufangen.
Was Unternehmen konkret tun können
Bestandsaufnahme: Was ist überhaupt im Einsatz?
Der erste Schritt ist Klarheit. Welche JavaScript-Anwendungen laufen im Unternehmen? Welche Pakete nutzen sie, in welcher Version? Diese Information sollte nicht aus dem Gedächtnis kommen, sondern aus einer aktuellen, verlässlichen Quelle.
Moderne Projekte speichern diese Information in einer sogenannten Lockfile-Datei, oft package-lock.json oder yarn.lock genannt. Diese Datei legt fest, welche Paketversion tatsächlich verwendet wird. Wenn diese Datei fehlt oder nicht gepflegt wird, ist die erste Grundlage für Kontrolle nicht vorhanden.
npm audit: der eingebaute Sicherheitscheck
Das npm-Tool bringt einen eingebauten Befehl mit: npm audit. Dieser Befehl gleicht alle Abhängigkeiten einer Anwendung gegen eine Datenbank bekannter Sicherheitslücken ab. Das Ergebnis ist eine Liste von Problemen, sortiert nach Schweregrad.
Das ist kein perfektes Werkzeug. Aber es ist kostenlos, ohne Einrichtungsaufwand und liefert sofort Orientierung. In Projekten, die es noch nie ausgeführt haben, sind die Ergebnisse oft ernüchternd.
SCA-Tools für den professionellen Einsatz
Für Unternehmen, die mehrere Anwendungen betreiben oder höhere Anforderungen haben, empfehlen sich spezialisierte Software-Composition-Analysis-Tools, kurz SCA-Tools. Bekannte Vertreter sind Snyk, Dependabot (in GitHub integriert) oder OWASP Dependency-Check.
Diese Werkzeuge überwachen Abhängigkeiten kontinuierlich. Wenn eine neue Sicherheitslücke bekannt wird, schlagen sie sofort Alarm, auch wenn die Anwendung selbst nicht verändert wurde. Sie können Warnungen direkt ins Entwicklungssystem schicken und automatisch Aktualisierungsvorschläge erstellen.
Regelmäßige Updates als Prozess, nicht als Ereignis
Sicherheit durch Aktualität entsteht nicht durch einmaligen Aufwand. Es braucht einen wiederkehrenden Prozess. Das bedeutet: Abhängigkeiten werden nicht einmal eingebunden und dann vergessen. Sie werden in regelmäßigen Abständen, mindestens einmal im Quartal, geprüft und aktualisiert.
Das klingt aufwändig. In einer gepflegten Anwendung ist es das nicht. Wenn Abhängigkeiten regelmäßig aktuell gehalten werden, sind die nötigen Schritte bei jedem Durchlauf klein. Wenn jahrelang nichts gemacht wurde, ist der erste Schritt groß, aber danach bleiben die Schritte klein.
Paket-Prüfung vor der Einbindung
Bevor ein neues Paket eingebunden wird, lohnt sich ein kurzer Check. Wie aktiv wird das Paket gepflegt? Wann war das letzte Update? Wie viele Nutzer hat es? Gibt es offene Sicherheitsprobleme? Für wie viele andere Pakete ist es Abhängigkeit?
Ein Paket mit einer Million Downloads täglich und einem aktiven Team dahinter ist ein anderes Risiko als ein Paket, das vor drei Jahren einmal veröffentlicht und seitdem nicht mehr angefasst wurde.
Diese Prüfung dauert fünf Minuten. Sie kann Monate Aufräumarbeit ersparen.
Was ein Security-Audit leistet
Für Unternehmen, die wissen wollen, wo sie konkret stehen, ist ein professioneller Security-Audit der richtige nächste Schritt. Dabei werden alle Abhängigkeiten systematisch erfasst, gegen bekannte CVEs abgeglichen und nach Schweregrad bewertet.
Das Ergebnis ist ein konkretes Bild: Welche Pakete sind kritisch? Wo besteht dringender Handlungsbedarf? Wo reichen kleinere Anpassungen? Ein guter Audit gibt keine endlose Liste ohne Priorität, sondern eine klare Reihenfolge.
Nützlich ist dieser Schritt auch als Grundlage für das Gespräch mit der Geschäftsführung. Wenn Zahlen auf dem Tisch liegen, wieviele Abhängigkeiten mit welchem Risikograd im Einsatz sind, werden Investitionen in Abhilfe greifbar.
Wenn Sie mehr darüber wissen wollen, was bei einem solchen Audit passiert und was danach folgt, lesen Sie auch unseren Artikel über Software-Audit: was passiert und warum KI ihn nicht ersetzt.
Fazit
npm-Pakete sind keine exotische Gefahr für Großkonzerne. Sie betreffen jede JavaScript-Anwendung, jeden Online-Shop, jede Web-App, jedes interne Tool. Und besonders jene Software, die lange unbeaufsichtigt läuft.
Die Zahl der Angriffe über Abhängigkeiten steigt. Die Werkzeuge für Angreifer werden einfacher. Die Angriffsfläche durch ungewartete Abhängigkeiten wird von Jahr zu Jahr größer.
Gleichzeitig sind die Gegenmittel nicht kompliziert. Bestandsaufnahme, regelmäßige Prüfung, ein verlässlicher Update-Prozess: Das reicht, um den größten Teil des Risikos zu kontrollieren. Was es braucht, ist der Anfang.
Wenn Sie wissen wollen, wie Ihre Abhängigkeiten heute aussehen und wo Handlungsbedarf besteht, sprechen Sie uns an. Wir prüfen, erklären und helfen beim Aufräumen, ohne Fachchinesisch und ohne unnötige Panik.