package.json Vulnerability Scanner and npm License Check

What the scanner checks

Paste a package.json and the scanner reads its dependencies, devDependencies and optionalDependencies in your browser. Nothing leaves the page until you press Check packages. Then it does three things:

1. Pins a version for each direct dependency. With a lockfile, that is the version you installed. Without one, it asks the npm registry for the package's versions and picks the one npm would install today: the latest tag when your range allows it, otherwise the highest matching version that is not deprecated.
2. Asks OSV about every package version in batches, through its querybatch endpoint, with the ecosystem set to npm.
3. Loads each advisory OSV returns: its severity, summary, affected ranges, fixed versions and aliases, with a link to the full record on osv.dev.

It also reads each direct dependency's manifest on npm for its license. The numbers it relies on, from the severity scale to OSV's limits, are in the table further down.

Why the lockfile matters

A range such as ^4.17.0 allows every 4.x release from 4.17.0 up, so the package.json alone cannot say what you run. The lockfile can. It records the exact version of every package in the install, including the dependencies of your dependencies.

The scanner reads package-lock.json from npm, in lockfile versions 1 to 3, and pnpm-lock.yaml from version 5 to version 9. For pnpm it reads the keys of every packages section, such as vue@3.5.13, and drops the peer suffix pnpm adds in parentheses. That includes the first document pnpm writes into the same file for config dependencies and its own version, which a scanner reading only one document would miss. Entries that name no registry version, such as git, file and link dependencies, are counted and skipped.

Without a lockfile, a clean result says only that today's versions of your direct dependencies have no known advisory. Run it again with the lockfile before you trust it.

How severity is read

OSV records come from several databases, and the scanner reads their severity in this order:

1. A record from the OpenSSF Malicious Packages repository, with an ID starting MAL-, is malicious. There is no safe version of a malicious package; remove it.
2. A record from the GitHub Advisory Database carries GitHub's own rating, which the scanner shows as written: Critical, High, Moderate or Low.
3. A record with only a CVSS v3 vector gets its base score from the CVSS v3.1 equations and the rating that score falls in.
4. Anything else shows as unrated. Open it on osv.dev to judge it yourself.

Where a record has a CVSS v3 vector, its base score appears beside the rating. GitHub's reviewers can rate an advisory outside its score's band, as with express's res.redirect XSS, rated Low with a base score of 5.0, so the two can disagree. A base score describes the flaw itself, not whether your code reaches it, so read the summary before you decide how fast to move.

How licenses are sorted

npm's license field holds an SPDX expression such as MIT or (MIT OR GPL-3.0-or-later), a pointer such as SEE LICENSE IN LICENSE.md, or UNLICENSED for a package that grants no rights to use it. Older packages use a license object or a licenses array, which the scanner also reads.

Each license ID is matched against the Blue Oak Council's permissive list and its copyleft list, which groups copyleft licenses into weak, strong, network and maximal families. In an expression, OR gives you the choice, so the most permissive option counts; AND binds you to both, so the most restrictive one counts. Deprecated IDs such as GPL-2.0 read as GPL-2.0-only, and GPL-2.0+ as GPL-2.0-or-later.

The check covers direct dependencies only, at the version that was checked. A family tells you what to read first, not what you may do. Whether a license fits depends on how you ship, so ask a lawyer when it matters.

When a package is vulnerable

Start with the advisory's fix line. When a fixed version is published, update the direct dependency, or the one that pulls the package in, to a release that uses it:

npm explain minimist
pnpm why minimist

When no release of the parent has moved yet, you can force the fixed version for the whole tree. npm reads overrides from package.json:

{
  "overrides": {
    "minimist": "1.2.8"
  }
}

pnpm reads overrides from pnpm-workspace.yaml. Either way, run your tests after, because the parent package was never tested against the version you forced.

A clean result is not a guarantee. OSV lists problems someone has found and reported, so scan again when you add a dependency and before each release.