batch_query_vulnerabilities

io.github.salemalem/npmscan · Verify this server

Check a whole npm dependency inventory against OSV.dev in one call: pass `packages: [{name, version?}]`, or raw package.json / package-lock / yarn.lock / pnpm-lock / CycloneDX / SPDX content via `content`. Large inventories are chunked automatically. Each finding has severity, summary, CVE aliases, fixedVersion and isMalware, so no per-package follow-up is needed. Before calling anything clean, read: - `unresolvedPackages`/`nonexistentVersions` (and each result's `registryStatus`): a name or version not on npm shows vulnerabilityCount 0 just like a clean package. A version npm removed can still have real OSV findings (often malware). - A `packages` entry with no version is checked against every historical version; confirm against the version actually in use before calling it vulnerable. - `signals` (deprecated, hasInstallScripts, popularity/maintenance tiers, possibleTyposquatOf): 0 vulnerabilities can still be deprecated, abandoned or a typosquat. `signals` is null for git/file/workspace/URL entries, which are not scanned. - `source` (lockfile input): `nonRegistryHost` means the tarball comes from an unexpected host; `identityMismatch` means it is a different package/version than declared (`resolvedName`/`resolvedVersion`) and the counts describe the declared one. Treat both as lockfile tampering. - Use `uniqueVulnerabilityCount` for distinct issues; raw counts can list one CVE twice. - package.json input: `projectLifecycleScripts`/`projectLifecycleScriptRisk` are the project's own install scripts; peerDependencies are skipped unless `includePeerDependencies: true` (see `ignoredPeerDependencyNames`); `declaredSpec` marks a version resolved from a range, which can change on the next install. - npm aliases are followed: `package.actualName` is the real package the data describes.