Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Du läufst npm audit, und da ist es:
14 vulnerabilities (3 low, 6 moderate, 4 high, 1 critical)Na, sieh dir das mal an: vierzehn Sicherheitslücken. Das ist wahrscheinlich ein Projekt, das seit einem Monat auf Eis liegt und an dem du vielleicht zweimal gearbeitet hast. Wahrscheinlich könntest du diese Pakete nicht einmal benennen, wenn man dich danach fragen würde. Sie sind wahrscheinlich einfach durch direkte Abhängigkeiten mit reingekommen. Der erste Schritt läuft an dieser Stelle wie am Schnürchen: Führe folgenden Befehl aus: npm audit fix, beobachten Sie, wie einige der Probleme behoben werden, schließen Sie das Terminal und machen Sie mit Ihrem Tag weiter. Niemand befasst sich tatsächlich eingehend mit allen vierzehn Sicherheitslücken.
Faulheit? Nein. Erschöpfung? Ja, und es lohnt sich, dies als eigenständiges Problem zu benennen, anstatt es unter „Entwickler kümmern sich nicht um Sicherheit“ zusammenzufassen, denn die beiden Ursachen erfordern ganz unterschiedliche Lösungen.
Das Problem mit den Störgeräuschen bei „npm audit“
npm audit Es kann eines gut: Es weist Sie darauf hin, dass eine bekannte Sicherheitslücke irgendwo in Ihrem Abhängigkeitsbaum auftritt. Ob dies für Ihre laufende Anwendung tatsächlich von Bedeutung ist? Das ist eine ganz andere Geschichte.
Was soll man damit anfangen, wenn Code, der vier Ebenen tief vergraben ist, plötzlich die Schweregradstufe „Hoch“ auslöst? npm definiert den Schweregrad anhand der Auswirkungen und der Ausnutzbarkeit im häufigsten Anwendungsfall – doch Ihre Anwendung entspricht möglicherweise nicht diesem typischen Fall. Andererseits ist die Aussage „Wir rufen das nie auf“ auch kein Freifahrtschein, da Installationsskripte und Build-Tools den anfälligen Code möglicherweise ausführen, noch bevor eine Anfrage überhaupt Ihre App erreicht.
Dann ist da noch die Zahl. Diese 14 bezieht sich auf die Anzahl der markierten Pakete, nicht auf einzelne Probleme. Ein Paket kann mehrere Sicherheitshinweise enthalten und zählt dennoch nur einmal, und npm markiert auch Meta-Schwachstellen: Pakete, deren deklarierter Abhängigkeitsbereich nur auf eine betroffene Version einer darunterliegenden Komponente abgeglichen werden kann. Daher könnten vierzehn „Schwachstellen“ in Wirklichkeit vier oder fünf einzelne Probleme sein, die unter verschiedenen Bezeichnungen auftreten.
Schlimmer noch: Entwicklungsabhängigkeiten werden mit genau derselben Dringlichkeit behandelt wie Produktionscode. Ein anfälliges ESLint-Plugin auf dem Laptop eines Entwicklers und eine anfällige Authentifizierungsbibliothek, die dem öffentlichen Internet ausgesetzt ist, gehören grundsätzlich nicht in dieselbe Dringlichkeitskategorie. Das gilt allerdings in beide Richtungen. Eine Build-Abhängigkeit, die in der CI läuft, auf Geheimnisse zugreift oder das von Ihnen ausgelieferte Artefakt beeinflusst, hat nicht automatisch eine niedrige Priorität, nur weil sie unter devDependencies.
Das Tool ist nicht unbedingt defekt; es fehlt ihm lediglich der Ausführungskontext, der erforderlich ist, um die Frage zu beantworten, die Sie interessiert.
Warum Teams abstumpfen
Müdigkeit, Angst, Nervosität: Nichts davon ist typisch für die Überwachung von Abhängigkeiten und CVE-Feeds, doch die Sicherheit von Abhängigkeiten ist eine große Quelle für alle drei.
Der Stapel an Tickets scheint endlos zu sein. Sie häufen sich immer schneller an, als man sie bearbeiten kann. Wenn man gerade die fünfzigste Sicherheitslücke geprüft hat und sich herausstellt, dass 49 davon irrelevant, nicht erreichbar oder bereits an anderer Stelle behoben sind, verliert die Kennzeichnung „hohe Schweregradstufe“ an Bedeutung. Das ist Alarmmüdigkeit.
Die wahren Kosten entstehen nicht durch das Geschwätz und die Warnmeldungen, sondern durch das, was dabei untergeht. Wenn jede Warnmeldung gleich behandelt wird, gilt das auch für diejenige, die tatsächlich wichtig ist. Überprüfungen werden zu reinen Abhakübungen: Audits laufen in CI, jemand wirft einen Blick auf die Anzahl, aber nichts wird wirklich überprüft. Irgendwann fügt jemand hinzu || true zum Prüfungsschritt, damit die Pipeline wieder grün wird, und diese Zeile überdauert die Erinnerung aller daran, warum sie überhaupt dort steht. Es ist nicht so, dass es niemandem mehr wichtig wäre. Der Rückstand ist einfach schneller gewachsen, als er abgearbeitet werden konnte.
Auch Upgrades haben ihren Preis. npm audit fix beschränkt sich auf Updates, die in die von Ihnen angegebenen Versionsbereiche passen. Alles, was außerhalb dieser Bereiche liegt – wozu auch eine Änderung der SemVer-Hauptversion gehören kann –, erfordert --force, und auch in der Dokumentation von npm selbst wird davor gewarnt, dies leichtfertig zu tun. Für manche Fehler gibt es überhaupt keine automatische Lösung. „Einfach aktualisieren“ ist keine so einfache Antwort, wie es zunächst klingt.
Ein vernünftigerer Triage-Pass
Das heißt aber nicht, dass man es ignorieren soll npm audit. Das bedeutet, dass man nicht jede Zeile der Ausgabe als gleich dringlich behandeln sollte, denn das ist sie nicht.
Ein paar Dinge, die tatsächlich helfen:
- Erreichbarkeit und Sichtbarkeit haben Vorrang vor der Schwere allein. Eine kritische CVE im Code, die in Ihrer Umgebung nicht erreichbar ist, hat in der Regel eine niedrigere Priorität als eine moderate CVE, die direkt bei der Bearbeitung Ihrer Anfragen auftritt. Schweregrade berücksichtigen Ihren Aufrufgraphen nicht, Sie jedoch schon.
- Trenne die Produktion von der Entwicklung und prüfe dann, was läuft. Ein anfälliges Tool zur Build-Erstellung und eine anfällige Laufzeitabhängigkeit erfordern in der Regel unterschiedliche Reaktionszeiten.
npm audit --omit=devDas ist zwar ein nützlicher erster Ansatz, aber Entwicklungswerkzeuge, die in der CI mit Anmeldedaten laufen, oder Code, den ein Bundler in die ausgelieferte Version einbindet, spielen nach wie vor eine wichtige Rolle. - Nach Paket gruppieren, nicht nach CVE. Eine einzige veraltete Bibliothek kann mehrere Sicherheitshinweise auslösen.
npm explain <package>zeigt, welche Ihrer Abhängigkeiten das Problem verursacht hat – dort liegt in der Regel die eigentliche Lösung. - Legen Sie einen Rhythmus fest, aber halten Sie sich dabei eine Hintertür offen. Führen Sie wöchentlich oder nach einem Zeitplan, der Ihrem Release-Zyklus entspricht, eine erneute Überprüfung durch, anstatt bei jeder Aktualisierung des Feeds eine neue Triage durchzuführen. Handeln Sie schneller, wenn Anzeichen für eine aktive Ausnutzung oder eine tatsächliche Gefährdung gegenüber dem Internet vorliegen.
- „Nicht jetzt“ sollte eine zulässige Antwort sein. Eine dokumentierte Entscheidung, ein Thema mit geringem Risiko zurückzustellen, ist nicht dasselbe wie es zu ignorieren. Notieren Sie sich, warum und wann Sie sich erneut damit befassen werden, und machen Sie dann weiter.
Das ist der Unterschied zwischen einer Triage und dem bloßen Löschen von Benachrichtigungen. Eine der beiden Maßnahmen senkt tatsächlich das Risiko.
Wo SecureChain zum Einsatz kommt
Hier ist der Unterschied, bei dem man ruhig ganz offen sein sollte: npm audit hat informativen Charakter. Es zeigt Ihnen, was falsch ist, und npm audit fix Die einfachen Korrekturen werden automatisch erledigt, aber die schwierigen Entscheidungen liegen weiterhin bei Ihnen. Es ist Ihre Aufgabe, herauszufinden, ob ein Upgrade zulässig und sicher ist, ob ein Patch zurückportiert werden muss oder ob ein EOL-Paket überhaupt im Upstream behoben wird.
SecureChain greift diesem Problem bereits im Vorfeld entgegen, anstatt den Berg an Warnmeldungen weiter anzuhäufen. Das öffentliche Register stellt jeden Tarball bereit, den ein Betreuer veröffentlicht hat. Die Signaturen des Registers zeigen, dass er seitdem nicht verändert wurde, doch sofern das Paket nicht mit einer Herkunftsbescheinigung ausgeliefert wird, gibt es keinen Hinweis auf das Quell-Repository. SecureChain erstellt Pakete aus verifizierten Quellen in gehärteten, isolierten Umgebungen neu und überprüft sie auf Malware und verdächtigen Code, bevor sie Ihren Abhängigkeitsbaum erreichen. npm audit ist nicht dafür ausgelegt, Typosquats, gehackte Betreuerkonten oder bösartige Installationsskripte eigenständig zu erkennen; es meldet lediglich, was bereits in den Sicherheitshinweisen enthalten ist. Patches richten sich nach den veröffentlichten Zielreaktionszeiten, unabhängig davon, ob der Upstream noch Korrekturen bereitstellt oder nicht mehr aktiv ist, und sobald für ein Paket monatelang kein Upstream-Release mehr veröffentlicht wurde, Endless Lifecycle Support stellt regelmäßig Updates für die Version bereit, die Sie bereits nutzen.
Nichts davon lässt die Triage verschwinden. Was sich ändert, ist der Umfang der Unsicherheit, die Sie übernehmen, bevor ein Paket Ihren Build erreicht. Pakete werden so erstellt und signiert, dass sie SLSA Level 3 unterstützen, und sie enthalten VEX-Daten sowie – je nach Paket – SBOMs. Das ist der Teil, den niemand manuell erstellen möchte, den die meisten Teams aber letztendlich für ein Audit benötigen. VEX geht am direktesten auf das Problem der „Rauschanteile“ ein, da es genau aufzeigt, welche bekannten CVEs eine bestimmte Paketversion tatsächlich betreffen.
Der entscheidende Blickwinkel in diesem Zusammenhang: SecureChain ist kein weiterer Feed, der um Ihre Aufmerksamkeit buhlt. Es landen von vornherein weniger Dinge in Ihrer Warteschlange, da ein Großteil des Problems bereits gelöst wurde, bevor es zu Ihrem Problem wurde.
