npm audit returns 94 findings and a customer's security questionnaire asks whether your deployed application is affected. The honest answer needs a distinction the audit output does not draw: which of those packages your running application actually loads, and which exist only so that your tests, bundler, linter and type checker can run.
Open the free lockfile evidence tool
A package-lock.json (v2 or v3) records, for every installed package, whether it was reached only through devDependencies. npm marks those entries dev: true. Anything reachable from your declared runtime dependencies — directly or transitively — is not marked, and a package reached by both paths counts as production, because it is.
That single flag is the evidence behind "this finding is in our test runner." It is already in the file you have; it is just not what a headline audit count shows you.
A dev-only finding is not a finding you can ignore. Build and test dependencies execute on developer machines and in CI, where they can reach source code, environment variables, and deployment credentials — a path that real supply-chain attacks have used repeatedly. The classification changes the question being answered: whether your deployed application is affected is not the same question as whether your pipeline is.
package-lock.json into the page, or paste its contents. Parsing runs in your browser — the file is never uploaded, and there is no server to upload it to.The same classification rules are available as a CLI in the repository, so the check can run in CI on every change rather than only when someone asks. The tool has no vulnerability database and makes no network calls; it adds reachability context to a scanner's output rather than replacing it.
Only the ones on the production dependency path — the packages reachable from your declared dependencies rather than from devDependencies. A lockfile records this: npm marks dev-only entries with a dev flag, and a package reachable from both paths is not dev-only. Separating the two usually shrinks a frightening audit count substantially, because test runners, bundlers, linters and type tooling pull in a large share of a typical dependency tree and none of it is shipped to users.
No. It means the exposure is different, not absent. A compromised build or test dependency runs on developer machines and in CI, where it can read source, secrets and tokens — that is a real and serious risk, and supply-chain attacks have repeatedly used exactly that path. What the distinction changes is triage order and the honest answer to 'is our deployed application affected', which is a different question from 'is our build pipeline affected'.
No, and it deliberately does not try to be. It reads a package-lock.json you supply and reports which dependencies reach the production path and which npm marks dev-only. It has no vulnerability database, makes no network calls, and never uploads the lockfile. Use it to give a scanner's output the reachability context it lacks, not to replace the scanner.