To check whether a package appears in a malware advisory, search the GitHub Advisory Database with the type:malware filter, query OSV for the package name, and compare your spelling against popular names. On a match, do not install it, and if it is already installed, remove it and rotate anything it could reach.
What these sources contain
The GitHub Advisory Database holds advisories for vulnerabilities and malware in open source packages. Its malware advisories come from the npm security team and the OpenSSF Malicious Packages repository. They have no fix version, so the only safe step is to stop using the package. Dependabot can generate malware alerts when enabled, and you can search them with type:malware.
OSV aggregates vulnerability databases that use the OpenSSF vulnerability format, with an API that includes endpoints for querying a package and for fetching a vulnerability by ID. deps.dev indexes advisories from OSV and displays them next to the dependency graph.
Steps before adopting
- Write down the exact package name and ecosystem.
- Search the GitHub Advisory Database for the name with the malware filter.
- Query OSV for the same name.
- Search for near spellings: swapped letters, added hyphens, different scope or namespace. Our post on how typosquatting campaigns pick targets explains the patterns.
- Open the registry page and check owners, repository link and first release date.
- Record the check in the adoption record.
What a clean result means
Not much on its own. Advisories appear after someone finds and reports a problem, so a brand new malicious package will not be listed yet. A clean search lowers one risk and leaves the others. Pair it with the registry checks in what to check on a registry page.
What to do on a match
| Situation | Action |
|---|---|
| Not yet installed | Do not install. Fix the name in your manifest |
| In a lockfile only | Remove, regenerate the lockfile, review the pull request that added it |
| Installed on a developer machine | Remove and treat that machine's secrets as exposed |
| Ran in CI | Rotate every secret the job could read, review artifacts built after |
Whether to treat secrets as exposed depends on what the package did, which the advisory may describe. When in doubt, rotate.
Automate it
Manual lookups do not scale beyond new adoptions. Keep an inventory of the packages you use and have a monitor that alerts when any one gains an advisory. Also gate new packages at pull request time so the lookup happens before merge.
Build the check into your workflow
A developer who adds a package today will not remember to search advisory databases. Put the lookup where the decision happens: in the pull request template, in a pre-merge check, or in the tool your team uses to install packages. Whatever you choose, make the result visible to the reviewer, so a missing check is as obvious as a failing test. Keep a short list of packages already blocked in your organization, and update it after each incident so the lesson is shared.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Is a package safe if no advisory exists?
No. Advisories lag behind new attacks. Verify owners, source and install behavior yourself.
Why is there no fixed version for malware?
The package itself is hostile, so there is nothing to patch. The safe response is removal.
Sources
Last reviewed: 19 October 2026.
