In the OSV dumps, 177,494 of 222,536 npm malicious package records (80%) name at least one report source, and 45,042 (20%) name none. One automated scanner accounts for 153,528 records, far ahead of the rest. A package missing from these reports has not been proven safe: it may simply not have been seen.
Method
We downloaded the npm OSV dump on 19 October 2026 and read the 222,536 records with IDs starting MAL, which come from the OpenSSF malicious-packages project. Where a record merges several reports, its details text holds one "Source" section per reporter. We counted those sections by name. A record with several sections counts once for each source, so the per-source counts overlap.
The counts
| Source label in the record | Records |
|---|---|
| amazon-inspector | 153,528 |
| ghsa-malware | 28,403 |
| ossf-package-analysis | 5,291 |
| google-open-source-security | 1,921 |
| one commercial security vendor | 142 |
Records with more than one source: 10,290 (4.6%). Records with no source section: 45,042 (20%). The no-source group includes most of the 34,306 records published on a single day in August 2025, which we describe in One npm campaign is 63% of malicious npm records in OSV.
What this tells you
- Coverage depends on a few reporters. One scanner label appears on 69% of records. If its coverage changes, so do the totals.
- Agreement is rare. Only 4.6% of records are backed by more than one source. For most packages, one party made the call.
- Reports are a lagging signal. A report appears after a package is found. Packages installed in the gap between publishing and removal are not in the data.
The source label names where the report came from, not how accurate it is. We did not test accuracy.
What to do with it
For a team choosing a defence, a few points follow from the data:
- Do not use a malware feed as your only control. Combine it with install-time rules, such as a delay before you adopt a brand new version and a lockfile that pins exact versions.
- Prefer reports with a stated source and an analysis note over bare entries.
- For packages you rely on, watch the maintainer and release history. A new maintainer or an unusual release is a signal that no feed will have yet.
- Keep an internal record of what you blocked and why, so you can tell whether the feed caught it first.
A scanner that reads your lockfile against these records answers one question: has someone already reported a package you use? It cannot answer whether a package nobody has looked at is clean.
Safeguard's SBOM and dependency scanning lists the components you run, and reachability analysis helps separate vulnerable code your application calls from code it does not. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and see which of your components could be matched against a report like these.
Quick check
Does a package missing from these reports mean it is safe?
No. It means no report has been recorded. New or unexamined packages are not covered.
Why do the source counts add up to more than the records?
A record can carry several source sections, and each is counted once for its source.
Sources
- OSV data sources and dumps, per-ecosystem OSV dumps downloaded on 19 October 2026.
- OpenSSF malicious-packages repository, the source of the MAL records in the OSV dumps.
Last reviewed: 19 October 2026.
