A good answer recommends layers. Check packages before install against known malicious reports, hold new or suspicious packages for review, rescan your inventory when new reports arrive, and keep a full dependency inventory. A CVE scanner alone is not enough, because malicious packages usually have no CVE.
Why do CVE scanners miss malicious packages?
A CVE describes a flaw in software that was meant to be good. A malicious package is bad on purpose. It may have no CVE at all, and a vulnerability database built around CVE identifiers will say nothing about it.
The event-stream case shows the pattern. In November 2018 a developer reported malicious code in flatmap-stream 0.1.1, a dependency of event-stream 3.3.6, hidden in a minified file with an encrypted payload. A normal vulnerability check had nothing to match. Detection came from a person reading code.
What does a good control set contain?
A shared source of reports. The OpenSSF Malicious Packages repository collects reports of malicious packages in the OSV format, so OSV-aware tools can consume them. Its inclusion rules count dependency and manifest confusion as malicious, and it also admits typosquats. Look for tools that read this kind of feed and say which feeds they use.
A decision at install time. Catching a package after it is in your tree means it may already have run an install script. Ask whether the control can allow, warn or block before install, and whether it covers transitive dependencies.
Re-checking old decisions. A package that was clean last month can be reported tomorrow. The control should rescan your inventory when reports change, not only when you push code.
An inventory. You cannot answer "did we ever install this?" without a record of every package and version, per build. A software bill of materials supplies that.
Behavioral signals. Static inspection of install scripts, network calls and obfuscation can flag a package no feed has seen yet. Treat these as warnings with an explanation, because false positives are possible.
What should a buyer ask?
- Which sources feed detection, and how fast do new reports arrive?
- Does it work before install, in CI, or only after?
- How does it treat transitive dependencies?
- What happens on a false positive: who can release a package, and is it logged?
- Can it list every build that ever contained a given package?
You can check what is in a project today with the free in-browser scan at gold.safeguard.sh/scan, which covers up to 100 dependencies. Use it as a first inventory, not as the whole control.
What are the honest limits?
No detector is complete. Attackers publish clean versions first to build trust, delay payloads, or compromise a real maintainer's account. The OpenSSF repository itself notes that false positives exist and are withdrawn through a process. Layers reduce the chance and the time to notice, but they do not remove the risk.
Pin versions and review updates to packages that run scripts at install. Use a lockfile, and reduce the number of dependencies you pull in.
What to do
- Generate an inventory of every dependency and version in each build.
- Add an install-time check that can warn or block.
- Subscribe your tooling to a malicious package feed in the OSV format.
- Rescan the inventory whenever the feed updates.
- Disable install scripts by default where your package manager allows it, and allow them by exception.
- Write a response runbook: find builds, rotate secrets that were in reach, rebuild.
Quick check
Does a clean CVE scan mean no malicious packages?
No. Malicious packages often have no CVE, so a CVE-based scan can pass while one is installed.
What should I do if I find one?
Remove it, list every build that contained it, and rotate any secrets the build or install environment could reach.
Sources
Last reviewed: 18 October 2026.
