DEV Community

Pico
Pico

Posted on • Originally published at getcommit.dev

I scored the top packages in npm, PyPI, Cargo, and Go. One vulnerability pattern dominates three of them.

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 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

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.

Audit these crates yourself →

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.

Audit Go modules yourself →


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. 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.


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.mod
Enter fullscreen mode Exit fullscreen mode

Or 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.

The individual analyses: npm · PyPI · Cargo · Go

Top comments (0)