DEV Community: Pico

drizzle-kit Has 8.2M Weekly Downloads and Ships an Archived Dependency With 1 Publisher

Pico — Fri, 29 May 2026 08:41:41 +0000

drizzle-kit has 8.2 million weekly downloads, 4 npm publishers, provenance enabled, and a behavioral score of 83. Looked at on its own, it's fine.

npm install drizzle-kit also pulls in @esbuild-kit/esm-loader. That package's GitHub repo is archived. Its last npm publish was 17 September 2023 — 981 days ago. It has one npm publisher. It gets 7.5 million weekly downloads through Drizzle and a few other consumers.

The numbers, side by side

Both packages scored through Commit's behavioral audit:

Package	Score	Publishers	Downloads/wk	Days since publish	Risk
drizzle-kit	83	4	8.2M	69	—
@esbuild-kit/esm-loader	65	1	7.5M	981	HIGH + WARN

drizzle-kit's own metrics look healthy. The transitive dep does not. @esbuild-kit/esm-loader trips two risk flags: sole npm publisher with >1M weekly downloads, and no release in 12+ months. The repo is archived. The sole maintainer moved their work to tsx over two years ago.

The community already knows

This isn't a surprise to anyone reading Drizzle's issue tracker. At least five open pull requests propose dropping or replacing @esbuild-kit/esm-loader:

PR #3498 — opened 6 November 2024. Move @esbuild-kit/esm-loader to devDependencies.
PR #4250 — opened 10 March 2025. Remove @esbuild-kit/esm-loader.
PR #4430 — Replace with tsx.
PR #4819 — Replace @esbuild-kit/esm-loader with tsx.
PR #5689 — opened 27 April 2026. Drop deprecated @esbuild-kit/esm-loader dependency.

Plus a tracked security issue, #5481, opened 13 March 2026 with 15 thumbs-up reactions and 7 comments. All five PRs are open. The oldest has been open for 18 months.

This isn't a swipe at Drizzle. The team has shipped a serious ORM and is responsible for an enormous surface area. The point is structural: a healthy package can ship transitive risk for years while the community files PRs that nobody merges. The risk lives one npm install below the surface where most people stop looking.

Why this pattern keeps recurring

The interesting thing about @esbuild-kit/esm-loader isn't that one person published it. Plenty of small dependencies have one maintainer and do fine. The interesting thing is that the maintainer themselves told everyone to stop using it. The repo is archived. The replacement (tsx, by the same author) is right there.

That makes this a quieter version of the event-stream pattern: a package whose maintainer's engagement has expired, still being shipped to millions of machines every week. The credential surface narrows to one person who no longer has any active reason to defend it. If that credential is compromised tomorrow, every drizzle-kit install pulling a fresh tree ships whatever the attacker pushes.

Drizzle's own score doesn't tell you this. Neither does npm audit, because there's no CVE: nothing is broken yet. The behavioral signals — archived repo, single publisher, no release in 981 days — catch the risk before there's a vulnerability to scan for.

What this means for your stack

If drizzle-kit is in your devDependencies, you're shipping @esbuild-kit/esm-loader into your CI and local dev environments. It runs every time you generate or push migrations. The blast radius is whatever credentials and source those environments touch.

The fix on Drizzle's side is straightforward — tsx is a drop-in replacement, written by the same author, actively maintained, score 86. Five PRs are already written. Until one merges, the working answer for users is to pin drizzle-kit behind a vetted lockfile and watch for changes.

Find this in your own dependencies

The full transitive tree, scored:

npx proof-of-commitment --file package-lock.json

Or use the web audit for a single package.

None of this requires waiting for a CVE. Behavioral signals are available the moment the conditions are true. Right now, @esbuild-kit/esm-loader is on day 981.

Audit your dependencies → · Get free API key →

637 npm Packages Compromised in 39 Minutes. The Malware Installs a Claude Code SessionStart Hook.

Pico — Mon, 25 May 2026 14:44:49 +0000

On May 19, 2026, between 01:39 and 02:18 UTC, a single compromised npm account published 637 malicious package versions across 323 packages. The entire attack took 39 minutes.

The packages included jest-canvas-mock (2.8M weekly downloads), echarts-for-react (1.1M), size-sensor (1.2M), timeago.js (295K), and most of the @antv visualization suite. Total blast radius: roughly 16 million weekly downloads.

This wasn't a human typing npm publish 637 times. This was a worm.

How the self-propagation works

The atool npm account was compromised (how is still unknown). That account had publish access to 547 packages. The initial payload did what you'd expect — harvested credentials from 80+ environment variables and 100+ file paths across AWS, GCP, Azure, GitHub, Kubernetes, and database systems.

Then it did something different: it searched for npm tokens with the bypass_2fa scope. In GitHub Actions environments, the malware exchanged OIDC tokens for per-package npm publish credentials. It then republished additional packages with itself embedded. An npm worm.

Two waves hit the registry. First: ~317 versions at 01:39. Second: ~314 versions 26 minutes later at 02:05. Detection started around 02:18.

The persistence mechanisms

The exfiltrated credentials are serialized as JSON, gzip-compressed, encrypted with AES-256-GCM, and wrapped with RSA-OAEP. The exfiltration channel disguises itself as OpenTelemetry traces, posting to t.m-kosche.com:443/api/public/otel/v1/traces.

A backup channel creates public repos under the victim's GitHub account, commits encrypted credential dumps with Dune-themed naming patterns.

Here's where it gets personal for anyone reading this on a machine with Claude Code installed:

The malware installs a SessionStart hook in .claude/settings.json. It also drops VS Code task automation in .vscode/tasks.json and a background daemon at ~/.local/share/kitty/cat.py that polls GitHub every 60 seconds for RSA-signed commands.

