npm audit

In short: A built-in npm command that checks a project’s installed dependencies against a database of known security vulnerabilities.

In more detail: The result is sorted by severity (critical/high/moderate/low). npm audit fix automatically fixes whatever is possible without breaking changes; npm audit fix --force also fixes the rest, but can force packages onto incompatible versions in the process. “No fix available” means the package maintainers themselves haven’t released a patched version yet.

Our context: Found while regenerating package-lock.json — 22 vulnerabilities, 15 fixed automatically without breaking changes; the remaining 15 depend on Capacitor build tools (only relevant for the mobile app, no fix available) and were deliberately not forced.

In Depth

What exactly is checked

npm audit checks not only the dependencies listed directly in package.json, but the complete dependency tree including all transitive dependencies (packages that are in turn imported by your own packages) — so a vulnerability can be buried deep in a package you’ve never even heard of but that was installed indirectly. The command itself installs nothing; it only compares the versions pinned in package-lock.json against a public database of known vulnerabilities (the npm registry advisory database, which in turn is based on publicly reported CVEs — Common Vulnerabilities and Exposures).

Severity levels and what they mean

The four severity levels (critical/high/moderate/low) typically reflect the CVSS scoring system (Common Vulnerability Scoring System), which is used to rate security vulnerabilities in a standardised way across the industry. Critical and high vulnerabilities usually concern things like remote code execution or bypassing authentication, while low ratings often concern theoretical problems or ones that can only be exploited under very special conditions. Important: the rating refers to the package considered in isolation — whether a vulnerability can actually be exploited in YOUR project depends on whether the vulnerable code path is reached with unchecked/external data at all.

Limits of npm audit fix --force

Important with npm audit fix --force: the command does try to fix the vulnerability, but to do so it can jump to a new major version of a package — and major versions are, by semantic versioning, explicitly NOT guaranteed to be backwards compatible. After a forced fix, a complete test/build run is therefore mandatory, not optional, before you trust the result. In practice, --force can even cause a package to jump to a version that breaks other dependencies in the same project (peer dependency conflicts) — the command optimises primarily for “vulnerability gone”, not for “project keeps working”.

When no fix is available

A vulnerability without an available fix (“no fix available”) usually means one of two things: either the maintainers of the affected package haven’t patched the hole yet, or the package isn’t actively maintained any more — in the latter case, often the only option is to replace the package with an actively maintained alternative. Before ignoring an unpatched vulnerability, it’s worth briefly checking whether the vulnerable code path is reachable in your own project at all — many reported vulnerabilities concern very specific function calls of a package that a project may not use at all, which can make the real risk low despite the formally existing vulnerability.

Continuous monitoring instead of a one-off check

Since new vulnerabilities are constantly discovered and reported, a one-off npm audit run is just a snapshot — a project that was clean at the time of installation can show new reports weeks later without anything in your own code having changed. Many teams therefore integrate npm audit (or equivalent tools such as GitHub Dependabot) into their CI pipeline to automatically and regularly check for new vulnerabilities, instead of relying on occasional manual runs.

See also: GitHub