Free malicious package detection exists: open databases of known malicious packages, research projects that run packages in a sandbox, and registry integrity checks. They are useful, but mostly cover known cases. A new malicious package can exist before any report does, so free tools reduce risk without removing it.
What counts as detection?
Three different jobs get called the same thing. Knowing which one you are getting matters more than the price.
- Lookup: is this exact package and version in a list of known bad ones?
- Behaviour analysis: what does this package do when it runs?
- Integrity checks: is this the file the publisher actually released?
What does the OpenSSF malicious packages database offer?
The OpenSSF malicious-packages repository is a community database of reports on malicious packages in open source registries. Reports use the OSV format, and any ecosystem supported by the OSV schema is in scope. Contributors submit reports by pull request, and producers with low false positive detections can feed it automatically.
The limits are written into the project. Typosquatting and spam packages that are not otherwise malicious are a borderline category. Reports that are added are not removed, though false ones are withdrawn or annotated. And it is a list: it only knows about packages someone reported. The OSV documentation lists the OpenSSF Malicious Packages database as one of its data sources, so tools that read OSV can pick it up.
What does package analysis add?
The OpenSSF Package Analysis project studies package behaviour: which files a package accesses, which addresses it connects to and which commands it runs. It does this by running the package in a gVisor sandbox and capturing system calls and network traffic, and it tracks behaviour over time to catch a previously safe package that turns suspicious.
This catches things a list cannot, because it needs no prior report. But the project page is a developer repository, not a turnkey scanner. It describes a scheduler, analysis workers and results loaded into BigQuery. The page's examples use PyPI and does not give a full ecosystem list. Treat it as a research feed and a building block, not as a gate you switch on.
Does npm audit catch malware?
Not as far as its documentation says. The npm audit page describes sending your dependency description to the registry to ask for known vulnerabilities, and calculating remediation. A related subcommand, audit signatures, verifies registry signatures and provenance attestations of downloaded packages. That is an integrity check. It tells you a package matches what was published, not that what was published is harmless. Vulnerability data and malware data are different things.
What about free in-browser scans?
Safeguard offers a free scan at gold.safeguard.sh/scan. It runs in the browser with no login, covers up to 100 dependencies, accepts a manifest or a CycloneDX or SPDX SBOM, and parsing happens in your browser. The page describes checking for known vulnerabilities. It does not state that this scan checks for malicious packages, so use it for vulnerability triage, not as malware detection.
What should a buyer ask of any tool?
- Does it match known malicious reports, analyse behaviour, or both?
- Which ecosystems does it cover, and does that match your stack?
- Does it act before install, in CI, or only after the fact?
- What is its false positive process, and who handles disputes?
- Can you see why a package was flagged?
- What happens to a package that is neither known good nor known bad?
Paid, legacy SCA style products and free projects differ mostly in coverage, support, workflow integration and speed of response, not in magic. Ask for those specifics.
What to do
- Decide which of the three jobs you need: lookup, behaviour or integrity.
- Feed the OpenSSF malicious packages data, through OSV, into whatever already scans your dependencies.
- Turn on registry integrity checks, such as npm audit signatures, in CI.
- Pin versions and use lockfiles so a surprise release does not land silently.
- Delay adopting brand new versions by a few days where your policy allows.
- Keep install scripts off by default where your package manager supports it.
- Write down how you will respond when a flagged package is already installed.
Quick check
Can a free tool stop a brand new malicious package?
Lookup tools cannot, because nobody has reported it yet. Behaviour analysis may catch it, but the OpenSSF project is a research and building block project rather than a ready gate.
Does npm audit detect malicious packages?
Its documentation describes known vulnerability checks and signature and provenance verification. It does not describe malware detection.
Sources
- OpenSSF malicious-packages repository, fetched 18 October 2026.
- OpenSSF Package Analysis, fetched 18 October 2026.
- OSV data sources, fetched 18 October 2026.
- npm audit documentation, fetched 18 October 2026.
- Gold free scan, fetched 18 October 2026.
Last reviewed: 18 October 2026.