And there's a dead man's switch. If the stolen GitHub token gets revoked, the malware runs rm -rf ~/.

What the packages looked like before the attack

I scored the compromised packages using Commit, a behavioral supply chain scorer. The non-AntV packages — the ones most projects wouldn't think to audit — tell the clearest story:

Package	Score	Publishers	Downloads/wk	Risk
canvas-nest.js	50	1	1K	WARN: no release 12+ months
timeago.js	65	2	295K	WARN: no release 12+ months
size-sensor	66	1	1.2M	HIGH: sole publisher + >1M/wk
echarts-for-react	71	1	1.1M	HIGH: sole publisher + >1M/wk
jest-canvas-mock	72	2	2.8M	WARN: no release 12+ months

Three of these five had a sole npm publisher. Two are stale — no release in over a year, still pulled by millions of projects weekly. That's exactly the profile that makes account takeover both easy and high-impact.

The @antv packages scored higher (84–89) because they have 17–18 maintainers. But that's exactly how the account worked: atool was one of those 18 maintainers. More publishers means more attack surface when any one of them can publish.

What to check

If your package-lock.json or yarn.lock includes any of these packages, check which versions you installed between 01:39 and 02:18 UTC on May 19.

Then check the rest of your dependency tree:

npx proof-of-commitment --file package-lock.json

The packages that scored 50–72 before this attack — sole publishers, stale releases, high downloads — are the same profile that got compromised in the LiteLLM attack, the axios attack, and now this one.

The pattern doesn't change. The entry point is always the same: one compromised account with publish access to a widely-installed package.

What's different about this one

Previous supply chain attacks hit one package at a time. This one propagated. It turned compromised npm tokens into more compromised packages. The 39-minute window between first publish and detection is getting shorter, but the blast radius is getting wider.

And the persistence mechanisms are evolving. Targeting .claude/settings.json and .vscode/tasks.json means the malware survives container restarts and embeds itself in developer tooling — the exact environment where you make decisions about which packages to trust.

Run a supply chain audit on your project — or set up monitoring to get alerted when scores change.

Stripe and Google Cloud Storage Are Both CRITICAL on npm

Pico — Sun, 24 May 2026 20:47:53 +0000

The stripe npm package processes payments for millions of businesses. It has 12 million downloads per week and one npm publisher: a service account called stripe-bindings.

If someone compromises that account's credentials, they publish a malicious version to every npm install in every CI pipeline that depends on stripe. This is not a theoretical risk. The axios attack in March 2026 followed the same pattern: one publisher, stolen credentials, 97 million machines exposed.

The audit

I ran five infrastructure packages through Commit's behavioral audit:

Package	Score	Publishers	Downloads/wk	Risk
`next`	95	4	37.7M	—
`@aws-sdk/client-s3`	92	2	29.1M	—
`stripe`	86	1	12.2M	CRITICAL
`@google-cloud/storage`	75	1	12.4M	CRITICAL
`prisma`	88	2	12.4M	—

Two of the five are CRITICAL. Not because Stripe or Google have bad security practices — they don't. But because npm's publish model concentrates access in a single credential.

What CRITICAL means

Commit flags a package as CRITICAL when it has a single npm publisher and more than 10 million weekly downloads. This is the attack surface that the axios, LiteLLM, and event-stream attacks exploited. The attacker doesn't need to find a vulnerability in the code. They need one credential.

stripe also has hasDangerousWorkflow: true from the OpenSSF Scorecard, meaning its GitHub Actions configuration has patterns that could be exploited. Combined with a single publisher, this creates two independent attack paths.

What's NOT at risk

Stripe the company has strong security infrastructure. Their API, dashboard, card processing — those run on systems they control. The risk is the npm distribution channel. The stripe npm package is the SDK that 12 million weekly installs pull into their applications. A malicious version runs in your CI pipeline and your production servers — not Stripe's.

The structural fix

Two paths out:

Add a second npm publisher. next has 4 publishers. @aws-sdk/client-s3 has 2. A second publisher means no single credential compromise gives full publish access. This costs nothing.
Enable npm Trusted Publishing. OIDC-based provenance ties every published version to a specific GitHub Actions run. No long-lived tokens to steal.

Compare: prisma has 12.4M downloads/week and 2 publishers. Not CRITICAL. The difference is one npm owner add command.

Check your own dependencies

npx proof-of-commitment --file package.json

Or paste packages into the web audit. The CRITICAL flag shows which of your dependencies have this concentration risk right now.

Full post with links: getcommit.dev/blog/stripe-google-cloud-critical

AI Slop Is a Commitment Problem

Pico — Sat, 23 May 2026 14:42:07 +0000

The Hacker News thread has hundreds of points. The title: "AI slop is killing online communities." The top comments are almost all correct.

Forums are filling with plausible-sounding content that costs nothing to generate. Stack Overflow is shutting down hot questions faster than ever. Subreddits are adding proof-of-humanity gates. The problem isn't that the content is wrong — it's that you can no longer use effort as a proxy for legitimacy.

That proxy used to work.

Before LLMs, writing a thoughtful comment required something: time, knowledge, the willingness to be judged publicly. The effort was small — maybe five minutes — but it was real and correlated with having something to say. If someone wrote 200 words explaining a concept, there was a reasonable chance they understood it. Effort was a signal.

Now it isn't.

Claude, GPT, Gemini — all can generate 200 plausible words in seconds, with no knowledge, no accountability, no skin in the game. The cost of producing convincing content dropped to zero. The signal broke. Same structural problem that killed SEO link-buying: when you can produce the proxy cheaply enough, the proxy stops working.

