DEV Community: mckeane mcbrearty

I watched Shai Hulud steal credentials from teams running npm audit. Here's the gap nobody talks about.

mckeane mcbrearty — Sat, 11 Apr 2026 16:25:51 +0000

September 2025. PostHog, Zapier, Postman, ENS Domains. Over 500 packages compromised. Credentials pulled from developer machines and CI agents. When the malware found an npm token, it automatically published backdoored versions of every package that token had access to. No human needed after the first infection.

Every team I watched get hit was running npm audit. Some had Snyk. One had Dependabot. All of it passed clean.

I spent the next few months figuring out why, then built something to fix it.

The problem with npm audit

npm audit checks your dependency versions against a database of known vulnerabilities. If there's no advisory filed, it returns zero findings.

With supply chain attacks, there's no advisory to file. The package does exactly what the attacker intended. A preinstall hook that reads ~/.npmrc and posts it to a webhook is working as designed. npm audit has nothing to flag.

From recent attacks, all clean passes at time of compromise:

axios (~100M weekly downloads) — maintainer account compromised by a North Korean state actor on March 31, 2026. A fake dependency was injected with a postinstall hook that dropped a cross platform RAT on Windows, macOS, and Linux. Live for about two hours before removal. Dependency Guardian flagged it.
xrpl (~135K weekly downloads) — backdoored through a compromised maintainer account
eslint-config-prettier (~30M downloads) — hijacked via phishing
chalk and debug (~299M downloads) — compromised in a coordinated attack
Shai Hulud packages (~2.6B combined downloads affected) — selfpropagating worm

None of these had CVEs when they were actively stealing credentials. The CVE came later.

What actually catches these

Every major supply chain attack in the last year used the same pattern. Credential theft, network exfiltration, install script abuse. A string padding library doesn't need child_process. A color utility doesn't need to make outbound HTTP calls. A patch release shouldn't add obfuscated network calls that weren't in the previous version.

You don't need a database to spot any of that. You need something that reads the published tarball and checks what the code does before it runs in your pipeline.

Dependency Guardian does that.

How it works

The scanner is written in Rust. It runs behavioral analysis on the published tarball before anything installs. No CVE lookup, no LLM, fully deterministic. Same package gets the same result every time.

The detection covers credential theft, shell execution, network exfiltration, obfuscation, time bombs, and CI secret access. Findings don't just get flagged individually. They get correlated. A child_process import by itself is a weak signal. That same package also making outbound network calls and reading environment variables in a patch release is a confirmed exfiltration pattern and it gets auto blocked. No triage queue.

There's also a behavioral sandbox that runs packages in an isolated container to catch things static analysis misses, like payloads that only activate after a time delay.

