Scanning package-lock.json for known vulnerabilities: npm audit, OSV.dev, and the gaps in both

A medium-sized Next.js project has 500 to 1,500 packages in its package-lock.json, twenty of which you chose yourself. The other thousand are transitive dependencies nobody has ever looked at. That's where the vulnerabilities are, and that's also where the noise is, because half of them only run during npm run build and never touch a production server. This article builds a scan that knows the difference.

Step 1: what npm audit does and doesn't do

cd /srv/app
npm audit --omit=dev            # production dependencies only
npm audit --omit=dev --json | jq '.metadata.vulnerabilities'
# { "info": 0, "low": 0, "moderate": 0, "high": 3, "critical": 1, "total": 4 }
npm audit --omit=dev --json | jq -r '.vulnerabilities | to_entries[] | "\(.value.severity)\t\(.key)\t\(.value.range)\tfixAvailable=\(.value.fixAvailable != false)"' | sort

npm audit queries the GitHub Advisory Database (via the npm registry) and is fine as a first check. Three limitations:

• It reports at advisory level (GHSA), not always with a CVE id, and the severity is the advisory's: not weighted for your usage.
• It only sees what's in your lockfile. A package that arrives via a Docker image, or that npx fetches on the fly, falls outside.
• fixAvailable: false means there's no semver-compatible upgrade; that's usually where the work starts, not where it stops.

For a second source with CVE ids, fix versions and a stable API: OSV.dev.

Step 2: parse the lockfile into an exact list

Lockfile v2/v3 (npm ≥ 7) has a packages object with the exact version per installed path and a dev flag. That's all you need:

# Production dependencies: name version
jq -r '.packages | to_entries[] | select(.key != "" and (.value.dev // false | not))
       | "\(.key | sub("^.*node_modules/"; "")) \(.value.version)"' package-lock.json | sort -u > /tmp/prod.txt
# Dev dependencies separately (build tooling: relevant for your CI runner, not for production)
jq -r '.packages | to_entries[] | select(.key != "" and (.value.dev // false))
       | "\(.key | sub("^.*node_modules/"; "")) \(.value.version)"' package-lock.json | sort -u > /tmp/dev.txt
wc -l /tmp/prod.txt /tmp/dev.txt

The sub("^.*node_modules/"; "") reduces nested paths (node_modules/a/node_modules/b) to the package name; sort -u deduplicates the same version nested multiple times. Different versions of the same package stay separate: rightly so, because they're vulnerable separately.

Step 3: query OSV.dev in batches of 900

The same endpoint as for OS packages, with ecosystem npm:

sudo apt install -y jq curl
scan() {  # scan <list> <output.jsonl>
  : > "$2"; split -l 900 "$1" /tmp/npmbatch.
  for f in /tmp/npmbatch.*; do
    jq -Rn '{queries: [inputs | split(" ") | {package: {name: .[0], ecosystem: "npm"}, version: .[1]}]}' "$f" \
    | curl -s -m 60 -X POST https://api.osv.dev/v1/querybatch -H 'Content-Type: application/json' -d @- \
    | jq -c --slurpfile q <(jq -Rn '[inputs | split(" ")]' "$f") '
        .results | to_entries[] | select(.value.vulns != null)
        | {pkg: $q[0][.key][0], version: $q[0][.key][1], vulns: [.value.vulns[].id]}' >> "$2"
  done; rm -f /tmp/npmbatch.*
}
scan /tmp/prod.txt /tmp/osv-prod.jsonl
scan /tmp/dev.txt  /tmp/osv-dev.jsonl
jq -r '"\(.pkg)@\(.version): \(.vulns|join(", "))"' /tmp/osv-prod.jsonl
# js-yaml@4.3.0: GHSA-2883-xcg3-v3hh, GHSA-5p4m-2wfm-xmqj
# nanoid@3.3.15: GHSA-28wg-ghj8-5hjv, GHSA-2v37-7h3g-55p8

Step 4: from advisory to CVE, severity and fix version

