Cut false positives in malicious package detection by never acting on a single signal. Combine metadata checks with behavior in a sandbox, compare against known reports, review exceptions in writing and keep a short, expiring allow list. A tool should show why it flagged a package, so a human can overrule it in minutes.
Why do detectors flag harmless packages?
Many legitimate packages do things that look suspicious in isolation: run install scripts, read environment variables, make network calls to download binaries, or contain minified or obfuscated code. A typosquat detector will also flag a real package whose name is close to a popular one. Each signal is weak alone, and the number of packages is large, so even a small error rate produces a steady stream of alerts.
What does the shared tooling teach us?
The OpenSSF Malicious Packages repository collects reports on malicious packages in registries, in the OSV format. It defines a malicious package as one that, when installed or used, would require incident response, or that exfiltrates an identifier usable for a follow on attack, and that violates registry terms or would reasonably require removal. That definition is a useful test for your own triage: if installing it would not need an incident response, it probably is not worth a block.
The repository also shows how to handle mistakes. A false positive is reported with the ecosystem, package, affected versions and links. If the whole report is wrong, maintainers move it to a withdrawn directory with a timestamp. If only some versions are wrong, those versions are recorded separately. Reports already added are not deleted. The page says support for handling false positives is still to be confirmed, so do not assume upstream feeds correct themselves quickly. Keep your own override record.
OpenSSF's Package Analysis project runs each package in a gVisor sandbox and records files accessed, network addresses contacted, commands run and system call traces, and it tracks behavior changes over time. Behavior in a sandbox is stronger evidence than a name or a metadata rule.
What should a buyer look for?
- Explanations. Each alert should say which signals fired and show the evidence, such as the install script line or the contacted address.
- Multiple signal types. Metadata, code patterns, behavior and known reports together beat any one.
- Version awareness. A compromise can affect one version. A tool that blocks the whole package, or ignores version, will be wrong in both directions.
- Override with expiry. Exceptions need an owner, a reason and a review date.
- Feedback loop. You should be able to report a miss or a false alarm and see what changed.
- Honest limits. Ask for the false positive rate on a sample of your own dependencies, not a headline number.
What is a triage routine that works?
Work through a short list for each alert. Is the package in your lockfile, or only proposed? Is the flagged version the one you use? What does the install script do, in plain terms? Does the maintainer history look normal? Does a public report exist for this version? If two answers look wrong, block and escalate. If none do, allow with a review date.
Where does Safeguard fit?
Safeguard's Gold registry and the free in browser scan at gold.safeguard.sh/scan (100 dependencies) let you check a real dependency list and see how findings are presented before you commit to a process. Review the explanation for each result the same way you would for any tool.
See it on its own page: Dependency inventory demo.
What to do
- Pick 30 recent alerts and label each as true, false or unclear, with the reason.
- Find which signal caused most false alarms and weight it down.
- Require evidence in every alert; reject alerts that only show a score.
- Add an allow list with owner, reason and expiry.
- Block at install time only for high confidence cases, and alert for the rest.
- Report false positives upstream with version details.
- Review the allow list monthly.
Quick check
Is a package with an install script malicious?
No. Many legitimate packages use install scripts. Look at what the script does.
Should I block on a single signal?
Only if that signal is high confidence, such as a match to a confirmed malicious report for that version.
Sources
Last reviewed: 18 October 2026.
