TL; DR
Das Auffinden von Sicherheitslücken in npm-Paketen ist einfach. npm audit Erledigt es in vier Sekunden und liefert Ihnen 400 Ergebnisse. Die Schwierigkeit liegt in den nächsten beiden Fragen: Welche davon sind in Ihrer Anwendung tatsächlich erreichbar, und welches Upgrade behebt das Problem, ohne den Build zu beschädigen?
- Der größte Teil der Liste ist nicht Ihr Problem. Die Anwendung von Erreichbarkeits- und Laufzeitkontext auf „kritische“ Ergebnisse lässt einen kleinen Teil weiterhin kritisch erscheinen. Die Aufrufdiagrammanalyse zeigt Ihnen, welche davon kritisch sind.
npm audit fix --forceist keine Lösungsstrategie. Es behebt Sicherheitswarnungen durch das Überspringen von Hauptversionen, wodurch aus einer Sicherheitsaufgabe ein Ausfall wird.- Transitive Abhängigkeiten sind der Ort, wo das Volumen liegt. Sie haben sie nicht ausgewählt, Sie können sie oft nicht direkt aktualisieren, und sie dominieren die Anzahl der Funde.
- Beheben Sie den Fehler vor dem Zusammenführen, nicht nach der Veröffentlichung. Ein Gate in CI und ein automatisierter pull request Es kostet Minuten. Ein Produktionspatch kostet ein Wochenende.
Warum die Anzahl der Funde nicht das Problem ist
Jedes Node-Projekt, das das erste Jahr überschritten hat, bietet die gleiche Erfahrung: Man führt einen Scan durch, erhält Hunderte von npm-Paket-Schwachstellen, und die Liste ist so lang, dass die vernünftige Reaktion darin besteht, das Terminal zu schließen.
Diese Reaktion ist berechtigt, und genau das ist das Unangenehme daran. Fast drei Viertel aller Codebasen enthalten risikoreiche Open-Source-Komponenten, und der Großteil der von Scannern gemeldeten Probleme befindet sich tatsächlich in Ihrem Abhängigkeitsbaum. Die Liste ist korrekt. Sie stellt jedoch keine Arbeitsliste dar.
Der Unterschied zwischen einer korrekten Liste und einer umsetzbaren Liste liegt im Kontext, und letztendlich kommt es auf eine Handvoll Fragen an.
- Ist der anfällige Code tatsächlich von meiner Anwendung aus erreichbar?
- Wird dies bereits von irgendjemandem in freier Wildbahn ausgenutzt?
- Ist das, was es betrifft, für das Unternehmen von Bedeutung?
Ein Scanner, der diese Fragen nicht beantworten kann, liefert Ihnen eine Bestandsaufnahme und nennt das einen Bericht.
Wie man npm-Pakete auf Sicherheitslücken überprüft
Es gibt vier praktische Methoden, um npm-Pakete auf Sicherheitslücken zu überprüfen, und jede Methode beantwortet eine andere Frage.
Beginnen mit npm audit Weil es nichts kostet und nur Sekunden dauert. Aber hören Sie nicht dabei auf, denn die Antwort lautet: „Hier ist alles“, und „alles“ ist kein Plan.
Wichtig zu wissen, wenn man auf Sicherheitswarnungen angewiesen ist: Die GitHub Advisory Database enthält Malware-Warnungen für das npm-Ökosystem, Dependabot gibt jedoch absichtlich keine Warnungen dazu aus, da ein nachgelagerter Benutzer das Problem in der Regel nicht durch ein Upgrade beheben kann. Dies ist eine strukturelle Lücke und keine beeinflussbare Einstellung. Schadsoftware in Paketen erfordert eine andere Vorgehensweise: Erkennung bei der Veröffentlichung statt nach der Offenlegung. Xygeni Frühwarnung vor Malware Es analysiert neu veröffentlichte Pakete auf npm, PyPI, Maven und anderen Registries in Echtzeit, indem es Verhaltens- und Anomalieanalysen durchführt, anstatt auf eine Signatur zu warten. Diese Funktion ist im kostenlosen Developer-Plan enthalten. Wir berichten darüber in [Link einfügen]. böswilligen npm-Pakete.
Die Filter, die aus 400 Ergebnissen eine Auswahlliste erstellen
Das ist der Teil, der die Arbeitsweise eines Teams verändert.
| Filter | Die Frage, die es beantwortet | Was es typischerweise entfernt |
|---|---|---|
| Erreichbarkeit | Kann die Ausführung meiner Anwendung die anfällige Funktion tatsächlich erreichen? | Die größte Reduzierung. Die meisten Warnhinweise befinden sich im Code, den die Anwendung nie aufruft. |
| Ausnutzbarkeit | Gibt es bereits eine funktionierende öffentliche Sicherheitslücke, und wird diese aktuell in freier Wildbahn ausgenutzt? | Unterscheidet theoretisches Risiko von tatsächlichem Risiko. Ein Fund mit einer öffentlich bekannten Sicherheitslücke wird unabhängig von seinem Schweregrad priorisiert. |
| Exploit-Wahrscheinlichkeit (EPSS) | Wie wahrscheinlich ist die Ausbeutung in freier Wildbahn in den nächsten 30 Tagen? | Schwerwiegende Erkenntnisse, die niemand nutzt, die selten Gegenstand der Arbeit dieser Woche sind. |
| Geschäftlicher Zusammenhang | Ist der betroffene Dienst relevant und ist er gefährdet? | Erreichbare, ausnutzbare Erkenntnisse in Systemen, die kein nennenswertes Risiko bergen |
| Verfügbarkeit von Fix | Gibt es eine Version, die dieses Problem behebt, ohne dass ich damit etwas kaputt machen kann? | Unterscheidet zwischen dem, was Sie heute schließen können, und dem, was eine Umgehungslösung erfordert. |
- Erreichbarkeit Dies ist der erste und wichtigste Schritt. Eine Schwachstelle in einem abhängigen Paket ist nur dann ausnutzbar, wenn die Ausführung die betroffene Funktion tatsächlich erreichen kann. Die Aufrufgraphenanalyse beantwortet diese Frage auf Funktionsebene, anstatt sie anhand des Manifests zu erraten, und unterscheidet tatsächlich verwendete Komponenten von solchen, die lediglich vorhanden sind. Die Erreichbarkeitsanalyse von Xygeni reduziert Fehlalarme um bis zu 70 %.
Ausnutzbarkeit Das zweite ist eine Tatsache, keine Prognose. Ein funktionierender, öffentlich ausgenutzter Sicherheitsfehler oder eine bestätigte Ausnutzung in freier Wildbahn ändert die Priorität eines Sicherheitsvorfalls, unabhängig von dessen Schweregrad. Diese Unterscheidung ist nicht länger nur eine bewährte Praxis, sondern eine Pflicht: Gemäß dem Cyber Resilience Act muss ein Hersteller, der von einer aktiv ausgenutzten Sicherheitslücke in seinem Produkt Kenntnis erlangt, diese innerhalb von 24 Stunden melden. Ein Programm, das nicht zwischen „aktiv ausgenutzt“ und „hohem CVSS-Wert“ unterscheiden kann, kann diese Frist nicht einhalten.
Die Ausnutzungswahrscheinlichkeit ist der dritte Faktor, und es geht im Grunde um dieselbe Frage, nur mit der zusätzlichen Vorhersage. EPSS bewertet die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen aktiv ausgenutzt wird. Das ist etwas ganz anderes, als die Frage nach den Folgen einer solchen Ausnutzung zu beantworten. Ein hoher CVSS-Wert bei gleichzeitig vernachlässigbarem EPSS-Wert ist selten ein Problem, das sich in dieser Woche lösen lässt.
- Geschäftlicher Zusammenhang Dies ist die dritte Schwachstelle, und sie kann von keinem generischen Feed bereitgestellt werden. Eine erreichbare, ausnutzbare Sicherheitslücke in einem internetbasierten Zahlungsdienst ist nicht dasselbe wie dieselbe CVE-Meldung in einem internen Meldetool.
In Kombination angewendet, verwandeln diese Filter routinemäßig eine Liste, die niemand liest, in eine Liste, die jemand abarbeitet. Laufzeit- und Erreichbarkeitskontext lassen typischerweise nur eine kleine Minderheit der „kritischen“ Ergebnisse weiterhin kritisch. Xygeni behandelt Erreichbarkeit, Exploit-Verfügbarkeit, EPSS und Geschäftskontext als konfigurierbare Stufen in einem Priorisierungstrichter mit bis zu acht Stufen, sodass „erreichbar und aktiv ausgenutzt“ zu einer ständigen Warteschlange wird, anstatt eine manuell ausgeführte Abfrage zu sein.
Behebung von npm-Paketsicherheitslücken ohne Beeinträchtigung des Builds
Das Finden ist die einfache Hälfte. Der Grund, warum Sicherheitslücken in npm-Paketen monatelang ungelöst bleiben, ist, dass deren Behebung eigene Risiken birgt, und das wissen die Entwickler.
Die entscheidende Frage vor jedem Upgrade ist nicht, ob die CVE dadurch behoben wird. Es sind drei Fragen gleichzeitig: Welche Sicherheitslücken verschwinden mit dieser Version, welche neuen treten auf und führt der Versionssprung zu Fehlern in meinem Code?
Xygeni Es werden alle drei Optionen für jede anfällige Abhängigkeit angezeigt, sodass die Wahl zwischen sichtbaren Optionen und nicht zwischen einem abrupten Sprung besteht. Anschließend generiert Autofix die pull request Mit der gepatchten Version werden durch die Massenbehebung mehrere Korrekturen in einem Schritt angewendet, und der Xygeni-Bot wird bei Bedarf ausgeführt. pull requests oder täglich, sodass der Rückstand schrumpft, ohne dass jemand die Bearbeitung einplant.
Bei transitiven Abhängigkeiten, bei denen man nicht einfach eine Version erhöhen kann, die man nicht selbst gewählt hat, ist die sinnvolle Ausgabe der kürzeste Upgrade-Pfad im Verzeichnisbaum, der die Sicherheitswarnung behebt, und nicht eine Warnung, die darauf hinweist, dass ein vier Ebenen tiefer liegendes Paket anfällig ist.
Bevor die Ware versendet wird: Wohin der Scheck gehört
„Bevor sie versenden“ ist eine Terminierungsaussage, und es kommt auf drei Platzierungen an.
- In der IDEEin Entwickler erkennt das Problem also bereits bei der Auswahl der Abhängigkeit, was der günstigste Zeitpunkt für eine Änderung ist.
- Auf dem pull requestHierbei kommentiert ein Bot die Änderungen und öffnet den Fix, und ein Sicherheitsgate kann einen Build bei Überschreitung eines Schwellenwerts fehlschlagen lassen. Die alleinige Berücksichtigung des Schweregrads führt dazu, dass Teams das Gate deaktivieren. Die Berücksichtigung erreichbarer und ausnutzbarer Schwachstellen hingegen sorgt dafür, dass sie es beibehalten.
- Kontinuierlich nach der Freigabe, Denn eine Abhängigkeit, die zum Zeitpunkt des Zusammenführens noch fehlerfrei war, wird an dem Tag, an dem eine Sicherheitswarnung veröffentlicht wird, angreifbar. Kontinuierliche Überwachung über alle Registries hinweg deckt dies auf, ohne dass jemand an einen erneuten Scan denken muss.
Und die Ausgabe aller drei gehört in eine priorisierte Warteschlange zusammen mit Ihrer SAST, und Containerfundeeinschließlich derjenigen, die von bereits ausgeführten Tools erfasst werden. Schwachstellenliste Es handelt sich dabei um eine Liste, die in ihrer eigenen Konsole existiert und mit der Arbeit, über die sie eigentlich informieren sollte, um Aufmerksamkeit konkurriert.
Liefere die Lösung, nicht die Erkenntnis.
Ein Scanner, der 400 npm-Paketschwachstellen meldet, hat die Arbeit nicht erledigt. Er hat sie nur verlagert.
Xygeni schränkt die Ergebnisse von Abhängigkeitsanalysen anhand von Erreichbarkeit, Ausnutzungswahrscheinlichkeit und Geschäftskontext ein, zeigt, was jedes Upgrade behebt und was es möglicherweise verursacht, und öffnet die pull request mit der gepatchten Version. Es läuft in Ihrem pipelineproduziert SBOM und VDR-Ausgabe in SPDX und CycloneDX, die von CRA, NIS2 und DORA angeforderten Nachweise, und platziert Abhängigkeitsbefunde in der gleichen priorisierten Warteschlange wie den Rest Ihres Risikos, einschließlich Befunden von Scannern, die Sie nicht ersetzen.
Kostenlos starten und ein Repository scannen, oder Sehen Sie, wie sich die Erreichbarkeit auf die Liste auswirkt..
FAQ
Wie kann ich npm-Pakete auf Sicherheitslücken überprüfen?
Führen Sie npm audit Für einen schnellen Überblick empfiehlt sich anschließend ein Tool mit Erreichbarkeitsanalyse, um die Liste auf die Stellen einzugrenzen, an denen der anfällige Code tatsächlich aufgerufen werden kann. Datenbanken mit Sicherheitswarnungen wie OSV und die GitHub Advisory Database sind hilfreich, um ein bestimmtes Paket und eine bestimmte Version zu überprüfen.
Is npm audit fix Kann man es sicher betreiben?
Die nicht erzwungene Version ist in der Regel sicher, da sie innerhalb semver-kompatibler Bereiche bleibt. npm audit fix --force Nein, es werden Aktualisierungen über Hauptversionen hinweg durchgeführt, um Sicherheitslücken zu beheben, und genau dort entstehen die inkompatiblen Änderungen.
Warum habe ich so viele Sicherheitslücken in meinen npm-Paketen?
Weil die meisten davon transitiv sind. Man installiert einige wenige direkte Abhängigkeiten und erbt Hunderte indirekter, jede mit ihrer eigenen Empfehlungshistorie. Das Volumen ist normal. Es fehlt die Priorisierung.
Was ist Erreichbarkeitsanalyse?
Die Feststellung, ob die Ausführung Ihrer Anwendung die anfällige Funktion in einer Abhängigkeit tatsächlich erreichen kann, ist entscheidend. Sie stellt die effektivste Methode zur Reduzierung von Fehlalarmen in der Abhängigkeitssicherheit dar, da die meisten gemeldeten Schwachstellen in Code liegen, den Ihre Anwendung nie aufruft.
Soll ich CVSS oder EPSS zur Priorisierung verwenden?
Beides dient unterschiedlichen Zwecken. CVSS beschreibt, wie schwerwiegend eine Schwachstelle im Falle ihrer Ausnutzung wäre. EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen ein. Schweregrad ohne Wahrscheinlichkeit führt zu einer falschen Sortierung der Warteschlange.
Wie oft sollte ich npm-Pakete auf Sicherheitslücken überprüfen?
Kontinuierlich, nicht nach einem Zeitplan. Ein fehlerfreier Scan am Montag ist am Mittwoch wertlos, wenn eine Warnung bei einem bereits versendeten Paket angezeigt wird.
