In the OpenSSF malicious packages repository, a package is malicious if installing or using it would need incident response because of lost confidentiality, availability or integrity, or if it leaks an identifier that enables a follow-up attack, and it breaks registry terms or deserves removal. Spam and obfuscation alone do not qualify.
The definition
The repository README defines a malicious package as one that is publicly available in a package registry and meets two tests.
First, either:
- when installed or used, it would require some sort of incident response due to loss of confidentiality, availability or integrity; or
- it exfiltrates an identifier that can be used directly to launch a later attack against the victim, such as a username for phishing or password guessing.
Second, either it violates the registry's terms, or it would reasonably be considered to need removal from the registry.
Why this matters to you: the definition ties "malicious" to what you would have to do afterwards. If you would need to rotate credentials or rebuild a machine, it counts.
What is in scope
The README lists as in scope any package from an ecosystem supported by the OSV schema, typosquatting type attacks, account takeover, malicious prebuilt binaries installed with a package, security researcher activity, and dependency and manifest confusion. It treats dependency confusion as equivalent to an account takeover where an attacker replaces a package's code, which means even trivial or empty packages of that type call for incident response.
What is treated differently
| Case | Treatment in the README |
|---|---|
| Spam or typosquat with no malicious behavior | Not malicious by itself, though allowed in the dataset as a borderline case |
| Obfuscation or debugger evasion | Not malicious unless it exhibits malicious behavior |
| Offensive security tools | Out of scope, unless they execute malicious payloads on install |
| Vulnerability reports | Out of scope |
| Compromised infrastructure | Out of scope |
This helps when a report says "suspicious package" and you must decide how loud to be. Empty typosquats are a nuisance. A package that runs a payload on install is an incident.
How reports are corrected
The README says reports use the OSV format. If a package was flagged wrongly, the maintainers either move the whole report into a withdrawn directory with a withdrawn time, or record the false positive versions in a database specific array when only some versions were wrong. If you track malicious package records, watch for withdrawals the same way you do for vulnerability advisories.
Turn it into a response rule
- If a package on your list matches a malicious report, check whether any build or machine installed the named versions.
- If yes, treat it as an incident: contain, rotate secrets that were reachable, and review logs.
- If the report is a typosquat without payload, block it in your registry policy and note it.
- If a report is later withdrawn, reverse the block and record the change.
For the day-one steps, see what to do after installing a malicious package.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and its policies and gates help you find where a named package version was installed and block it going forward. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a typosquatted package always malicious?
Not by the repository's definition. Typosquats are malicious only if they show malicious behavior, though they may still appear in the dataset.
Are vulnerability reports included?
No. Vulnerability reports are out of scope for the malicious packages repository.
Sources
- OpenSSF Malicious Packages README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