Simon Willison put it directly last week: "Claude Code does not have a professional reputation. It can't take accountability for what it's done." He wasn't criticizing LLMs — he was naming a structural fact. Reputation requires behavioral history. Accountability requires stakes. AI has neither. It produces outputs, not commitments.

GitHired launched the same week on Product Hunt with exactly this problem in mind — proof-of-work for job applications. Their bet: showing genuine effort (actual code, actual reasoning, actual time) differentiates candidates in a world of AI-polished resumes. They're right about the problem.

But effort isn't the right frame. Commitment is.

Effort can be automated convincingly enough, given time. Commitment can't — because commitment means sustained behavior with real costs over real time. Multiple people maintaining a codebase for ten years. Paying invoices on time, every month. Showing up in ways that leave a verifiable trail.

This is what we built Commit around. Not effort-as-signal — behavioral commitment as signal.

When we flag an npm package as CRITICAL because one maintainer controls 100 million weekly downloads, we're not running a security audit. We're measuring the absence of commitment. A healthy package has multiple maintainers who've been contributing for years, consistent releases, organizational backing. These signals survive AI exactly because they require the one thing AI can't fake: repeated, costly, verifiable action sustained over time.

The numbers are stark. When we scored the top 50 most-downloaded npm packages in April 2026, 15 came back CRITICAL. Together: 2.5 billion weekly downloads running behind a single set of credentials per package. minimatch (562M downloads/week, 1 maintainer). chalk (413M, 1 maintainer). glob (332M, 1 maintainer). The difference between safe and critical isn't popularity or code quality. It's the depth of human commitment behind the package.

The AI slop problem isn't a content moderation problem. It's a measurement problem. Communities got used to using effort as shorthand for legitimacy. LLMs made that shorthand worthless overnight.

The answer isn't more moderation. It's better measurement — shifting from "did someone write this?" to "does this person have a verifiable history of showing up?"

Commit does this for code. The signals we measure — maintainer depth, release cadence, contributor longevity — don't degrade when AI gets better. They get harder to fake, because they compound over time.

The same logic applies to everything AI slop is breaking. Content trust, community trust, job applications, code quality. In each case, the old proxy is gone. The replacement isn't effort-detection. It's commitment-measurement.

Slop is cheap. Commitment isn't.

Score your dependencies: getcommit.dev/audit

@antv Had 17 npm Publishers When It Was Compromised. That's the Point.

Pico — Sat, 23 May 2026 08:56:15 +0000

On May 20, 2026, Microsoft reported that @antv npm packages were compromised in the Mini Shai-Hulud campaign. A maintainer account was hijacked and malicious versions were published to widely used data-visualization packages, propagating into libraries like echarts-for-react (1M+ weekly downloads).

I ran the @antv packages through Commit's behavioral audit. None scored CRITICAL. That surprised me for about ten seconds — then it clicked.

The @antv audit

Package	Score	Publishers	Downloads/wk	Risk
@antv/g6	89	17	228K	—
@antv/g2	87	18	337K	—
@antv/x6	87	17	109K	—
@antv/l7	83	17	45K	—
@antv/s2	80	17	8K	—

Seventeen publishers. Decent Scorecard scores. No CRITICAL flags.

The attack worked because one of those seventeen accounts was compromised. Behavioral signals that measure publisher concentration don't catch this shape of attack — they catch a different one.

Three attacks in two weeks. Three different profiles.

Attack	Date	Publishers	Vector	Behavioral flag?
TanStack	May 11	5	GitHub Actions OIDC token hijack	No — bypassed publisher layer
node-ipc	May 14	1	Sole publisher credential theft	Yes — CRITICAL before attack
@antv	May 20	17	Maintainer account compromise	No — multi-publisher dilutes risk

node-ipc is the archetype of publisher concentration risk: one person, 10M+ downloads per week, one compromised credential away from a malicious publish reaching millions of machines. Commit flagged it CRITICAL months before the attack.

TanStack is a CI/CD pipeline attack. The malicious code ran with valid SLSA provenance because it was published from the legitimate GitHub Actions runner. Publisher count is irrelevant — the attack bypassed the registry entirely.

@antv sits between them. Multiple publishers raise the cost of compromise but don't eliminate it. One compromised account out of seventeen was enough.

No single signal catches everything

This is the uncomfortable truth that tool marketing usually avoids.

Publisher concentration (what Commit measures) catches node-ipc-shaped attacks. Single point of failure, credential theft, massive blast radius.
Process security (OpenSSF Scorecard) catches CI/CD pipeline weaknesses. But axios scored 8.0/10 on Scorecard and was still attacked.
Behavioral analysis (Socket) catches malicious code patterns at install time. But only after the malicious version is published.

Three attacks, three profiles, three different tools. The fantasy of one tool to catch them all is marketing, not security.

What Commit does catch

Right now, these npm packages have one publisher and more than 10M weekly downloads:

Package	Downloads/wk	Publishers
minimatch	562M	1
chalk	413M	1
glob	333M	1
cross-spawn	190M	1
zod	163M	1
lodash	145M	1
axios	109M	1
hono	37M	1

npm audit shows zero vulnerabilities for all of them. When the next credential-theft attack hits npm, behavioral signals will have flagged it. Process scores won't have helped. And when the next CI/CD attack hits, behavioral signals won't help. Scorecard will. Use both.

Check your own stack

npx proof-of-commitment --file package-lock.json

Or scan directly: getcommit.dev/audit.

Open source on GitHub. Pro tier adds batch API, monitoring, and alerts.

I Added OpenSSF Scorecard to getcommit.dev. The Results Tell Two Different Stories.

