npm audit online: scan your lockfile

How the audit works

The tool reads your lockfile in the browser. For package-lock.json it supports lockfile versions 1, 2 and 3, and it reads yarn.lock in the classic format. It builds a list of every distinct package and version, and marks the ones that are only development tools where the lockfile says so. Local folders, links and git or file dependencies are skipped, because they are not registry releases.

It then asks OSV (osv.dev), the open vulnerability database run by Google, which of those versions have a published advisory. Only package names and version numbers are sent, in batches. The lockfile, your registry addresses and any tokens stay on your device. For each advisory found, the tool reads the details and works out the fixed version for the release line you are on, because many advisories list a separate fix for each line.

The report groups the results by package and sorts them by severity. Advisories that start with MAL are reports of malicious packages: code that steals secrets or runs commands when installed. Remove those and assume any secret the machine could reach is exposed.

What to do with the result

Start with the critical and high items that are not development-only. Run npm audit fix first. It applies every fix that stays inside the version ranges you allow. For a package that remains, find what pulls it in with npm ls and update that parent. A flaw in a development tool matters less to a running site but still matters to your build machine, so do not ignore it.

An advisory is a published flaw, not proof of an attack on you. Whether it can be exploited depends on how your code calls the package. That is why the report keeps the advisory identifiers, so you can read the details. Add the check to your build pipeline as well, because new advisories appear every day for versions that were clean yesterday.