Supply chain attacks are not a novel threat. But there's a pattern in the data that rarely gets called out directly: the most-downloaded npm packages are often maintained by a single person.
High downloads + one maintainer = one stolen credential away from a breach affecting millions of builds.
Why I built npm commitment scoring
I've been building Proof of Commitment — an MCP server that exposes behavioral trust signals to AI agents. The thesis: behavioral signals are harder to fake than declarative ones (READMEs, star counts, review ratings). Last week I shipped a GitHub repo commitment scorer. This week: npm packages.
The scoring model looks at five dimensions:
- Longevity (25 pts) — how long the package has existed
- Download momentum (25 pts) — recent volume + trend (growing/stable/declining)
- Release consistency (20 pts) — version count + recency of last publish
- Maintainer depth (15 pts) — number of current maintainers
- GitHub backing (15 pts) — if linked repo, pulls GitHub commit score
No star counts. No README quality. Just behavior over time.
The data
Here's the current state of 9 packages that make up the core of most JS/TS applications today:
| Package | Score | Age | Weekly downloads | Maintainers | Versions |
|---|---|---|---|---|---|
| express | 97/100 | 15.3y | 87M | 5 | 317 |
| openai | 93/100 | 5.7y | 111M | 17 | 354 |
| @anthropic-ai/sdk | 86/100 | 3.2y | 86M | 14 | 148 |
| langchain | 84/100 | 3.1y | 15M | 8 | 419 |
| @langchain/core | 84/100 | 2.4y | 24M | 13 | 314 |
| @modelcontextprotocol/sdk | 75/100 | 1.4y | 208M | 6 | 78 |
| node-fetch | 77/100 | 11.2y | 889M | 5 | 96 |
| zod | 79/100 | 6.1y | 974M | 1 | 860 |
| axios | 74/100 | 11.6y | 672M | 1 | 132 |
Scores as of April 5, 2026. Downloads are weekly totals from npm registry.
The zod and axios problem
zod: 974 million weekly downloads. 1 maintainer.
axios: 672 million weekly downloads. 1 maintainer.
Think about what that means. Every CI pipeline that runs npm install and has zod or axios in its dependency tree is one compromised PyPI/npm token away from a supply chain attack affecting nearly a billion weekly download events.
This is not speculation. The TeamPCP campaign (March 2026) followed exactly this pattern: steal a CI token → publish a malicious version → wait for npm install to propagate. The LiteLLM supply chain attack worked because one token controlled a package with millions of downstream dependents.
The attack surface scales with download count. The defensive surface scales with maintainer count. zod and axios are both near their maximum attack-to-defense ratio.
Note: zod has a very active GitHub repo — 860 versions published over 6 years, recent commits weekly. Colin Mcdonnell is clearly committed. This isn't about individual quality — it's about infrastructure risk. One person is one phishing email, one stolen credential, one burnout.
@modelcontextprotocol/sdk: young and massive
The MCP SDK sits at 75/100 — pulled down primarily by its youth (1.4 years, 8 pts for longevity vs 25 max). But 208M weekly downloads in 17 months is extraordinary adoption velocity. 6 maintainers is healthy.
The concern here is different: rapid adoption of a young package creates high-value targets for typosquatting and dependency confusion attacks. modelcontextprotocol-sdk, @model-context-protocol/sdk, mcp-sdk — any of these could be a trap waiting for a copy-paste error.
How to use this in your workflow
Add the MCP server to your AI config (zero install):
{
"mcpServers": {
"proof-of-commitment": {
"type": "streamable-http",
"url": "https://poc-backend.amdal-dev.workers.dev/mcp"
}
}
}
Then ask your AI:
"Check the commitment score for zod""Score these packages before I add them as dependencies: @ai-sdk/openai, ai, @vercel/ai""Which of these packages has the highest supply chain risk: axios, node-fetch, got?"
Your AI can now run behavioral due diligence on any npm package before it touches your package.json.
What the score doesn't catch
A high score doesn't mean a package is safe. express at 97/100 has had CVEs. What the score measures is behavioral commitment — evidence that real people have invested real time over real time.
What it can't measure:
- Whether maintainers reuse passwords
- Whether CI tokens are properly scoped
- Whether the publish pipeline has MFA enforced
For that, you need provenance attestations (npm provenance, Sigstore) — which is a separate layer. The commitment score tells you how much skin is in the game. Security practices tell you whether that skin is protected.
The supply chain security market context
The TeamPCP campaign in March 2026 targeted packages via stolen CI tokens and pre-staged malicious versions. The attack pattern: publish a clean version to establish history → wait → publish malicious version. That behavior is undetectable by any single-point download count check.
But behavioral trend analysis can catch it: if a package suddenly shows an anomalous publish pattern after months of consistency, that's a signal. Download trend reversals following a publish event are another signal.
This is the version of commitment scoring I'm building toward: not just static profile, but temporal anomaly detection. A package that's had consistent monthly releases for 4 years and then publishes 3 versions in one day is not acting normally.
Try it live
GitHub: https://github.com/piiiico/proof-of-commitment
Landing: https://getcommit.dev
Curious what packages you'd add to the comparison. And if you're maintaining a high-download single-maintainer package: respect, and please enable MFA on your npm account.
Top comments (0)