If a malicious package report names a library you use, do not assume it is wrong and do not assume it is right. Check the report's evidence, look at the versions you actually installed, and if it looks mistaken, report the false positive to the database with the ecosystem, package, affected versions and links.
Why mistakes happen
Malicious package databases rely on detection that has to be fast. The OpenSSF malicious packages repository says plainly that it does its best to keep false positives out, but they may be present from time to time. Obfuscation is one cause: the repository notes that obfuscation and debugger evasion are used both by developers who protect their source code and by attackers, so an obfuscated but harmless package can resemble a malicious one.
The same repository also states a narrow definition of malicious: a package whose use would need incident response, or that leaks an identifier enabling a follow-up attack. A report that does not meet that bar may still be present as a borderline entry, such as an empty typosquat.
First, treat it as possibly real
Until you know, assume the report may be correct, because the cost of being wrong the other way is a compromised build machine. Do these steps in order.
- Find where it was installed. Search lock files, build logs and image inventories for the named package and version.
- Check the version. Reports can be limited to certain versions. A clean older version may not be affected.
- Read the report evidence. Look for the behavior described: install scripts, network calls, credential access.
- Compare with the source. Check the project's repository and recent releases for unexpected changes, new maintainers or unusual install hooks.
- Pause new installs of that version. Pin to a known good version or hold the update until the answer is clear.
If the evidence holds up, follow your incident steps. See what to do after installing a malicious package.
If it looks like a false positive
The OpenSSF repository asks reporters to open an issue and include:
- the affected ecosystem and package;
- which versions are false positives, if only some are;
- any relevant links.
According to its README, the maintainers then either move the whole report into a withdrawn directory and add a withdrawn time, when the whole report is a false positive, or record the false positive versions in a database specific array, when some versions are malicious and some are not.
This tells you how to read a corrected record. A report may be partly withdrawn: some versions bad, some fine. If your tooling only checks the package name, it will keep flagging the good versions.
What not to do
| Mistake | Better move |
|---|---|
| Add a permanent ignore for the package name | Ignore only specific versions, with a review date |
| Disable the check for the whole project | Keep the check and handle this one item |
| Assume the maintainer is wrong | Inspect the package contents yourself |
| Post angry comments in the issue | Provide evidence: versions, links, reproduction |
After the answer
- Record the decision, the evidence and the date in your tracker.
- Remove temporary holds.
- If the record was withdrawn, update your tooling cache so it stops flagging.
- Check that your policy handles partial withdrawals by version.
Where Safeguard fits
Safeguard's SBOM and dependency scanning shows exactly which versions of a package are in each repository and image, which is the first fact you need, and its policies and gates let you hold one version without disabling the rest. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Can a malicious package report be partly wrong?
Yes. The OpenSSF README describes recording false positive versions separately when only some versions were wrongly flagged.
Should I ignore the package name permanently?
No. Ignore only the versions you have verified, with an owner and a review date.
Sources
- OpenSSF Malicious Packages README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
