Your pnpm monorepo has 4 CRITICAL packages. Here’s how to find them in 10 seconds.

Monorepos feel safer. Everything is in one place. Shared dependencies get deduped. The lockfile is one file.

The thing monorepos actually do is concentrate your attack surface and make it invisible. Each workspace has its own package.json, its own dependencies, its own exposure. And when you run pnpm audit, you get the same CVE scan you’d get on a single project. It doesn’t tell you what happens when you look at the aggregate.

---

The scan

I ran Proof of Commitment v1.5.0 against a pnpm workspace with 4 packages. The tool reads pnpm-workspace.yaml, walks each workspace, collects all direct dependencies, deduplicates, and scores the merged set against behavioral signals — publisher count, download volume, release cadence, GitHub backing.

npx proof-of-commitment --file pnpm-workspace.yaml

10 unique dependencies. 4 scored CRITICAL.

Combined: over 512 million weekly downloads behind single-publisher npm accounts. Four stolen credentials. That’s the blast radius.

---

Why monorepos make this worse

A single-project scan tells you about that project’s direct dependencies. Fine. But a monorepo has N projects, and the shared dependency often appears in more than one. The risk compounds:

• Hidden duplication: axios might be in packages/api and packages/cli. You scan each workspace separately, you see the same CRITICAL flag twice and treat it as one issue. Or you miss it entirely because each workspace has few enough deps that nobody bothers auditing.
• Aggregate view matters: The monorepo-level scan deduplicates and shows the full surface area. clsx scored 70 — the lowest of the four. It appeared in one workspace. Per-workspace, it looks minor. At the aggregate level, a 70-score single-publisher package with 95 million weekly downloads is the most dangerous thing in the repo.
• pnpm audit doesn’t do this: pnpm audit checks the NVD for known CVEs. There’s no CVE for “one person holds the publish token to 95 million weekly installs.” That’s a structural risk, not a vulnerability.

---

The clsx problem

clsx is a 228-byte utility for constructing className strings. It scores 70 — GOOD on the Commit scale. But it has one npm publisher and 95 million weekly downloads. Zero provenance. Last published 746 days ago. OpenSSF Scorecard: 3.0.

A high-quality, well-maintained, incredibly popular package — and a single-token compromise away from supply chain disaster. The per-workspace scan didn’t flag it because no workspace depends on enough packages to trigger concern. The aggregate view did.

That’s the point of the monorepo scan. It surfaces risks that per-package scans miss.

---

Try it

# Scan your pnpm monorepo
npx proof-of-commitment --file pnpm-workspace.yaml

# Or scan specific packages
npx proof-of-commitment clsx lodash zod axios

# JSON output for CI
npx proof-of-commitment --file pnpm-workspace.yaml --json

Web view (no install): getcommit.dev/audit

The --json flag exits with code 1 if any CRITICAL packages are found. Wire it into CI and it becomes a gate, not a report.

---

pnpm audit finds known vulnerabilities. Commit finds structural risk — the conditions that make a future vulnerability catastrophic. One person publishing to 95 million machines per week is not a CVE. It’s a blast radius.

---

Proof of Commitment is open-source. v1.5.0 adds pnpm workspace support. Web audit at getcommit.dev/audit.

Also: The same analysis on Rust crates · Python supply chain risk · Why npm audit returns zero for the most dangerous packages