Separate the two. Say whether you check dependencies for known vulnerabilities, and say separately what you do about malicious or tampered packages: allowlists, lockfiles, review of new additions and delayed adoption of brand new versions. Do not claim malware detection you do not run.
Two different problems
A known vulnerability is a flaw in legitimate code that has been catalogued, usually with an identifier. A malicious package is code published to cause harm, often through a lookalike name, a hijacked maintainer account or a compromised build. Vulnerability scanners match against advisories, so a brand new malicious release may appear in no database yet.
Customers sometimes lump the two together. Your answer should not.
What you can honestly describe
| Control | What it addresses |
|---|---|
| Lockfiles and exact versions | Unexpected version changes |
| Clean installs in CI | Drift between lock and manifest |
| Review of new dependencies | Lookalike and unnecessary packages |
| Provenance checks where offered | Unknown build origin |
| Private mirror or allowlist | Direct pulls from public registries |
| Waiting period for fresh releases | Exposure to very new malicious versions |
npm documents that npm ci requires an existing lock file and exits with an error if the lock does not match the manifest, which makes it suitable for automated builds. npm also states that provenance gives a verifiable link to source and build instructions but does not guarantee a package is free of malicious code.
What not to say
- "We detect all malicious packages." Nobody can promise that.
- "Provenance means the package is safe." The registry documentation says otherwise.
- "We scan for malware" if you just match advisories.
Reply template
We distinguish known vulnerabilities from malicious packages. For vulnerabilities, we match our component inventory against advisory data. For malicious or tampered packages, we pin versions with lockfiles, install from the lock in CI, review new dependencies, and check provenance where the registry provides it. We do not claim to detect every novel malicious release.
That last sentence is the one customers remember.
Related reading: malicious package detection tools and abandoned package takeover risks.
A worked example
Suppose a customer asks, "Do you scan for malicious packages?" and you run an advisory scanner plus lockfile installs. The accurate reply separates the layers. The scanner matches your inventory to published advisories, so it will flag a malicious release once an advisory exists for it. The window before that advisory is what lockfiles, clean installs and delayed adoption of brand new versions are meant to narrow.
If a customer pushes for more, offer to walk through one real example: a new dependency request, the review notes, the lockfile change and the build log. A single concrete trace answers the question better than a longer paragraph of claims.
Quick check
Does a lockfile stop a malicious package?
It stops silent version changes. It does not make the version you locked trustworthy.
Is signed provenance enough?
It tells you where and how a package was built. You still decide whether to trust that source.
Sources
Last reviewed: 19 October 2026.