: > /tmp/osv-detail.jsonl
for id in $(jq -r '.vulns[]' /tmp/osv-prod.jsonl | sort -u); do
  curl -s "https://api.osv.dev/v1/vulns/$id" | jq -c '{
    id,
    cve: ((.aliases // []) | map(select(startswith("CVE-"))) | first),
    severity: (.database_specific.severity // "unknown"),
    fixed: ([.affected[] | select(.package.ecosystem=="npm") | .ranges[]?.events[]? | .fixed? // empty] | first),
    summary }' >> /tmp/osv-detail.jsonl
  sleep 0.1
done
jq -r '[.id, (.cve // "-"), .severity, (.fixed // "no fix"), .summary[0:60]] | @tsv' /tmp/osv-detail.jsonl | column -t -s $'\t'

The fixed column is your work list. If there's a version: npm install pkg@^version or, for a transitive dependency, an overrides block in package.json:

{
  "overrides": {
    "js-yaml": ">=4.3.1",
    "nanoid": ">=3.3.16"
  }
}

Then npm install, npm test, and scan again. An override that breaks the build signals that the upgrade contains a breaking change: then it's a ticket, not a commit.

Step 5: what really counts, reachability and EPSS

A vulnerability in a package that's in your lockfile isn't automatically a vulnerability in your application. Two filters:

# 1. Is the package loaded at all? Look for imports in your own code.
for p in $(jq -r '.pkg' /tmp/osv-prod.jsonl | sort -u); do
  n=$(grep -rlE "from ['\"]$p['\"/]|require\(['\"]$p['\"/]" src/ 2>/dev/null | wc -l)
  printf '%-30s direct imports in src/: %s\n' "$p" "$n"
done
# 0 = transitive only; then the package importing it determines whether the vulnerable code is reachable

# 2. EPSS: probability of exploitation within 30 days (see the OS package guide for the batch version)
jq -r '.cve // empty' /tmp/osv-detail.jsonl | sort -u | head -100 | paste -sd, - \
  | xargs -I{} curl -s "https://api.first.org/data/v1/epss?cve={}" | jq -r '.data[] | [.cve, .epss] | @tsv'

"Transitive, EPSS 0.001, no fix" is an accepted risk you document in one line. "Directly imported, EPSS 0.4, fix available" is this afternoon.

Step 6: weekly, with history

sudo tee /usr/local/sbin/npm-cve-scan.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
# npm-cve-scan.sh <project dir>: writes /var/lib/cve-scan/npm/<project>-<date>.tsv
set -euo pipefail
P=$1; N=$(basename "$P"); D=/var/lib/cve-scan/npm; mkdir -p "$D"
cd "$P"
jq -r '.packages | to_entries[] | select(.key != "" and (.value.dev // false | not)) | "\(.key | sub("^.*node_modules/"; "")) \(.value.version)"' package-lock.json | sort -u > /tmp/prod.$$
: > /tmp/osv.$$; split -l 900 /tmp/prod.$$ /tmp/b.$$.
for f in /tmp/b.$$.*; do
  jq -Rn '{queries: [inputs | split(" ") | {package: {name: .[0], ecosystem: "npm"}, version: .[1]}]}' "$f" \
  | curl -s -m 60 -X POST https://api.osv.dev/v1/querybatch -H 'Content-Type: application/json' -d @- \
  | jq -r --slurpfile q <(jq -Rn '[inputs | split(" ")]' "$f") '.results | to_entries[] | select(.value.vulns != null) | "\($q[0][.key][0])\t\($q[0][.key][1])\t\([.value.vulns[].id]|join(","))"' >> /tmp/osv.$$
done
sort /tmp/osv.$$ > "$D/$N-$(date +%F).tsv"; rm -f /tmp/prod.$$ /tmp/osv.$$ /tmp/b.$$.*
prev=$(ls -1 "$D/$N-"*.tsv | grep -v "$(date +%F)" | tail -1 || true)
if [ -n "$prev" ]; then
  new=$(comm -13 <(cut -f1,2 "$prev") <(cut -f1,2 "$D/$N-$(date +%F).tsv"))
  [ -n "$new" ] && printf 'NEW vulnerable packages in %s:\n%s\n' "$N" "$new" | curl -s -H "Title: npm cve $N" -H "Priority: high" --data-binary @- https://ntfy.example.be/cve >/dev/null
fi
echo "$D/$N-$(date +%F).tsv: $(wc -l < "$D/$N-$(date +%F).tsv") vulnerable packages"
EOF
sudo chmod 0755 /usr/local/sbin/npm-cve-scan.sh
echo '30 6 * * 1 root /usr/local/sbin/npm-cve-scan.sh /srv/app' | sudo tee /etc/cron.d/npm-cve-scan

Pitfalls

• Lockfile v1. Projects with npm 6 have a dependencies tree instead of packages. npm install --package-lock-only with npm ≥ 7 converts it. Without a lockfile a scan is pointless: then you don't know what's installed.
• Scanning package.json instead of the lockfile. "express": "^4.18.0" doesn't say which version runs. Always the lockfile, and always the lockfile on the server (or in the image), not the one in your git checkout from last month.
• Bundlers. After next build or vite build the vulnerable code sits in a bundle; the node_modules on the server may not even be needed. Then scan the lockfile the bundle was built with (in CI, with a date).
• npm audit fix --force. Installs major upgrades without asking. Never in CI, never without npm test afterwards.
• Scopes. @scope/pkg works in the OSV query as expected; jq's sub("^.*node_modules/"; "") keeps the scope intact. Check once with grep '^@' /tmp/prod.txt.
• Lifecycle scripts. A vulnerability is one thing; a package running a postinstall script on npm install is a supply-chain vector in its own right. jq -r '.packages | to_entries[] | select(.value.hasInstallScript) | .key' package-lock.json lists them.

What you still don't have

• All projects on all hosts. One cron per project is doable for three projects; at thirty you're maintaining an inventory of where which lockfile lives.
• Other ecosystems. requirements.txt, composer.lock, go.sum, Cargo.lock: each with its own parsing, the same OSV API.
• The link to what's running. A lockfile on disk doesn't say whether the app using it still runs, or on which port. That's the step from "CVE in a file" to "CVE on an internet-facing host".

How monsys does it

The monsys agent finds lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, composer.lock, go.sum) on the host, parses them and ships the package list to the hub; the dependency scanner checks it against OSV.dev, enriches with EPSS and KEV, and links every lockfile to the application and the host it runs on, including hop distance to the internet. postinstall scripts are reported as separate supply-chain signals. For a vulnerability you deliberately don't patch, you record a VEX statement with date and reason; it appears in the audit pack next to the CVE.

FAQ

Is npm audit enough?

As a first filter yes. For a complete picture no: it doesn't give CVE ids for every advisory, doesn't weight severity by reachability, and only sees what's in your lockfile. OSV.dev as a second source plus a reachability check gives a list you can defend.

Should I scan dev dependencies too?

Yes, but separately. They run on your CI runner and on developers' laptops, not in production. A vulnerable esbuild is a risk for the build environment (supply chain), not for your customers, and that difference belongs in your prioritisation.

What do I do with a vulnerability without a fix?

Assess whether the vulnerable code is reachable in your usage, look at EPSS, and document the decision (patch when fixed, mitigate, or accept) with a date. That's exactly what a VEX statement is for.