Validated against 133,516 real packages (53,119 malicious, sourced from DataDog's malicious packages dataset, OpenSSF, and the GitHub Advisory Database):

99.5% detection rate on npm, 99.2% on PyPI
0.6% false positive rate
F1 score 99.79%

Full methodology at westbayberry.com/benchmark.

Using it in CI

GitHub App scans the lockfile diff on every PR and posts findings as a check. A package with a credential stealing install script gets blocked before the merge.

CLI for one off checks or non GitHub CI:

npm install -g @westbayberry/dg
dg scan

It reads your lockfile, sends package names and versions to the detection API, and returns findings. Your source code never leaves your machine.

If you want to verify that's actually all it sends, the client is open source. You can read exactly what goes over the wire before you run anything: npmjs.com/package/@westbayberry/dg.

Free tier is 1,000 scans per month. No account needed for the CLI.

On false positives

A tool that blocks PRs on weak signals gets turned off.

Socket, the main competitor here, introduced three alert severity tiers because of noise. At scale, triaging medium risk alerts becomes someone's actual job. We handle that at the detection layer. Signals correlate into high confidence patterns before anything blocks. Single weak signals don't stop your pipeline, they feed a risk score.

Socket also uses LLM inference on each scan, which means results vary between runs and detection depends on a third party API staying up. Our scanner is deterministic. When a block fires you can trace it to the exact rule that triggered it.

The thing that doesn't get said

Most attackers aren't trying to evade behavioral detection. They're using the same preinstall script playbook they've used for years because most teams have zero visibility into what their packages actually do at install time.

Going from nothing to behavioral analysis blocks an entire category of attack and forces the rest into increasingly constrained patterns. The teams that move first on this have a real advantage right now, because most of their peers are still relying on a database that only knows about yesterday's attacks.

Try it:

npm install -g @westbayberry/dg && dg scan

Or install the GitHub App for automatic PR scanning with no config.

How Dependency Guardian Would Have Caught Shai-Hulud

mckeane mcbrearty — Tue, 03 Mar 2026 15:05:00 +0000

In September 2025, the npm ecosystem experienced its first self-replicating worm. The attacker published a single malicious package under a common typosquat name. Within 24 hours, 500+ packages were compromised. By the time the second wave subsided in November, 796 packages had been infected. The worm was called Shai-Hulud.

Every major CVE-based security tool — Dependabot, Snyk, npm audit — gave it a clean bill of health.

This post is a technical breakdown of exactly how Dependency Guardian's behavioral analysis engine would have blocked Shai-Hulud at the PR gate, before a single infected package entered your dependency tree.

What Shai-Hulud Did

The attack was elegant in its simplicity. The initial payload was a preinstall script that executed a bundled JavaScript file:

{
  "name": "colros",
  "version": "1.5.0",
  "scripts": {
    "preinstall": "node scripts/setup.js"
  }
}

That setup.js file did four things:

Read npm tokens from ~/.npmrc and environment variables (NPM_TOKEN, GITHUB_TOKEN)

Exfiltrated the tokens via the GitHub API — POST https://api.github.com/repos//shai-hulud/issues — disguised as normal GitHub traffic

Used Bun-specific APIs (Bun.spawn, Bun.file) to bypass Node.js security sandboxes that only monitor child_process and fs

Ran npm publish on every package the stolen token had write access to, injecting the same preinstall hook into each one

The self-replication loop was the breakthrough. Previous npm attacks were one-shot: compromise a package, steal data, done. Shai-Hulud was a worm. Every victim became a new attack vector.

Why Existing Tools Missed It

The answer is straightforward: there was no CVE to match against.

CVE-based tools work by maintaining a database of known-vulnerable package versions. When you run npm audit, it checks your lockfile against that database. If package@version appears in the database, you get an alert. If it doesn't, silence.

Shai-Hulud was a zero-day. No CVE existed. No advisory had been filed. The infected packages were otherwise-legitimate libraries with new patch versions published using stolen credentials. From the perspective of npm audit, version 2.3.1 of a popular utility was just another routine update.

The attack also made deliberate choices to evade heuristic tools:

GitHub API for exfiltration: most network-based heuristics allowlist github.com as a known-good domain

Bun runtime APIs: security sandboxes that hook child_process.exec and fs.readFileSync saw nothing because the code used Bun.spawn and Bun.file instead

No obfuscation: the code was clean, readable JavaScript — no base64 encoding, no eval, no string concatenation tricks

Which Dependency Guardian Detectors Would Fire

Dependency Guardian doesn't ask "is this package in a vulnerability database?" It asks "what does this code do?" Each of the 26 behavioral detectors examines a specific capability. Here's what would have triggered on Shai-Hulud's payload:

Detector	Severity	What It Caught
install_script	5	preinstall hook executing node scripts/setup.js — a non-benign script running arbitrary code at install time
child_process	4	Shell command spawning during the install lifecycle (4-pass detection: static imports, high-risk calls, inline requires, dynamic identifier-aware patterns)
network_exfil	5	Outbound HTTP calls to api.github.com — the 5-pass architecture catches builtin HTTP, third-party clients, WebSocket, DNS, and global APIs like fetch regardless of the destination domain
ci_secret_access	5	Reading NPM_TOKEN and GITHUB_TOKEN from process.env — the 17-pattern engine with PROC/ENV/D/BO building blocks catches dot notation, bracket notation, destructuring, aliasing, and optional chaining
token_theft	5	Reading ~/.npmrc via file system calls — 21 credential target patterns including .npmrc, .yarnrc, and path.join split-path evasions
bun_runtime_evasion	4	Bun.spawn, Bun.file API usage — detects dot notation, bracket notation (Bun['spawn']), .call/.apply/.bind, globalThis.Bun, and destructured aliases
worm_behavior	5	npm publish commands executed programmatically — catches exec('npm publish'), spawn('npm', ['publish']), Bun.spawn publish variants, and execa wrappers

Seven detectors. Seven independent signals that this package is doing things a color utility should never do.

A Closer Look at the Detection

Consider what the ci_secret_access detector sees when it scans setup.js:

// Shai-Hulud's token harvesting (simplified)
const token = process.env.NPM_TOKEN || process.env.npm_token;
const ghToken = process.env.GITHUB_TOKEN;

The detector's 2-pass per-file architecture first runs findAliases() to discover any process.env aliasing (destructuring, variable assignment, globalThis indirection). Then buildAliasPatterns() generates dynamic regexes specific to that file. Even if the attacker had written:

const e = process["env"];
const t = e["NPM" + "_TOKEN"];

The alias tracking would catch the process["env"] assignment, and the string concatenation evasion pattern would flag the token construction at severity 4.

The worm_behavior detector is similarly thorough. It doesn't just grep for npm publish. It looks for the entire taxonomy of programmatic publishing:

// All of these trigger worm_behavior:
exec("npm publish --access public");
spawn("npm", ["publish"]);
Bun.spawn(["npm", "publish"]);
Bun["spawnSync"](["bun", "publish"]);   // bracket notation evasion
execa("npm", ["publish"]);
execaCommand("npm publish");

Each pattern carries a weight of 3. A single match is enough for a severity 5 finding.

How the Correlator Amplifies Signals

Individual detectors produce findings. The correlator examines combinations of findings across detectors and generates amplifier findings when multiple signals co-occur in the same package. This is where Shai-Hulud's score goes from "suspicious" to "automatic block."

Four amplifiers would fire:

worm_propagation (severity 5, critical)

Fires when worm_behavior + (token_theft OR ci_secret_access) are both present. The correlator's evidence string is explicit:

"This matches the Shai-Hulud worm pattern: steal tokens, publish malicious versions"

This amplifier was added specifically because of Shai-Hulud. Confidence is capped at 0.95, and the critical: true flag means the score is floored at 100.

secret_theft (severity 5, critical)

Fires when ci_secret_access + network_exfil co-occur. The package reads secrets from the environment AND sends data over the network. Confidence derived from the weakest constituent + 0.15 boost, capped at 0.9.

install_download_exec (severity 5)

Fires when install_script + network_exfil co-occur. A lifecycle hook that makes network calls is the canonical dropper pattern. Capped at 0.85 confidence.

bun_evasion_attack (severity 5, critical)

Fires when bun_runtime_evasion + (network_exfil OR token_theft) co-occur. Using Bun-specific APIs alongside network exfiltration or credential theft indicates deliberate sandbox evasion.

All four of these amplifier IDs appear in the UNCONDITIONAL_BLOCK_IDS list in the reporting engine. Any single one of them triggers an automatic block regardless of the numeric score.

What the Scan Output Would Look Like

When Dependency Guardian runs in CI (as a GitHub Action, GitLab CI step, or any PR gate), the scan would produce output like this:

Package: colros@1.5.0

Score: 100 / 100

Verdict: BLOCK

Findings (7 base + 4 amplifiers):

[sev 5] install_script — Suspicious preinstall script

[sev 5] ci_secret_access — Reads NPM_TOKEN, GITHUB_TOKEN from environment

[sev 5] token_theft — Reads ~/.npmrc credential file

[sev 5] network_exfil — HTTP POST to api.github.com

[sev 5] worm_behavior — Executes npm publish programmatically

[sev 4] child_process — Shell command execution during install

[sev 4] bun_runtime_evasion — Bun.spawn, Bun.file API usage

Amplifiers:

[sev 5] worm_propagation — Steals credentials AND self-publishes (CRITICAL)

[sev 5] secret_theft — CI secret access + network exfiltration (CRITICAL)

[sev 5] install_download_exec — Install script with network access

[sev 5] bun_evasion_attack — Bun APIs used for sandbox evasion (CRITICAL)

The PR comment would display: BLOCK: Critical supply chain threat detected.

The critical: true flag on worm_propagation alone is enough to floor the score at 100. Even if the base detector scores somehow summed to less than the block threshold, the critical flag overrides numeric scoring. The scoring engine enforces this:

const hasCritical = findings.some((f) => f.critical === true);
if (hasCritical) {
  raw = Math.max(raw, 100);
}

There is no configuration that overrides a critical finding. The PR is blocked.

The Key Insight

Shai-Hulud was not sophisticated. It didn't use novel exploitation techniques. It didn't chain zero-days in the Node.js runtime. It was a preinstall script that read tokens, made HTTP calls, and ran npm publish. These are ordinary operations — but they are ordinary operations that a color utility package should never perform.

CVE-based tools ask: "Is this package version in our vulnerability database?"

Behavioral analysis asks: "Why is a CSS helper reading ~/.npmrc and posting to the GitHub API during installation?"

That difference is why Dependency Guardian would have blocked Shai-Hulud on the first infected package, before the worm had a second host to spread to. No CVE required. No advisory needed. Just 26 detectors asking what the code actually does, and a correlator that recognizes when the answers form an attack pattern.

The npm ecosystem will see more worms. The question is whether your CI pipeline asks the right questions before npm install finishes running.

Dependency Guardian is free for up to 200 scans/month. Add it to your CI pipeline in 5 minutes: https://westbayberry.com/docs