npm audit

Kurz: Ein eingebauter npm-Befehl, der die installierten Abhängigkeiten eines Projekts gegen eine Datenbank bekannter Sicherheitslücken prüft.

Genauer: Ergebnis ist nach Schweregrad sortiert (kritisch/hoch/moderat/niedrig). npm audit fix behebt automatisch, was ohne Breaking Changes geht; npm audit fix --force behebt auch den Rest, kann dabei aber Pakete auf inkompatible Versionen zwingen. “No fix available” heißt, die Paket-Maintainer selbst haben noch keine gepatchte Version veröffentlicht.

Kontext bei uns: Beim Neu-Generieren des package-lock.json gefunden — 22 Schwachstellen, 15 automatisch ohne Breaking Change behoben, die restlichen 15 hängen an Capacitor-Build-Tools (nur für die Mobile-App relevant, kein Fix verfügbar) und wurden bewusst nicht erzwungen.

Im Detail

Was genau geprüft wird

npm audit prüft dabei nicht nur die direkt in package.json gelisteten Abhängigkeiten, sondern den kompletten Abhängigkeitsbaum inklusive aller transitiven Abhängigkeiten (Pakete, die von den eigenen Paketen selbst wieder importiert werden) — eine Schwachstelle kann also tief verschachtelt in einem Paket stecken, von dem man selbst noch nie gehört hat, aber indirekt mitinstalliert. Der Befehl selbst installiert nichts, er vergleicht nur die im package-lock.json fixierten Versionen gegen eine öffentliche Datenbank bekannter Schwachstellen (die npm-Registry-Advisory-Datenbank, die wiederum auf öffentlich gemeldeten CVEs — Common Vulnerabilities and Exposures — basiert).

Schweregrade und ihre Bedeutung

Die vier Schweregrade (kritisch/hoch/moderat/niedrig) spiegeln typischerweise das CVSS-Scoring-System (Common Vulnerability Scoring System) wider, mit dem Sicherheitslücken branchenweit standardisiert bewertet werden. Kritische und hohe Schwachstellen betreffen meist Dinge wie Remote Code Execution oder das Umgehen von Authentifizierung, während niedrige Einstufungen oft theoretische oder nur unter sehr speziellen Bedingungen ausnutzbare Probleme betreffen. Wichtig: Die Einstufung bezieht sich auf das Paket isoliert betrachtet — ob eine Schwachstelle im EIGENEN Projekt tatsächlich ausnutzbar ist, hängt davon ab, ob der verwundbare Code-Pfad überhaupt mit ungeprüften/externen Daten erreicht wird.

Grenzen von npm audit fix --force

Wichtig bei npm audit fix --force: Der Befehl versucht zwar, die Verwundbarkeit zu beheben, kann dafür aber auf eine neue Major-Version eines Pakets springen — und Major-Versionen sind per semantischer Versionierung explizit NICHT abwärtskompatibel garantiert. Nach einem erzwungenen Fix ist deshalb ein vollständiger Test-/Build-Durchlauf Pflicht, nicht optional, bevor man dem Ergebnis vertraut. In der Praxis kann --force sogar dazu führen, dass ein Paket auf eine Version springt, die andere Abhängigkeiten im selben Projekt bricht (Peer-Dependency-Konflikte) — der Befehl optimiert primär auf “Schwachstelle weg”, nicht auf “Projekt bleibt funktionsfähig”.

Wenn kein Fix verfügbar ist

Eine Schwachstelle ohne verfügbaren Fix (“no fix available”) bedeutet meist eines von zwei Dingen: entweder die Maintainer des betroffenen Pakets haben die Lücke noch nicht gepatcht, oder das Paket wird gar nicht mehr aktiv gepflegt — in letzterem Fall bleibt oft nur, das Paket durch eine aktiv gepflegte Alternative zu ersetzen. Bevor man eine ungepatchte Schwachstelle ignoriert, lohnt sich eine kurze Prüfung, ob der verwundbare Code-Pfad im eigenen Projekt überhaupt erreichbar ist — viele gemeldete Schwachstellen betreffen sehr spezifische Funktionsaufrufe eines Pakets, die ein Projekt vielleicht gar nicht nutzt, wodurch das reale Risiko trotz formal bestehender Schwachstelle gering sein kann.

Kontinuierliche Überwachung statt Einmalprüfung

Da laufend neue Schwachstellen entdeckt und gemeldet werden, ist ein einmaliger npm audit-Lauf nur eine Momentaufnahme — ein zum Zeitpunkt der Installation sauberes Projekt kann Wochen später neue Meldungen aufweisen, ohne dass sich am eigenen Code irgendetwas geändert hätte. Viele Teams integrieren deshalb npm audit (oder äquivalente Tools wie GitHub Dependabot) in ihre CI-Pipeline, um regelmäßig automatisch auf neue Schwachstellen zu prüfen, statt sich auf gelegentliche manuelle Läufe zu verlassen.

Siehe auch: GitHub