# Reconciling npm audit vs snyk vulnerability counts

## TL;DR
The counts differ because the tools count different things: snyk's database covers more advisory sources, npm audit and snyk handle devDependencies and severity thresholds differently, and each may count one advisory per package while the other counts per path. Align the scopes (prod vs all, same severity floor) and compare package-by-package instead of trusting the headline numbers.

```text
npm audit reports 6 vulnerabilities but snyk reports 11 for the same package.json - reconciling the counts
```

## Steps

1. Capture both reports in a comparable form.
   - Run: npm audit --json > npm-audit.json && snyk test --json > snyk.json
   - Expected: two JSON reports for the same package.json.

2. Check whether devDependencies are included on both sides, since that is the most common source of count drift.
   - Run: snyk test --prod and compare against npm audit (which defaults to including dev deps unless configured otherwise)
   - Expected: the gap shrinks when both sides use the same dependency scope.

3. Normalize the severity floor. A scanner set to report low severity will always count more.
   - Run: snyk test --severity-threshold=high and compare with npm audit's default threshold
   - Expected: you can see how many of the extra findings are just lower-severity advisories.

4. Diff the actual package lists, not the totals.
   - Run: python3 -c comparing the package names in npm-audit.json advisories vs snyk.json vulnerabilities
   - Expected: a short list of packages only one tool flags, which you then investigate individually (usually a snyk-only advisory source or an npm audit blind spot).

## Use this when
- npm audit and snyk report different vulnerability counts for the same package.json
- A security review asks which scanner's number is "right"
- An agent needs to pick one count for a dashboard or ticket

## Not for this skill when
- Both tools agree on the count but disagree on severity (that is a scoring question)
- The manifests differ between the two runs (lockfiles out of sync)
- You only run one of the two tools (pick the reconciliation approach for the tools you have)

## Variant phrasings
- npm audit vs snyk different vulnerability count
- snyk reports more vulnerabilities than npm audit
- why do npm audit and snyk disagree

## Why it happens
npm audit draws on the GitHub Advisory Database as surfaced through the npm registry, while snyk maintains its own larger database that aggregates more sources (including its own research and additional ecosystems). On top of that, the two tools default to different scopes and group findings differently: one advisory affecting three dependency paths can count as one finding in one tool and three in the other. Different inputs plus different counting rules guarantee different headline numbers.

## Edge cases
- Stale lockfile: if package-lock.json is out of sync with package.json, the tools may scan different trees; regenerate the lockfile first.
- snyk monitor vs snyk test: monitored projects snapshot at import time, so a fresh snyk test can differ from the dashboard; re-import after manifest changes.
- Neither tool is authoritative alone: for a disputed finding, check the upstream advisory (GitHub Advisory Database entry) directly.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_s1VXiJ5g7ZxCUmiVRIwJaQ