Originally posted on getcommit.dev.

In October 2021, ua-parser-js was used by Facebook, Microsoft, Amazon, and Google. It had 7 million weekly downloads. It had no reported CVEs. It had clean code and an active maintainer. Every security tool in the npm ecosystem reported: nothing wrong here.

Then the maintainer's npm token was compromised. A malicious release deployed a cryptominer and credential stealer to every CI pipeline and production server that ran npm install that day. The blast radius: four hours, millions of installs, Fortune 500 pipelines.

The same structural profile — single maintainer, massive download volume, clean code — was present before the attack. It was visible, computable from public data, and nobody was measuring it.

This is the gap most npm supply chain audits leave open.

The three-layer model

A complete npm supply chain audit covers three distinct layers. Most teams run one. Sophisticated teams run two. Almost nobody runs all three — because the third layer only became a standard practice after real-world attacks validated the signal.

Each layer is essential. Each one fails at what the others cover. A supply chain audit that uses only one or two is a partial audit.

Layer 1: Known vulnerability scanning

What it does

npm audit submits your dependency tree to GitHub's Advisory Database and returns matches. Snyk extends this with a proprietary database, license compliance checking, and auto-fix pull requests. Both tools answer the same question: does this package version have a documented, reported vulnerability?

What it catches

Prototype pollution vulnerabilities. Known RCE bugs. Packages with published CVEs where the fix is a version bump. The entire category of "known bad" code.

What it misses

Anything that isn't documented yet. A CVE requires discovery, analysis, and reporting — that process takes days to weeks after an attack. For the ua-parser-js attack, npm audit returned zero for the four hours the malicious version was live, and returned zero for every day before that, including the years when the structural risk was building.

Checklist: Layer 1

• Run npm audit in CI on every push. Fail on high/critical.
• Set a .npmrc audit-level threshold appropriate for your risk tolerance.
• If using Snyk: enable the GitHub integration for automated PRs on new CVEs.
• Review npm audit --json output for transitive vulnerabilities, not just direct dependencies.
• Don't suppress audit failures with npm audit --production if devDependencies run in CI pipelines.

Layer 2: Real-time code analysis

What it does

Socket performs static analysis on the actual published package source — not the CVE database, not the repository. When a new version publishes to the npm registry, Socket analyzes the code for suspicious patterns: dynamic eval of user-controlled strings, network calls to unexpected endpoints, obfuscated payloads, environment variable harvesting.

For the class of attack where a maintainer's account is compromised and they push a malicious release, Socket catches the payload within minutes of publication — before most CI pipelines would run.

What it catches

Token-theft attacks. Malicious versions with obfuscated payloads. Packages that suddenly start making network calls they didn't make before. The ua-parser-js attack, run through Socket today, would be flagged by the suspicious network activity and eval patterns in the malicious release.

What it misses

The structural risk that exists before any malicious code is published. Socket analyzes code. The code was clean until the attack happened. Socket correctly reports "nothing suspicious in the code" when the code is genuinely clean — it can't report on structural conditions that live outside the code.

Socket also doesn't score blast radius. A solo-maintained package with 400 million weekly downloads gets the same analysis as a solo-maintained package with 400 downloads. The structural risk is orders of magnitude different, and that difference isn't in the code.

Checklist: Layer 2

• Enable Socket on your GitHub organization. The free tier covers open source.
• Configure Socket to block PRs that introduce packages with medium/high risk signals.
• Subscribe to Socket alerts for packages already in your lockfile.
• Review Socket's "install scripts" and "network access" flags — these are rarely false positives for utility packages.

Layer 3: Structural risk scoring

What it does

Structural risk scoring answers the question that neither Layer 1 nor Layer 2 can answer: is this package a high-value attack target, right now, based on observable structural conditions?

The structural conditions that define a high-value npm target are three things:

• Single publish credential. One npm account with publish access. One compromised token = one malicious release to every system that runs npm install.
• High download volume. The blast radius of a compromised publish. Hundreds of millions of weekly installs means CI pipelines and production deployments at Fortune 500 companies.
• Active maintenance. A package that publishes regularly is more valuable to an attacker than an abandoned one, because developers trust it and update to new versions.

