The Axios Signal

Here’s what the proof-of-commitment API returns for axios right now:

{
  "name": "axios",
  "score": 86,
  "riskFlags": ["CRITICAL"],
  "maintainers": 1,
  "weeklyDownloads": 81672752
}

Score 86 out of 100. Nearly perfect on longevity, release consistency, and download momentum. And: CRITICAL.

These aren’t contradictory. They’re the most important thing the score reveals: quality and structural risk are orthogonal. A package can be excellent on every dimension that matters for code health, and simultaneously be the highest-impact single point of failure in the npm ecosystem.

Here’s what npm audit returns for axios today:

found 0 vulnerabilities

That’s the gap this tool is built to fill.

---

One line of code

Here’s the CRITICAL flag logic in proof-of-commitment:

if (maintainerCount === 1 && weeklyDownloads > 10_000_000)
  riskFlags.push("CRITICAL");

That’s it. One maintainer. More than 10 million weekly downloads. CRITICAL.

No machine learning. No behavioral analysis engine. One conditional that asks: is this package a single point of failure at scale?

If your instinct is that this is too simple to be useful — hold that thought. We’ll come back to it.

---

Why quality doesn’t equal safety

The ua-parser-js incident (October 2021) is the template. Faisal Salman was the sole maintainer. His npm credentials were compromised. A malicious version containing a cryptominer and a credential-stealing trojan went live. The package had ~7 million weekly downloads at the time — used by Facebook, Microsoft, Amazon, and Google. The malicious versions ran for four hours.

Here’s what npm audit showed before the attack: zero warnings. The package was healthy by every quality metric. Consistent releases. Growing adoption. High longevity. The vulnerability was orthogonal to quality — it was structural.

Proof-of-commitment would have flagged ua-parser-js at minimum as WARN, and CRITICAL at today’s volume (25M weekly downloads). Axios has the same structural profile. 82 million weekly downloads. One maintainer. The blast radius is 10x larger.

---

Why npm audit can’t see this

npm audit is a CVE database lookup. It answers one question: “has a known vulnerability been discovered, documented, and catalogued for this specific package version?”

That’s useful. But it has a fundamental limitation: it can only see threats that have already happened and been reported. By the time npm audit flags a supply chain compromise, the malicious code has already been running in production. The CVE is the documentation of the attack, not the detection.

The ua-parser-js timeline makes this concrete:

The structural flag was there the entire time. npm audit finally caught up after the attack occurred. Axios carries the same structural profile right now — except at 12x the download volume.

This isn’t a criticism of npm audit — it does what it’s designed to do. The problem is treating vulnerability scanning as supply chain security. Those are different things.

---

The simplicity is the point

A skeptical reader is thinking: “you flagged a structural condition with one if-statement. That’s not sophisticated analysis — that’s a filter.”

Correct. And that’s the argument.

The supply chain attack surface isn’t complicated. It doesn’t require deep learning or behavioral analysis to identify. The structural conditions that attackers select for are simple, public, and computable from the npm registry API in milliseconds:

1. How many people can push a release? (npm registry)
2. How many systems execute this code every week? (npm download stats)

If the answer to #1 is “one” and the answer to #2 is “tens of millions,” you have a rational attack target. The attacker’s calculation is trivial: compromise one credential, get code execution on millions of systems.

The sophistication isn’t in the detection. The sophistication is in the fact that the entire npm security ecosystem — npm audit, Dependabot, Snyk, Socket — is oriented around a different question (“does this package have known bugs?”) while this question (“is this package a single point of failure at scale?”) goes unasked.

---

The score breakdown

Proof-of-commitment does score packages across five dimensions — all inputs are public data from the npm registry and GitHub API. Here’s the actual API response for axios:

{
  "name": "axios",
  "score": 86,
  "riskFlags": ["CRITICAL"],
  "scoreBreakdown": {
    "longevity": 25,
    "downloadMomentum": 22,
    "releaseConsistency": 20,
    "maintainerDepth": 4,
    "githubBacking": 15
  }
}

Longevity (25/25). 11.6 years old. Full marks.

Download momentum (22/25). 82M/week. Stable, not accelerating.

Release consistency (20/20). Regular release cadence. Full marks.

Maintainer depth (4/15). One maintainer. This is the dimension that breaks the curve.

GitHub backing (15/15). Strong community engagement. Full marks.

The compound effect: a score of 86 would pass any reasonable “healthy package” threshold. The CRITICAL flag exists precisely because the overall score is misleading. A package can be well-maintained, actively developed, widely adopted, and still be structurally dangerous because one compromised credential opens the blast door for 82 million projects.

---

The ecosystem view

Axios isn’t an outlier. It’s the norm.

When we scored the top 50 most-downloaded npm packages in April 2026, 15 of them — 30% — triggered CRITICAL. Together, those 15 packages account for 2.5 billion weekly downloads.

Some names from that list:

For comparison, packages with similar download volumes that don’t flag:

The difference isn’t download count, project age, or release cadence. It’s the number of people between an attacker and the npm publish button.

minimatch, the second most-downloaded package on npm at 562 million weekly downloads, has one maintainer. If that credential is compromised, the supply chain attack makes axios look like a test run.

---

The false positive objection

“You flagged 15 out of 50 packages. Only two got attacked. That’s a 13-out-of-15 false positive rate.”

Fair. Let’s be precise about the claim.

Proof-of-commitment does not predict which package will be attacked next, or when. It identifies the structural conditions that attackers select for. The distinction matters, and it’s the same distinction that separates structural engineering from earthquake prediction.

A structural engineer doesn’t predict earthquakes. They assess which buildings will collapse when an earthquake happens — based on construction, materials, load paths, and soil conditions. A building that scores poorly doesn’t mean an earthquake is imminent. It means the building is the wrong place to be when one arrives.

The CRITICAL flag operates on the same logic. It doesn’t predict that an attacker will compromise minimatch’s sole maintainer next Tuesday. It identifies that minimatch has the structural profile — 562 million weekly downloads, one person with the keys — that makes it a rational target. When supply chain attackers evaluate their options, this is the profile they select.

The ua-parser-js attack confirmed the pattern in 2021. event-stream confirmed it in 2018. colors.js confirmed it in 2022. Every package that was exploited or sabotaged via sole-maintainer access shared the same structural profile. The CRITICAL packages in the top 100 haven’t been attacked yet. That’s not evidence the flag is wrong — it’s evidence the attack hasn’t happened yet.

The question isn’t whether the flag is predictive. It’s whether you’d rather know about the structural risk before the CVE or after.

---

What this means for axios

axios is actively maintained. In April 2026, the maintainer coordinated two security-hardening releases (v1.15.1 and v1.15.2) to address CVEs proactively. That’s good security practice. It also underscores exactly what the CRITICAL flag measures: one person is making every security decision for 82 million weekly installs. The security hardening happened because that person chose to do it. The risk exists because they’re the only person who can.

npm audit does its job — it scans for known vulnerabilities and finds them after they’re catalogued. The problem is treating that as supply chain security. Supply chain security is a structural question: is this package a single point of failure at enormous scale?

That question has an answer. It’s computable from public data. And it’s embarrassingly simple to check.

For axios, minimatch, chalk, glob, zod, esbuild, and nine other top-100 packages, the answer is CRITICAL. Right now.

npm audit will catch the next attack after it happens. The structural signal is visible before.

---

Audit your own dependencies: getcommit.dev/audit | GitHub Action

Full dataset: State of npm Supply Chain Trust — Q2 2026 (100 packages, 14 CRITICAL)

Open source: github.com/piiiico/proof-of-commitment