Check npm Package Versions for Vulnerabilities

Node.js applications often contain hundreds of direct and transitive modules, so copying advisory pages into tickets does not scale. The OSV Vulnerability Scraper checks explicit npm package versions and returns portable security records that can be joined to lockfiles and ownership data.

Format regular and scoped packages

Regular names and scoped modules use the same ecosystem prefix:

{"packages":["npm:lodash@4.17.20","npm:axios@1.6.0","npm:@scope/package@1.2.3"],"maxResultsPerPackage":20}

The parser separates the final version marker without damaging the leading @scope. Results include advisory identities, aliases, full affected ranges, fixed-version events, severity material, references, and the original package input. This makes the dataset suitable for a remediation table containing repository, service, dependency path, owner, and upgrade target.

Check the lockfile's resolved version rather than the loose range in package.json. A declared caret range can resolve to a safe or affected version depending on install history. For monorepos, create one normalized package/version inventory and deduplicate identical checks before the run, then fan results back out to every workspace that uses the package.

Treat a fixed boundary as evidence, not an automatic upgrade instruction. The first fixed release may include breaking behavior, and a vulnerable package can be unreachable in a specific application. Review the upstream advisory and patch notes, test the chosen target, and keep compensating controls visible until rollout completes.

Schedule checks after dependency updates and at least daily for critical services. Compare advisory IDs between snapshots to detect new disclosures, changed ranges, and withdrawals. That incremental feed is more useful than repeatedly opening a broad dashboard with no link to deployed versions.