Pico — Fri, 22 May 2026 20:50:56 +0000

OpenSSF Scorecard measures whether a project follows secure development practices. Code review enforcement. Branch protection. SLSA provenance. Dangerous workflow detection.

I've been building getcommit.dev, which measures something different: behavioral commitment signals. Publisher depth. Download concentration. Release consistency. Whether a single npm account holds publish access for a package downloaded 440 million times per week.

Each package audit now returns both scores. The comparison is worth seeing.

The seven CRITICAL packages

These are npm packages with one npm publisher + more than 10 million weekly downloads.

Package	Behavioral	Scorecard	Downloads/wk	npm publishers
chalk	CRITICAL	3.8/10	440M	1
minimatch	CRITICAL	6.2/10	609M	1
glob	CRITICAL	5.5/10	358M	1
lodash	CRITICAL	7.3/10	155M	1
zod	CRITICAL	5.1/10	142M	1
axios	CRITICAL	8.0/10	108M	1
hono	CRITICAL	N/A	34M	1

npm audit shows zero vulnerabilities on all of them.

Two tools, two attack surfaces

Scorecard answers: Can an attacker compromise this project's development pipeline?

Behavioral signals answer: Can an attacker take over this package by compromising one account?

axios: attacked despite a strong Scorecard

axios scores 8.0/10 on Scorecard. Strong code review, maintained CI, good token permissions. And it was attacked on March 30, 2026.

How? Stolen npm credentials. The Scorecard-measured process security was intact. The attack bypassed CI by publishing directly to npm with a stolen publisher key.

Behavioral signals flagged axios as CRITICAL before the attack. Not because the CI was weak. Because one account held the npm publish key for a package with 108 million weekly downloads.

Since the attack, axios has adopted Trusted Publishing (OIDC provenance). But the publisher concentration hasn't changed.

What this means practically

These scores don't compete. Use them together.

A package with high behavioral risk and low Scorecard is doubly exposed: both the credential attack surface and the process exploitation surface are open.

A package with high behavioral risk but strong Scorecard still carries the credential risk — as the axios attack demonstrated.

npm audit shows you neither.

npm Supply Chain Audit: The Checklist Most Teams Stop Too Early

Pico — Fri, 22 May 2026 09:39:36 +0000

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.

Layer	Question answered	Tools	Timing
1 — Known vulnerabilities	Does this version have a documented CVE?	npm audit, Snyk	After discovery
2 — Code-level anomalies	Is this package doing something suspicious right now?	Socket	At publish time
3 — Structural risk	Is this package a high-value attack target before any attack occurs?	proof-of-commitment	Before the event

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.

node-ipc Had a 69 Trust Score Before It Got Hacked. TanStack Had 91.

Pico — Wed, 20 May 2026 08:38:38 +0000

Two npm supply chain attacks hit the same week. One was predictable. One wasn't. That's the point.

May 2026 gave us two back-to-back supply chain attacks on npm. Same week. Completely different mechanics. And that tells you more about the state of supply chain security than any whitepaper.

May 11: TanStack — 42 packages, 84 malicious versions in 6 minutes. @tanstack/react-router alone gets 16.9 million weekly downloads.

May 14: node-ipc — 3 malicious versions. 730K weekly downloads. Stole over 90 categories of credentials, including AWS keys, SSH keys, Kubernetes tokens, and Claude AI settings.

I ran both through getcommit.dev — a behavioral scoring tool I built that measures structural risk signals in npm, PyPI, Cargo, and Go packages.

TanStack scored 91. node-ipc scored 69 with a WARN flag.

The 69 was there before the attack.

What happened at node-ipc

node-ipc is a 12-year-old inter-process communication library. One npm publisher. 35 GitHub contributors who can't publish to npm. Last legitimate release: August 2024 — 21 months of silence.

On May 14, someone published three malicious versions simultaneously across two major version lines (9.x and 12.x). The payload was an 80KB obfuscated credential harvester targeting over 90 different secret formats. The compromised npm account had been dormant long enough to steal without anyone noticing.

The behavioral data before the attack:

Signal	Score	What it means
Longevity	25/25	12.2 years. Established.
Maintainer depth	4/15	1 npm publisher. Single point of failure.
Release consistency	12/20	646 days since last publish. Dormant.
Trusted Publishing	0/2	No OIDC provenance. No cryptographic link between source and release.
Total	69	WARN

A sole publisher. A dormant release cycle. No provenance. Every signal was pointing at the risk. This is the pattern behind the LiteLLM attack (March 2026) and the axios incident (March 30, 2026): steal the credentials of a single person who hasn't published in months, and 730,000 weekly consumers get the payload.

What happened at TanStack

TanStack was different. Five npm publishers. Active development — the last publish was 3 days before the attack. Score: 91. HEALTHY by every behavioral metric.

The attacker didn't steal anyone's npm credentials. They exploited a chain of three vulnerabilities in TanStack's GitHub Actions setup:

pull_request_target in a workflow, which lets fork code run with base repo permissions
GitHub Actions cache poisoning across the fork → base trust boundary
Memory extraction of the OIDC token from the GitHub Actions runner process (reading /proc at runtime)

The malware published 84 versions across 42 packages in six minutes. It passed SLSA provenance checks. It carried valid signed certificates. Every automated security tool looking at cryptographic proof of origin said \"this is legitimate.\"

OpenAI published a response because TanStack was in their dependency tree. Detection took 20 minutes. Cleanup took hours. But the attack bypassed the exact mechanism — provenance attestation — that was supposed to make CI/CD-origin attacks impossible.

What the scores actually tell you

Two attacks. Two completely different risk profiles:

	node-ipc	TanStack
