I scored the top packages in npm, PyPI, Cargo, and Go. One vulnerability pattern dominates three of them.
5.2 billion weekly downloads across three registries share a single structural weakness. The fourth ecosystem doesn’t have it.
Over the past two weeks I’ve scanned the most-downloaded packages in four major ecosystems using Proof of Commitment — the same behavioral scoring tool, the same methodology, applied to npm, PyPI, Cargo, and Go.
The individual findings are striking. The cross-ecosystem pattern is damning.
The scoreboard
I audited the 20 most-downloaded packages in each registry-based ecosystem (npm, PyPI, Cargo) and 10 top Go modules. A package scores CRITICAL when it has a sole publish-credential holder and high download volume — the structural preconditions for a credential-compromise supply chain attack.
| Ecosystem | Scanned | CRITICAL | CRITICAL rate | CRITICAL downloads/wk |
|---|---|---|---|---|
| npm | 20 | 10 | 50% | ~2.4B |
| PyPI | 20 | 10 | 50% | ~2.6B |
| Cargo | 20 | 12 | 60% | ~176M |
| Go | 10 | 0 | 0% | — |
Combined across npm, PyPI, and Cargo: roughly 5.2 billion weekly downloads flow through packages where a single compromised credential could push malicious code.
The worst in each ecosystem
Each registry has its own version of the same problem. The scale varies. The structure is identical.
npm: 2.4 billion downloads/week behind sole publishers
| Package | Downloads/wk | Publishers | Score |
|---|---|---|---|
minimatch | 577M | 1 | 78 |
chalk | 416M | 1 | 75 |
glob | 340M | 1 | 69 |
esbuild | 220M | 1 | 80 |
zod | 164M | 1 | 86 |
Audit these packages yourself →
PyPI: 2.6 billion downloads/week — many hidden in transitive deps
| Package | Downloads/wk | Publishers | Score |
|---|---|---|---|
boto3 | 728M | 1 | 89 |
certifi | 359M | 1 | 80 |
idna | 349M | 1 | 84 |
charset-normalizer | 323M | 1 | 69 |
cryptography | 275M | 1 | 74 |
Audit these packages yourself →
Cargo: highest CRITICAL rate at 60% — one person owns seven of them
| Crate | Downloads/wk | Owners | Score |
|---|---|---|---|
syn | 22.8M | 1 | 82 |
rand | 19.3M | 1 | 80 |
thiserror | 17.3M | 1 | 75 |
serde | 13.4M | 1 | 78 |
memchr | 14.7M | 1 | 74 |
Seven of the 12 CRITICAL crates are owned by one person: dtolnay. Combined: 108M weekly downloads behind a single crates.io account.
Go: zero CRITICALs — structurally different
Every Go module I scanned scored 82 or higher. None triggered a publisher-concentration flag. The reason is architectural: Go has no go publish command. There’s no registry credential to phish. Publishing is pushing a Git tag, verified by sum.golang.org.
Go’s risks are real but categorically different: abandoned modules (gorilla/mux, archived), stale releases (golang-jwt/jwt, 1000+ days since last tag), and typosquatting in an infinite namespace. Publisher-concentration isn’t one of them.
The structural argument
Three ecosystems with centralized publish credentials. Three ecosystems with CRITICAL packages. One ecosystem without centralized credentials. Zero CRITICALs.
That’s not a coincidence. It’s a design consequence.
In npm, you get an auth token. Anyone with that token can npm publish. Same with PyPI and Cargo. The token is the last gate between an attacker and every downstream project. When only one person holds that token for a package with 500M weekly downloads, the blast radius of a single phished credential is enormous.
Go skipped this architecture entirely. go get pulls from Git. The “publish credential” is your GitHub account — protected by 2FA, SSH keys, org-level access controls. It’s the same security infrastructure the developer already maintains for everything else. The attack cost is higher by design.
This isn’t about Rust being less secure than Go, or JavaScript developers being careless. The people maintaining these packages are among the best in their fields. The problem is the credential model they’re forced to use.
What the conventional tools miss
npm audit reports zero issues for minimatch. pip audit is clean on certifi. cargo audit has no advisory for serde. govulncheck finds nothing on gorilla/mux.
All correct. No CVEs. No known vulnerabilities.
But “one person controls publish access to 577 million weekly installs” is not a vulnerability — it’s a structural condition for future vulnerability. Existing tools scan for what has already gone wrong. Behavioral scoring measures the conditions that make it likely.
This is the gap that Proof of Commitment fills. Five dimensions — longevity, download momentum, release consistency, publisher depth, GitHub backing — scored from public data. No access tokens. No installation.
Check your own stack
# npm
npx proof-of-commitment axios chalk minimatch
npx proof-of-commitment --file package-lock.json
# Python
npx proof-of-commitment --pypi requests certifi boto3
npx proof-of-commitment --file requirements.txt
# Rust
npx proof-of-commitment --cargo serde tokio rand
npx proof-of-commitment --file Cargo.toml
# Go
npx proof-of-commitment --golang github.com/gin-gonic/gin
npx proof-of-commitment --file go.modOr use the web UI — no install required:
The language you write in doesn’t determine your supply chain risk. The registry architecture does. Three registries built on single-credential publish tokens have the same structural weakness. The one that didn’t is the one without CRITICAL packages.
5.2 billion weekly downloads are waiting for the same kind of attack that hit ua-parser-js in 2021. The conditions are visible now. The question is whether registries will fix the credential model before the next one lands.
Proof of Commitment is open-source. Now supports npm, PyPI, Cargo, and Go. Web audit at getcommit.dev/audit. Data accurate as of May 9, 2026.