Half of npm’s Top Packages Don’t Use Trusted Publishing
We now detect OIDC provenance in every npm package score. Here’s what the data shows.
npm introduced Trusted Publishing in 2023. Instead of publishing with a personal access token stored in your local environment, packages are published from CI via OIDC — the registry verifies the identity of the build pipeline, not a human. If a maintainer’s laptop is compromised, the attacker can’t publish a malicious version because there’s no token to steal.
This is the single most effective defense against credential-theft attacks — the attack vector that hit axios in March 2026 and LiteLLM the same month.
As of today, Commit detects Trusted Publishing for every npm package we score. Here’s what we found.
The data
We checked the 27 most-downloaded npm packages. Thirteen use Trusted Publishing. Fourteen don’t.
| Package | Weekly dl | Publishers | Trusted Publishing | Score |
|---|---|---|---|---|
| semver | 660M | 4 | OIDC ✓ | 93 |
| minimatch | 613M | 1 | No | 78 |
| debug | 563M | 2 | No | 78 |
| commander | 416M | 2 | No | 84 |
| glob | 360M | 1 | No | 80 |
| uuid | 198M | 2 | OIDC ✓ | 87 |
| fs-extra | 190M | 3 | No | 89 |
| yargs | 161M | 2 | No | 81 |
| cross-spawn | 148M | 1 | No | 72 |
| dotenv | 136M | 3 | No | 89 |
| webpack | ~99M | 4+ | OIDC ✓ | 99 |
| express | ~95M | 5 | No | 93 |
| vite | ~94M | 3+ | OIDC ✓ | 94 |
| react | ~91M | 3+ | No | 91 |
| axios | ~88M | 1 | OIDC ✓ | 88 |
| esbuild | ~85M | 1 | OIDC ✓ | 85 |
| chalk | ~75M | 1 | No | 75 |
| lodash | ~84M | 1 | No | 84 |
| zod | ~163M | 1 | OIDC ✓ | 91 |
| next | ~95M | 3+ | OIDC ✓ | 95 |
| typescript | ~97M | 3+ | No | 97 |
| eslint | ~92M | 3+ | No | 92 |
| prettier | ~97M | 3+ | No | 97 |
| jest | ~97M | 3+ | No | 97 |
| rollup | ~90M | 2+ | OIDC ✓ | 101 |
Highlighted rows have a single npm publisher and no Trusted Publishing — the highest-risk combination. axios adopted Trusted Publishing after the March 2026 attack.
What stands out
The build tool ecosystem adopted faster. Webpack, vite, esbuild, rollup all use OIDC. They publish from CI as a natural consequence of how they’re developed — automated release pipelines.
Utility packages are exposed. minimatch (613M/wk), glob (360M/wk),
cross-spawn (148M/wk) — all have a single npm publisher and no Trusted Publishing.
These packages rarely show up in your package.json, but they’re in your
node_modules. A credential theft on any of them follows the
same pattern that compromised axios.
Big orgs aren’t consistent. React and TypeScript don’t use Trusted Publishing. Next.js does. Express doesn’t. The pattern isn’t about org size — it’s about whether the specific package’s release pipeline was modernized.
axios adopted it post-attack. After the March 30 credential compromise, axios enabled OIDC publishing. It now scores 88 with Trusted Publishing (+2 points from the new dimension). The attack was preventable.
How we detect it
When you query any npm package through Commit —
the web audit,
the CLI,
or the MCP server —
we check the latest version’s dist.attestations in the npm registry.
If OIDC-based attestations are present, the package uses Trusted Publishing.
The signal adds up to 2 points to the commitment score (out of 102 max) and appears in the score breakdown on every package profile page. It’s a small bonus, not a cure — a sole publisher with Trusted Publishing is still a concentration risk. But it eliminates the most common attack vector.
What you can do
If you maintain an npm package, enable Trusted Publishing.
It takes one flag in your CI workflow: --provenance.
If you depend on packages, check which ones use it:
npx proof-of-commitment --file package-lock.jsonThe CRITICAL packages in your lock file — single publisher, high downloads, no OIDC — are where a stolen credential does the most damage. Those are the ones to watch.