Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- „npm audit“ kann Ihren Verzeichnisbaum nur mit den Daten aus den Sicherheitshinweisen abgleichen, sodass eine vor einer Stunde veröffentlichte bösartige Version nicht erkannt wird.
- Um diese Lücke zu schließen, bedarf es mehr als nur eines Tools, da Verhaltensscanner, Herkunftsprüfungen und geprüfte Register jeweils einen anderen Aspekt abdecken.
- Die Steuerung, die das Ergebnis beeinflusst, ist diejenige, die überhaupt erst festlegt, was dein Build ausführen darf.
npm audit erfüllt eine Aufgabe besonders gut: Es vergleicht Ihren Abhängigkeitsbaum mit einer Datenbank bekannter Sicherheitslücken und zeigt Ihnen an, welche Übereinstimmungen gefunden wurden. Bei bereits dokumentierten Sicherheitslücken ist das sehr nützlich. Bei noch nicht dokumentierten Sicherheitslücken liefert audit jedoch keine Informationen, und wenn Sie die Abhängigkeit in diesem Zeitraum installieren, befindet sich der Code bereits in Ihrem Baum, bevor ein entsprechender Sicherheitshinweis vorliegt, mit dem er abgeglichen werden könnte.
Es wurde nie dafür entwickelt, ein schädliches Paket zu erkennen, bevor diese Bedrohung in den von ihm überprüften Sicherheitshinweisen auftaucht. Um eine Alternative zu npm audit zu finden, die diese Lücke tatsächlich schließt, muss man sich damit befassen, welche Kriterien darüber entscheiden, welche Versionen Ihr Build auflösen kann – und nicht nur damit, was im Nachhinein als problematisch markiert wird.
Was „npm audit“ tatsächlich überprüft und wo die Grenzen liegen
npm audit vergleicht Ihren Abhängigkeitsbaum mit den Warnmeldungen aus der GitHub Advisory Database, die seit 2021 als Grundlage für die Audit-Daten von npm dient. Es handelt sich dabei um eine Abfrage von Warnmeldungen und nicht um eine Überprüfung des Paketinhaltes oder des Laufzeitverhaltens. Wenn eine Version vor einer Stunde veröffentlicht wurde und noch keine Warnmeldung dazu vorliegt, hat audit keinen Vergleichswert für diese Version und sie wird daher nicht markiert.
Das ist kein Fehler. So ist das Tool nun einmal definiert. Der etwa dreistündige Axios-Hack im März 2026 zeigt, wie das in der Praxis aussieht. Zwei mit einer Hintertür versehene Versionen, 1.14.1 und 0.30.4, wurden in Betrieb genommen und verbreiteten sich über Installationen, während die Warnmeldungen noch nichts davon erwähnten. Sobald eine Warnmeldung vorlag, konnte das Audit diese Versionen überall dort kennzeichnen, wo sie gelandet waren – einschließlich der Verzeichnisse, in denen die Installation bereits erfolgt war. Was es jedoch nicht konnte, war, während des entscheidenden Zeitfensters etwas zu melden.
Es gibt noch eine zweite, enger gefasste Überprüfung, die man kennen sollte. Mit dem Befehl „npm audit signatures“ werden die Registrierungssignaturen heruntergeladener Pakete und, sofern vorhanden, deren Herkunftsbescheinigungen überprüft. Diese Kontrollen finden alle zu unterschiedlichen Zeitpunkten statt, was sich am besten im direkten Vergleich verdeutlichen lässt.
| Kategorie | Was es auffängt | Wenn es wirkt |
|---|---|---|
| npm audit | Bekannte Schwachstellen, die in den von ihm überprüften Sicherheitshinweisen erfasst sind | Sobald die Beratungsdaten dies abdecken |
| Verhaltensbasierte und statische Scanner | Verdächtige neue Pakete, Skripte, Verschleierung | Nach der Veröffentlichung, vor oder nach der Installation |
| Prüfung der Registrierungssignaturen | Fehlende oder ungültige Signaturen, die auf Manipulation hindeuten könnten | Wenn die Unterschriften überprüft werden |
| Herkunftsprüfungen | Ob die angegebene Herkunft und der Build-Workflow eines Pakets mit dessen Bescheinigung übereinstimmen | Wenn Bescheinigungen überprüft werden |
| Geprüfte, neu aufgebaute Register | Artefakte, die die Quellenüberprüfung oder die Malware-Prüfung nicht bestehen | Bevor Ihr Build diese beheben kann |
Werkzeuge zur Verhaltens- und statischen Analyse
Wenn die Audit-Daten mit den Beratungsdaten übereinstimmen, überprüfen Verhaltensanalyse-Tools das Paket selbst. Sie untersuchen, was sich zwischen den Versionen geändert hat: eine neue Abhängigkeit, die ohne ersichtlichen Grund aufgetaucht ist, ein Installationsskript, das in der letzten Version noch nicht vorhanden war, verschleierter Code oder Netzwerkaufrufe, die niemand angefordert hat.
Was sie aufdecken, was das npm-Audit nicht erkennt
Ein brandneues Paket oder eine vor wenigen Minuten veröffentlichte Version, für die noch kein Sicherheitshinweis vorliegt, ist einer der Fälle, für die dieses Tool entwickelt wurde. Es benötigt keine CVE, um ein verdächtiges Postinstallationsskript zu kennzeichnen, das eine unbekannte Domain ansteuert, oder einen Diff, der Hunderte von Kilobyte verschleierten Codes in eine Caching-Bibliothek einfügt, ohne dass dafür ein Grund vorliegt. Das ist der Kernnutzen: Verhaltensmuster zu erkennen, anstatt darauf zu warten, dass jemand anderes sie zuerst katalogisiert.
Wo sie noch Defizite aufweisen
Diese Tools erfordern eine Feinabstimmung, bevor das Signal eine Reaktion rechtfertigt, und Fehlalarme tragen zu einer Alarmmüdigkeit bei, die schließlich dazu führt, dass jemand den Kanal stummschaltet. Außerdem überprüfen sie nicht, woher ein Paket stammt, sondern nur, was es scheinbar tut, sodass eine Nutzlast, die während eines Scan-Fensters inaktiv bleibt, dennoch durchrutschen kann.
Die meisten davon vergleichen zudem die Daten mit dem, was bereits in der Registrierungsdatenbank veröffentlicht wurde, was bedeutet, dass sie erst dann melden, dass etwas nicht stimmt, wenn die Daten bereits dort gespeichert sind. Das ist zwar eine echte Verbesserung gegenüber dem Warten auf Warnmeldungen, aber es ist nicht dasselbe wie zu entscheiden, was bei Ihrem Build installiert werden darf.
Einen umfassenderen Überblick darüber, wo diese Art von Tools an ihre Grenzen stößt, erhalten Sie unter „Was Supply-Chain-Tools vermissen lassen“.
Herkunfts- und Signaturprüfung
Signaturen und Herkunftsangaben geben Antwort auf zwei Fragen, die eine Überprüfung nicht klären kann: ob das von Ihnen heruntergeladene Artefakt korrekt verifiziert wird und wo es erstellt wurde.
Was die Signaturen von „npm audit“ tatsächlich bestätigen
npm-Provenienzbescheinigungen nutzen Sigstore, um ein veröffentlichtes Artefakt mit dem Quell-Repository und dem Build-Workflow zu verknüpfen, aus dem es hervorgegangen ist. Mit dem Befehl „npm audit signatures“ wird überprüft, ob die Registrierungssignatur eines Pakets gültig ist und – sofern eine Bescheinigung vorliegt – ob das Paket eine gültige Bescheinigung enthält, die es mit dem Quell-Repository und dem darin erfassten Build-Workflow verknüpft.
Warum eine gültige Signatur noch kein Sicherheitsurteil ist
Das sind echte, nützliche Prüfungen. Eine ungültige Registrierungssignatur kann auf ein manipuliertes Artefakt hindeuten, und die Herkunftsprüfung kann ein Paket aufdecken, hinter dem keine Build-Historie steht, oder eine Bescheinigung, die auf eine andere Quelle verweist als die, von der Sie dachten, dass Sie sie erhalten würden.
Beides sagt jedoch nichts darüber aus, ob der Code selbst sicher ist. Die Herkunft gibt Aufschluss darüber, woher etwas stammt, nicht darüber, was es tut, sobald es ausgeführt wird. Eine Pipeline, die unbemerkt kompromittiert wurde, kann dennoch einen Build mit einer vollkommen gültigen Bescheinigung erzeugen, da die Bescheinigung einen echten Build mit tatsächlich bösartigem Code korrekt beschreibt. Betrachten Sie eine einwandfreie Herkunftsprüfung als einen Faktor bei einer Vertrauensentscheidung, nicht als Endziel.
Registrierungsstellen, die eine Überprüfung durchführen, bevor Sie die Domain zuweisen
Damit kommen wir zu dem Aspekt, von dem die meisten Teams annehmen, dass sie ihn bereits abgedeckt haben.
Proxy oder Mirror im Vergleich zu einer Registry, die Daten überprüft und neu aufbaut
Zahlreiche Teams betreiben eine private npm-Registry als Proxy oder Mirror vor der öffentlichen Registry, sei es Verdaccio mit einem Uplink oder ein in Nexus oder Artifactory konfiguriertes Proxy-Repository. Diese Produkte können weit mehr als nur Caching, aber in dieser Konfiguration fungiert die Registry als Engpass für den ausgehenden Datenverkehr und als zentrale Stelle, an der festgelegt wird, welche Quellen zugelassen sind. Eine Überprüfung ist dabei nicht vorgesehen. Wenn an keiner Stelle im Pfad das Artefakt überprüft wird, bleibt ein bösartiges Upstream-Paket auch dann bösartig, wenn es aus Ihrem Cache bereitgestellt wird.
Die andere Art von Registry greift in die durchlaufenden Daten ein, überprüft das Artefakt, verifiziert dessen Quelle und erstellt es in manchen Fällen sogar neu aus dieser Quelle, anstatt einfach das bereitzustellen, was zuletzt in der öffentlichen Registry veröffentlicht wurde. TuxCares „SecureChain“ beispielsweise erstellt npm-Pakete neu aus dem Quellcode und überprüft sie, bevor sie überhaupt in der Registry verfügbar sind. Das ist eine wesentlich andere Garantie, und genau dieser Aspekt macht den Unterschied aus: Anstatt nur zu kontrollieren, woher die Pakete stammen, wird nun kontrolliert, was tatsächlich installiert wird.
Was ändert sich, wenn ein Paket aus dem Quellcode neu kompiliert wird?
Der Neuaufbau aus dem Quellcode schließt eine Fehlerquelle aus, die durch Scannen allein nicht abgedeckt werden kann, nämlich ein veröffentlichtes Artefakt, das nicht mit dem übereinstimmt, was sich tatsächlich im Upstream-Repository befindet. Wenn die Version, die Ihr Build auflöst, in einer kontrollierten Pipeline aus dem erwarteten Quellcode neu erstellt wird, kann ein manipuliertes Tarball, das mit einem gestohlenen Token direkt in das öffentliche Register hochgeladen wurde, diesen Pfad nicht erreichen, solange der Quellcode selbst noch sauber ist. Das ist eine engere Garantie als „es passiert niemals etwas Schlimmes“, aber es ist eine echte Garantie, und sie gilt unabhängig davon, ob jemals ein Sicherheitshinweis verfasst wird oder nicht.
Warum das Stapeln von Werkzeugen immer noch eine Zeitlücke hinterlässt
Wenn man all das zusammennimmt, deckt man einen großen Bereich ab: npm-Audit auf bekannte Schwachstellen, Verhaltensanalyse neuer Pakete, Signatur- und Herkunftsprüfungen. Was sich dadurch allein jedoch nicht ändert, ist die Frage, welche Artefakte Ihr Paketmanager überhaupt einbinden darf.
Skripte zur Installation von Abhängigkeiten wurden bisher immer in dem Moment ausgeführt, in dem ein Paket installiert wurde – oft noch bevor ein Scanner etwas als verdächtig markiert hatte und bevor ein Mensch einen Blick darauf geworfen hatte. Genau das machte den Axios-Angriff so effektiv, da die mit einer Hintertür versehenen Releases eine brandneue Abhängigkeit einbunden, deren Postinstall-Skript den Dropper ausführte. Seit npm v12 werden Installationsskripte für Abhängigkeiten standardmäßig blockiert, es sei denn, das Projekt listet sie in seiner „allowScripts“-Richtlinie auf. Dadurch wird ein Teil dieses Angriffspfads geschlossen, allerdings können die Installationsskripte einer kompromittierten Abhängigkeit immer noch versehentlich genehmigt werden.
Falls Sie sich noch nicht näher mit der Funktionsweise dieses Vertrauensmodells befasst haben: Die Funktionsweise von Lebenszyklus-Skripten und deren aktuelle Standardwerte werden in dieser Anleitung zur sicheren Installation von npm-Paketen erläutert. Die Skriptblockierung legt fest, ob die Installationsskripte einer Abhängigkeit ausgeführt werden, nachdem npm diese ausgewählt und abgerufen hat. Sie entscheidet jedoch nicht darüber, ob eine bösartige Version überhaupt ausgewählt werden kann.
Das ist der entscheidende Unterschied, den man im Auge behalten sollte. Diese Prüfungen ändern für sich genommen nicht die Paketquelle, aus der Ihr Build bezogen wird, und eine Möglichkeit, dies zu ändern, besteht darin, die Entscheidung auf die Registry zu verlagern, auf die Ihre Builds verweisen.
Die Lücke schließen, bevor „npm audit“ sie überhaupt entdecken könnte
SecureChain ist kein Ersatz für Audits. Es handelt sich um eine alternative Registry, aus der Ihre npm-Abhängigkeiten aufgelöst werden. Es ersetzt die öffentliche npm-Registry durch ein kuratiertes, aus dem Quellcode neu erstelltes Repository, das Pakete überprüft, bevor sie zur Installation verfügbar sind. Somit wurden die von Ihrem Build abgerufenen Pakete bereits einer Quellcode-Überprüfung und einer Malware-Prüfung unterzogen. Für Teams, denen eine rein beratende Erkennung nicht ausreicht, verlagert dies die Entscheidung in eine frühere Phase, in der die Lücke bei der Beratung weitaus weniger ins Gewicht fällt.
Der Support erstreckt sich von der Einführung über die Entwicklung und den Betrieb bis hin über das Ende der Lebensdauer hinaus, wobei aktive Pakete im Rahmen des SLA gepatcht werden und der „Endless Lifecycle Support“ einspringt, sobald die Wartung durch den Upstream-Anbieter eingestellt wird. Jedes Paket verfügt über eine Herkunftsangabe gemäß SLSA Level 3, eine SBOM und VEX-Daten, ohne dass Änderungen am Workflow erforderlich sind.
Um einen tieferen Einblick in die Risiken zu erhalten, die in transitiven Abhängigkeiten lauern, sehen Sie sich das On-Demand-Webinar an oder sprechen Sie mit dem Team über SecureChain.
FAQ
Was ist eine gute Alternative zu npm audit?
Das lässt sich nicht einfach so direkt einbauen. „npm audit“ ist nach wie vor eine sinnvolle Methode, um bekannte Sicherheitshinweise in einem Verzeichnisbaum zu verfolgen, aus dem Sie bereits Pakete beziehen. Die leistungsfähigeren Optionen verlagern den Zeitpunkt der Entscheidung und prüfen Pakete, bevor Ihr Build-Prozess sie abrufen kann – was die Abgleichung mit Sicherheitshinweisen aufgrund ihrer Konzeption nicht leisten kann.
Erkennt „npm audit“ schädliche Pakete?
Es werden ausschließlich die Daten aus den Sicherheitshinweisen überprüft. Für Malware gibt es zwar Sicherheitshinweise, die vom npm-Sicherheitsteam und dem OpenSSF-Projekt „malicious-packages“ in die GitHub-Sicherheitshinweisdatenbank eingespeist werden, allerdings dokumentiert GitHub hierfür Dependabot und nicht „audit“ als Benachrichtigungsweg. In jedem Fall kann „audit“ eine neu veröffentlichte schädliche Version nicht anhand ihres Verhaltens erkennen, da es einen Abgleich mit den Daten aus den Sicherheitshinweisen durchführt, anstatt das Paket selbst zu überprüfen.
Lohnt es sich noch, „npm audit“ bei einer geprüften Registry auszuführen?
Vor allem aus Gründen der Transparenz. Eine gefilterte und kontinuierlich aktualisierte Registrierungsdatei verändert zwar den Umfang, in dem die Behebungsmaßnahmen von der Prüfung abhängen, aber ihre Ausführung zeigt Ihnen dennoch, welche bekannten Sicherheitshinweise sich auf bereits in Ihrem Baum vorhandene Elemente beziehen.
Was ist eigentlich der Unterschied zwischen einer privaten und einer geprüften Registrierungsstelle?
Ein privates Repository kann so konfiguriert werden, dass es kaum mehr als ein Proxy oder ein Mirror ist, der steuert, woher die Pakete stammen. Ein gefiltertes Repository überprüft und erstellt in manchen Fällen die tatsächlich bereitgestellten Inhalte neu, was eine andere und stärkere Garantie darstellt.
Bedeutet eine einwandfreie Herkunftsprüfung, dass ein Paket sicher installiert werden kann?
Nein. Eine gültige Herkunftsangabe verknüpft ein Artefakt mit der Quelle und dem Arbeitsablauf, die in seiner Zertifizierung erfasst sind. Sie beweist jedoch nicht, dass diese Quelle oder dieser Arbeitsablauf nicht manipuliert wurden; daher kann ein gültig zertifiziertes Paket dennoch schädlich sein.