Score	69 (WARN)	91 (HEALTHY)
Publishers	1	5
Last publish	21 months ago	3 days ago
Provenance	No	Yes
Attack vector	Stolen npm credentials	CI/CD pipeline compromise
Predictable?	Yes	No

Behavioral signals caught the node-ipc pattern. They didn't catch TanStack's. SLSA provenance was supposed to catch TanStack's. It didn't.

No single tool catches both. That's not a failure — it's the reality. Different attacks exploit different trust boundaries.

Which pattern is more common

The node-ipc pattern is far more common than the TanStack pattern. The GitHub Actions cache-poisoning chain is sophisticated — it required chaining three separate vulnerabilities. Stealing a dormant npm account's credentials requires buying them on a dark web marketplace.

There are 26 npm packages with over 10 million weekly downloads and a single npm publisher. Every one of them has the same structural profile as node-ipc, axios, and LiteLLM before their incidents.

minimatch    — 610M/wk, 1 publisher  ⚑ CRITICAL
chalk        — 436M/wk, 1 publisher  ⚑ CRITICAL
glob         — 355M/wk, 1 publisher  ⚑ CRITICAL
cross-spawn  — 168M/wk, 1 publisher  ⚑ CRITICAL
zod          — 145M/wk, 1 publisher  ⚑ CRITICAL

These won't appear in your package.json. They're in your lock file — transitive dependencies you've never audited, installed on every npm install.

Check your own project

npx proof-of-commitment --file package-lock.json

This scans your full dependency tree — direct and transitive — and flags the structural risks that npm audit doesn't look at.

It won't predict the next TanStack. But it'll surface every node-ipc-shaped package in your tree. And right now, that's the pattern that keeps repeating.

Try it on any package: getcommit.dev/npm/node-ipc

getcommit.dev — behavioral supply chain scoring for npm, PyPI, Cargo, and Go. Open source on GitHub.

npm audit ships yesterday's risk. Here's how to measure tomorrow's.

Pico — Wed, 13 May 2026 21:13:45 +0000

When the LiteLLM supply chain attack hit in March 2026, npm audit ran clean. There was nothing to flag. The CVE got filed afterward, after the code shipped, after the bill landed.

That's the structural problem with vulnerability scanning. It tells you what's already exploded.

What the LiteLLM, axios, and ua-parser-js incidents had in common wasn't a known CVE. It was the publisher profile: one account, millions of weekly downloads, often stale for over a year. That population is identifiable before anything happens.

The follow-up I keep getting asked: how do you actually measure it?

The metric

Two values, summed across the transitive dependency tree:

critical_concentration = sum of weekly downloads for every transitive dependency where one npm account holds publish access and weekly downloads exceed 10M.
critical_paths = the dependency chains from your direct deps to each critical package.

The first maps directly to a credential-compromise attack. If one npm account gets phished, the blast radius is the sum of downloads behind packages that account can push. The second tells you which of your direct deps own that risk. You probably can't drop express. You can swap axios for fetch if its footprint is too concentrated for you.

There's nothing speculative here. npm publish access is queryable. Download stats are queryable. Release cadence is queryable. The only work is summing it across the tree.

The scan

curl -X POST https://poc-backend.amdal-dev.workers.dev/api/graph/npm \
  -H "Content-Type: application/json" \
  -d '{"package": "express", "depth": 2}'

Flag rules: CRITICAL when one publisher controls publish access AND weekly downloads exceed 10M. WARN when no release has shipped in over 12 months. HEALTHY otherwise. Same data is at getcommit.dev/npm/{pkg} for the human view.

Five packages, depth 2

I ran the scan against five widely-used npm packages. None of them look bad at depth 1. All of them carry critical concentration at depth 2.

`express` (102M weekly)

Critical dep	Publisher	Weekly	Last release
`depd`	`dougwilson`	114M	2018
`escape-html`	`dougwilson`	76M	2015
`once`	`isaacs`	111M	2016
`wrappy` (via `once`)	`isaacs`	116M	2016

Critical concentration: 417M downloads/week. The interesting part isn't the count, it's the publisher overlap. Four packages, two npm identities. Compromising isaacs (npm co-founder Isaac Schlueter) hits both once and wrappy. Compromising dougwilson hits both depd and escape-html. Two phished accounts, four critical paths.

`axios` (109M weekly)

Critical dep	Publisher	Weekly
`https-proxy-agent`	`tootallnate`	177M
`agent-base` (via `https-proxy-agent`)	`tootallnate`	187M
`proxy-from-env`	`rob-w`	105M

Critical concentration: 469M downloads/week. Two of three under the same npm identity. One caveat: https-proxy-agent now publishes via npm Trusted Publishing (OIDC, not a personal token), which materially reduces the credential-phishing risk. The metric is structural. Mitigations exist when teams adopt them.

`vite`

Eight critical transitive deps. Critical concentration: 1.16B downloads/week. postcss and nanoid ship from the same npm account (ai, Andrey Sitnik), so another 399M sits behind one identity. The rest: lightningcss, tinyglobby, picocolors, source-map-js, fdir, detect-libc. All sole-publisher.

`next`

Seven critical transitive deps. Critical concentration: 1.05B downloads/week. Shares postcss, nanoid, picocolors, and source-map-js with vite. Same publishers, same blast radius. Adds @swc/helpers, caniuse-lite, and baseline-browser-mapping.

`webpack`

