CVE based scanning looks up known flaws in legitimate software. A malicious package is deliberately harmful code, not an accidental bug, so it often has no CVE and no affected version range to match. Catching it needs separate malware reports, install time controls and review.
Two different problems
A vulnerability is a mistake in a library that people use on purpose. An advisory says versions A to B are affected, fixed in C. A malicious package is a different thing: a package built to steal, destroy or take control, often named to look like a real one.
Because it is not a flaw in someone's product, the usual route of CVE assignment and a version range does not fit. Scanning your lockfile against a vulnerability list will pass such a package, because there is nothing to match.
Where malware reports live
The OpenSSF malicious-packages repository describes itself as a repository of reports of malicious packages identified in open source package repositories, consumable through the Open Source Vulnerability format. That format is the same one used for ordinary advisories, so tools that read it can treat malware reports as another feed.
Whether your scanner consumes such a feed is a question to ask, not assume. See CVE, GHSA and OSV IDs: what are the differences.
What a layered defence looks like
| Control | What it stops |
|---|---|
| Malware feed matching | Packages already reported |
| Delay on brand new versions | Fresh malicious releases not yet reported |
| Install script restrictions | Code running at install time |
| Private mirror with allowlist | Unknown or lookalike packages |
| Lockfile review in pull requests | Surprise new dependencies |
No row catches everything alone. Reports lag behind publication, so the delay and review rows matter.
Practical steps
- Ask your scanner vendor which malware sources it uses and how fast they update.
- Review new dependencies in pull requests, checking name spelling and publisher.
- Turn off or restrict install scripts where your tooling allows it.
- Consider a waiting period before adopting a version released only hours ago.
- Keep lockfiles committed, so unexpected changes show up in diffs.
For related controls see does a private package mirror stop malicious versions.
What to tell leadership
A clean vulnerability scan does not say there is no malware in dependencies. It says no known flaws matched. Say that sentence plainly in reports.
Try it yourself
Click through it at your own pace, or open it full screen. See how ongoing monitoring catches new information after a build, which is how late malware reports reach you.
Safeguard offers dependency scanning with continuous monitoring and a free scan at gold.safeguard.sh/scan. Ask any tool what malware data it uses.
Quick check
Do malicious packages ever get CVEs?
Sometimes, but many are tracked only as malware reports, so do not depend on CVE data alone.
Is a lockfile enough protection?
It stops silent drift. It does not tell you the pinned package is safe.
Sources
Last reviewed: 19 October 2026.