All three of these signals are computable from public data. The npm registry exposes maintainer count per package. The npm download API returns weekly statistics. GitHub exposes commit history and contributor count. No scanning required. No proprietary database. The data was always there.

What it catches

The conditions that make a package a rational attack target before any attack has occurred. Event-stream (2018), ua-parser-js (2021), and colors.js (2022) all shared this structural profile: sole publisher, enormous download volume, active releases. The structural risk was computable and present for years before each incident. No existing tool was measuring it.

What it misses

Everything that requires code inspection. Structural scoring tells you about the conditions for an attack, not the attack itself. It generates leading indicators, not proof of compromise. A CRITICAL structural score means "this package is a high-value target" — not "this package is currently compromised." For that, you need Layer 2.

Checklist: Layer 3

• Run npx proof-of-commitment --file package-lock.json against your dependency tree. Note every CRITICAL flag (single maintainer, >10M weekly downloads).
• For every CRITICAL package, document the risk in your threat model. Do you have a contingency if this package is compromised? Can you pin to a specific version and monitor for unexpected updates?
• Check Trusted Publishing status for critical dependencies. Packages that publish via OIDC provenance (Trusted Publishing) are meaningfully harder to compromise than packages that publish via personal tokens.
• Re-run quarterly. Package maintainer counts change when projects gain or lose contributors. A package that was safe at multi-maintainer status may drift to single-maintainer over time.
• Evaluate transitive dependencies, not just direct ones. Your direct dependencies may look clean; the packages they depend on may carry CRITICAL flags. The blast radius includes the entire install tree.

The complete audit checklist

Run this in sequence. Each layer surfaces a different class of problem.

Before a major dependency update

# Layer 1: Known vulnerabilities
npm audit --json | jq '.vulnerabilities | length'

# Layer 2: Socket analysis (if CLI installed)
npx @socketsecurity/cli check package.json

# Layer 3: Structural risk
npx proof-of-commitment --file package-lock.json

In CI (on every PR)

# Layer 1
npm audit --audit-level=high

# Layer 3 (structural risk, fail on CRITICAL)
npx proof-of-commitment --file package-lock.json --fail-on-critical

Quarterly review

• Re-run Layer 3 on the full dependency tree. Note any packages that gained CRITICAL status since last quarter.
• Review Socket alert history for your organization. Note patterns.
• Check Trusted Publishing adoption for your five most critical dependencies.
• Update your threat model with any new structural risks.

Why most audits stop at Layer 1 or 2

The argument against Layer 3 is: "It's a leading indicator, not an exploit. A CRITICAL flag doesn't mean anything was attacked."

That's true. It's also the argument for credit scoring before fraud detection exists. Leading indicators measure structural conditions that predict future events. They're not proof of the event — they're the reason you insure against it before it happens.

The practical objection is noise: if your audit returns CRITICAL flags for minimatch, @types/node, and lodash, what do you do with that? You can't replace these packages. You can't wait for them to gain more maintainers.

The answer isn't to fix the packages. It's to know the risk exists, document it in your threat model, and make informed decisions about dependency pinning, update monitoring, and response plans. The same way you know that your RDS instance is a single point of failure and set up a read replica anyway.

The ua-parser-js compromise lasted four hours and affected millions of systems because the teams running those systems didn't have a response plan. They didn't have one because nobody told them the risk existed. Layer 3 is the tool that tells you the risk exists.

Try the structural layer

proof-of-commitment is open source and zero-install:

# Scan your project
npx proof-of-commitment --file package-lock.json

# Scan specific packages
npx proof-of-commitment axios lodash chalk zod

# pnpm or yarn
npx proof-of-commitment --file pnpm-lock.yaml
npx proof-of-commitment --file yarn.lock

Or use the web interface at getcommit.dev/audit — paste a GitHub repo URL and get structural risk scores for every dependency in seconds.

Layer 1 tells you what broke. Layer 2 tells you what's breaking now. Layer 3 tells you what will break. You need all three.