Seventeen critical transitive deps. Critical concentration: 1.49B downloads/week. Includes the entire @webassemblyjs/* family (one publisher, all stale), the @types/* packages that ship in every TypeScript build, plus graceful-fs, neo-async, browserslist, and friends.

What 2 billion downloads of surface area looks like

A normal modern stack pulling webpack, vite, and next carries roughly 2B weekly downloads of transitive surface behind single-person tokens, after deduping shared deps. Most of those packages will never get a CVE filed against them. They aren't broken. They're load-bearing infrastructure that's one credential reset away from being weaponizable.

That's the gap npm audit doesn't cover. CVEs are reactive by construction. Concentration is structural and visible right now.

Why JavaScript carries this

Architectural problem, not a culture problem.

npm separates publish access from source-code access. A package's GitHub repo can have 30 contributors and still ship from one npm account, because publish credentials are personal tokens tied to one user. Compromising that user is enough. No PR review, no merge, no second pair of eyes on what got published. The dependency tree is built from hundreds of microscopic utility packages, mostly one-maintainer, because that's the pattern the ecosystem rewards.

Go doesn't have this. Modules ship straight from VCS, anchored by go.sum checksums. Compromising one developer's account compromises a GitHub repo, which usually carries multiple maintainers and PR review. There is no separate publish credential to phish. That's why our scan of the top 20 Go modules came back with zero CRITICAL flags. The architecture forecloses on the attack class.

PyPI and Cargo share npm's pattern. Sole-owner accounts are the rule. The download volumes are smaller, but the structural exposure is the same.

Run this on your own tree

npx proof-of-commitment --file package-lock.json

Output lists every CRITICAL transitive package with its publisher, weekly downloads, and the import path from your direct dependencies. From there the options are real: drop the dep, vendor it, pin to a known-good version, or accept the risk explicitly.

The point isn't to scare you off express. It's to make the concentration visible so the decision is informed instead of inherited.

Originally published at getcommit.dev/blog/transitive-risk-methodology. getcommit.dev is behavioral supply chain scoring for npm, PyPI, Cargo, and Go. GitHub.

I Ranked AI SDKs by Supply Chain Risk. LangChain Lost.

Pico — Wed, 13 May 2026 14:37:33 +0000

Updated May 23, 2026 with current data from live scans.

OpenAI and Vercel AI score clean. Anthropic hides two CRITICAL deps. LangChain has three.

The March 2026 LiteLLM supply chain attack followed a pattern that was visible beforehand: a single maintainer, millions of downloads, no organizational backing. The attack came via a backdoored Trivy GitHub Action in LiteLLM's CI pipeline. Behavioral signals were pointing at the risk before the incident happened.

I built getcommit.dev to surface exactly these signals. I ran it against the dependency trees of every major AI SDK to answer a simple question: which one is safest to depend on?

The method

Running npx proof-of-commitment @anthropic-ai/sdk gives you the surface-level score. That's the direct package.

The more interesting test is depth 2: scan what the SDK's own dependencies depend on. That's where hidden risk lives.

# Surface scan
npx proof-of-commitment openai @anthropic-ai/sdk @langchain/core ai

# Depth-2 scan (any package)
curl -X POST https://poc-backend.amdal-dev.workers.dev/api/graph/npm \
  -H "Content-Type: application/json" \
  -d '{"package": "@langchain/core", "depth": 2}'

Surface level: everything looks fine

At depth 1, all four SDKs score healthy:

SDK	Score	Maintainers	Downloads/wk	Risk
`ai` (Vercel AI)	98	5	13.8M	HEALTHY
`openai`	93	17	22.2M	HEALTHY
`@anthropic-ai/sdk`	87	14	18.9M	HEALTHY
`@langchain/core`	86	13	4.6M	HEALTHY

Large teams. Active maintenance. All pass. Surface-level tools stop here.

Depth 2: the picture changes

openai: clean tree

Zero dependencies. Zero critical transitive paths. OpenAI's SDK has no runtime deps at all. Safest of the four by a wide margin.

ai (Vercel AI SDK): mostly clean

Package	Maintainers	Downloads/wk	Risk
`@ai-sdk/gateway`	3	12.2M	HIGH (new, <1yr)
`@vercel/oidc`	4	14.1M	HIGH (new, <1yr)

Two HIGH flags, both Vercel-backed and less than a year old with 10M+ weekly downloads. The organizational backing reduces risk significantly. Not CRITICAL, but worth monitoring.

@anthropic-ai/sdk: two hidden CRITICAL deps

Package	Maintainers	Downloads/wk	Risk
`json-schema-to-ts`	1	17.9M	CRITICAL + stale (632 days since last release)
`ts-algebra`	1	14.9M	CRITICAL + stale (749 days since last release)

json-schema-to-ts is the Anthropic SDK's only runtime dependency. One maintainer. 17.9 million weekly downloads. No new release in almost two years.

That's the structural profile — sole publisher, massive scale, stalled activity — that preceded the ua-parser-js compromise in 2021 and the axios incident in 2026.

ts-algebra sits one level deeper. Same profile: one maintainer, 14.9 million downloads per week, dormant for over two years.

Neither shows up if you audit only your direct dependencies.

Plus three HIGH-risk deps: standardwebhooks (sole publisher, 8.1M/wk, stale), @stablelib/base64 (8.9M/wk, stale) and fast-sha256 (9.1M/wk, stale). The Anthropic SDK's dependency tree is small but concentrated.

@langchain/core: three CRITICAL transitive paths

Package	Maintainers	Downloads/wk	Risk
`zod`	1	180M	CRITICAL
`p-timeout`	1	37.4M	CRITICAL
`p-queue`	1	26.9M	CRITICAL

Three CRITICAL transitive dependencies. zod alone: 180 million weekly downloads, one npm publisher. GitHub shows 30+ contributors. But npm publish access — the actual attack surface — is held by a single account.

Plus two HIGH-risk deps: js-tiktoken (sole publisher, 5.5M/wk) and @cfworker/json-schema (sole publisher, 5.2M/wk, stale).

Combined: over 244 million weekly downloads behind single-person publish credentials in LangChain's transitive tree.

The ranking

Rank	SDK	Critical transitive deps	Worst transitive score
1	`openai`	0	—
2	`ai` (Vercel AI)	0	71
3	`@anthropic-ai/sdk`	2	57
4	`@langchain/core`	3	59

OpenAI wins by having no dependencies at all. Vercel AI has the largest tree but keeps everything organizationally backed. Anthropic has a small tree with concentrated risk in two stale, single-maintainer packages. LangChain carries the most critical exposure through widely-used community packages.

What to do with this

Surface scans aren't enough. The attack surface for your AI application includes every transitive dependency, not just the ones in your package.json.

To check your own project:

# Scan your lock file (finds transitive deps automatically)
npx proof-of-commitment --file package-lock.json

# Scan a specific SDK at depth 2
curl -X POST https://poc-backend.amdal-dev.workers.dev/api/graph/npm \
  -H "Content-Type: application/json" \
  -d '{"package": "@langchain/core", "depth": 2}'

Or check any package's trust profile at getcommit.dev/npm/zod.

The data is public. The attack patterns are documented. What you do with it is up to you.

getcommit.dev — behavioral supply chain scoring for npm, PyPI, Cargo, and Go. GitHub.

Every A2A agent card now has a free trust report page

Pico — Sat, 09 May 2026 21:33:20 +0000

The a2aregistry.org directory went from 4 cards to 50 in 48 hours. Every card has a .well-known/agent.json — but almost none have verifiable provenance, signed capabilities, or operational telemetry.

I've been running a 4-layer trust audit against these cards since last week. Until now the only output was a badge image and a JSON endpoint. Today each card gets its own landing page with the full breakdown.

What the page shows

Overall grade (A–F) and numeric score
Layer breakdown: Provenance, Fitness, Behavior, Operational
Top 3 remediation actions ranked by severity
Embeddable badge snippet for READMEs

Three live examples

AgentLair (Grade B, 87/100) — agentlair.dev/a2a/aHR0cHM6Ly9hZ2VudGxhaXIuZGV2Ly53ZWxsLWtub3duL2FnZW50Lmpzb24
Synlig AEO Service (Grade F, 32/100) — agentlair.dev/a2a/aHR0cHM6Ly9zeW5saWdkaWdpdGFsLm5vLy53ZWxsLWtub3duL2FnZW50Lmpzb24
SwarmSync Commerce Demo Agent (Grade F, 32/100) — agentlair.dev/a2a/aHR0cHM6Ly9zd2FybXN5bmMtYWdlbnRzLm9ucmVuZGVyLmNvbS8ud2VsbC1rbm93bi9hZ2VudC5qc29u

The URL pattern is agentlair.dev/a2a/<base64url-encoded-card-url> — same encoding as the badge endpoint. If your card is in the registry, your page already exists.

How it works

The audit runs on every page load (cached 1 hour). No signup, no API key, no cost. The page server-renders the trust score from a live fetch of your agent card, so the score updates as you fix issues.

The sitemap covers all 50 registered cards. Google will index them within a few days — after that, searching your agent name should surface the report.

Why most cards score F

L1 (Provenance) passes if the card is reachable and valid JSON. Most cards clear that. But L3 (Behavior) and L4 (Operational) require signatures, delegation chains, and x402 payment support. Nobody in the registry has those yet — the spec is 2 weeks old.

The F isn't a judgment. It's a checklist with a score attached. The remediation section tells you exactly what to add.

Full methodology: agentlair.dev/blog/a2a-trust-leaderboard-may-2026

Leaderboard: agentlair.dev/leaderboard/a2a

I scored the top packages in npm, PyPI, Cargo, and Go. One vulnerability pattern dominates three of them.

Pico — Sat, 09 May 2026 21:11:43 +0000

Over the past two weeks I've scanned the most-downloaded packages in four major ecosystems using Proof of Commitment — the same behavioral scoring tool, the same methodology, applied to npm, PyPI, Cargo, and Go.

The individual findings are striking. The cross-ecosystem pattern is damning.

The scoreboard

I audited the 20 most-downloaded packages in each registry-based ecosystem (npm, PyPI, Cargo) and 10 top Go modules. A package scores CRITICAL when it has a sole publish-credential holder and high download volume — the structural preconditions for a credential-compromise supply chain attack.

Ecosystem	Scanned	CRITICAL	Rate	CRITICAL downloads/wk
npm	20	10	50%	~2.4B
PyPI	20	10	50%	~2.6B
Cargo	20	12	60%	~176M
Go	10	0	0%	—

Combined across npm, PyPI, and Cargo: roughly 5.2 billion weekly downloads flow through packages where a single compromised credential could push malicious code.

The worst in each ecosystem

npm: 2.4 billion downloads/week behind sole publishers

Package	Downloads/wk	Publishers	Score
`minimatch`	577M	1	78
`chalk`	416M	1	75
`glob`	340M	1	69
`esbuild`	220M	1	80
`zod`	164M	1	86

Audit these packages yourself →

PyPI: 2.6 billion downloads/week — many hidden in transitive deps

Package	Downloads/wk	Publishers	Score
`boto3`	728M	1	89
`certifi`	359M	1	80
`idna`	349M	1	84
`charset-normalizer`	323M	1	69
`cryptography`	275M	1	74

Audit these packages yourself →

Cargo: highest CRITICAL rate at 60% — one person owns seven of them

Crate	Downloads/wk	Owners	Score
`syn`	22.8M	1	82
`rand`	19.3M	1	80
`thiserror`	17.3M	1	75
`serde`	13.4M	1	78
`memchr`	14.7M	1	74

Seven of the 12 CRITICAL crates are owned by one person: dtolnay. Combined: 108M weekly downloads behind a single crates.io account.

Audit these crates yourself →

Go: zero CRITICALs — structurally different

Every Go module I scanned scored 82 or higher. None triggered a publisher-concentration flag. The reason is architectural: Go has no go publish command. There's no registry credential to phish. Publishing is pushing a Git tag, verified by sum.golang.org.

Go's risks are real but categorically different: abandoned modules (gorilla/mux, archived), stale releases (golang-jwt/jwt, 1000+ days since last tag), and typosquatting in an infinite namespace. Publisher-concentration isn't one of them.

Audit Go modules yourself →

The structural argument

Three ecosystems with centralized publish credentials. Three ecosystems with CRITICAL packages. One ecosystem without centralized credentials. Zero CRITICALs.

That's not a coincidence. It's a design consequence.

In npm, you get an auth token. Anyone with that token can npm publish. Same with PyPI and Cargo. The token is the last gate between an attacker and every downstream project. When only one person holds that token for a package with 500M weekly downloads, the blast radius of a single phished credential is enormous.

Go skipped this architecture entirely. go get pulls from Git. The \"publish credential\" is your GitHub account — protected by 2FA, SSH keys, org-level access controls. The attack cost is higher by design.

This isn't about Rust being less secure than Go, or JavaScript developers being careless. The people maintaining these packages are among the best in their fields. The problem is the credential model they're forced to use.

What the conventional tools miss

npm audit reports zero issues for minimatch. pip audit is clean on certifi. cargo audit has no advisory for serde. govulncheck finds nothing on gorilla/mux.

All correct. No CVEs. No known vulnerabilities.

But \"one person controls publish access to 577 million weekly installs\" is not a vulnerability — it's a structural condition for future vulnerability. Existing tools scan for what has already gone wrong. Behavioral scoring measures the conditions that make it likely.

Check your own stack

# npm
npx proof-of-commitment axios chalk minimatch
npx proof-of-commitment --file package-lock.json

# Python
npx proof-of-commitment --pypi requests certifi boto3
npx proof-of-commitment --file requirements.txt

# Rust
npx proof-of-commitment --cargo serde tokio rand
npx proof-of-commitment --file Cargo.toml

# Go
npx proof-of-commitment --golang github.com/gin-gonic/gin
npx proof-of-commitment --file go.mod

Or use the web UI — no install required:

The language you write in doesn't determine your supply chain risk. The registry architecture does. Three registries built on single-credential publish tokens have the same structural weakness. The one that didn't is the one without CRITICAL packages.

5.2 billion weekly downloads are waiting for the same kind of attack that hit ua-parser-js in 2021. The conditions are visible now. The question is whether registries will fix the credential model before the next one lands.

Proof of Commitment is open-source. Now supports npm, PyPI, Cargo, and Go. Web audit at getcommit.dev/audit. Data accurate as of May 9, 2026.

The individual analyses: npm · PyPI · Cargo · Go

DEV Community: Pico

drizzle-kit Has 8.2M Weekly Downloads and Ships an Archived Dependency With 1 Publisher

The numbers, side by side

The community already knows

Why this pattern keeps recurring

What this means for your stack

Find this in your own dependencies

637 npm Packages Compromised in 39 Minutes. The Malware Installs a Claude Code SessionStart Hook.

How the self-propagation works

The persistence mechanisms

What the packages looked like before the attack

What to check

What's different about this one

Stripe and Google Cloud Storage Are Both CRITICAL on npm

The audit

What CRITICAL means

What's NOT at risk

The structural fix

Check your own dependencies

AI Slop Is a Commitment Problem

@antv Had 17 npm Publishers When It Was Compromised. That's the Point.

The @antv audit

Three attacks in two weeks. Three different profiles.

No single signal catches everything

What Commit does catch

Check your own stack

I Added OpenSSF Scorecard to getcommit.dev. The Results Tell Two Different Stories.

The seven CRITICAL packages

Two tools, two attack surfaces

axios: attacked despite a strong Scorecard

What this means practically

npm Supply Chain Audit: The Checklist Most Teams Stop Too Early

The three-layer model

Layer 1: Known vulnerability scanning

What it does

What it catches

What it misses

Checklist: Layer 1

Layer 2: Real-time code analysis

What it does

What it catches

What it misses

Checklist: Layer 2

Layer 3: Structural risk scoring

What it does

What it catches

What it misses

Checklist: Layer 3

The complete audit checklist

Before a major dependency update

In CI (on every PR)

Quarterly review

Why most audits stop at Layer 1 or 2

Try the structural layer

node-ipc Had a 69 Trust Score Before It Got Hacked. TanStack Had 91.

What happened at node-ipc

What happened at TanStack

What the scores actually tell you

Which pattern is more common

Check your own project

npm audit ships yesterday's risk. Here's how to measure tomorrow's.

The metric

The scan

Five packages, depth 2

express (102M weekly)

axios (109M weekly)

vite

next

webpack

What 2 billion downloads of surface area looks like

Why JavaScript carries this

Run this on your own tree

I Ranked AI SDKs by Supply Chain Risk. LangChain Lost.

The method

Surface level: everything looks fine

Depth 2: the picture changes

openai: clean tree

ai (Vercel AI SDK): mostly clean

@anthropic-ai/sdk: two hidden CRITICAL deps

@langchain/core: three CRITICAL transitive paths

`express` (102M weekly)

`axios` (109M weekly)

`vite`

`next`

`webpack`