ChainStrip

• Miasma & Hades wave Jun 2026

  A week-long run of Shai-Hulud-descended waves — ~448 malicious npm and PyPI artifacts, zero CVEs. It poisoned 32 @redhat-cloud-services packages (~117K weekly downloads), a broad npm batch including @vapi-ai/server-sdk, then backdoored Microsoft GitHub repos — GitHub auto-disabled 73 of them in under two minutes. The payload ran from a preinstall script (one wave hid it in binding.gyp to dodge install-script scanners), dropping an obfuscated credential stealer aimed at CI and developer machines.

  ChainStripChainStrip's release artifacts are unpacked into node_modules, never npm install-ed — so nothing fires at install time: not a lifecycle script, and not a native build from a binding.gyp, the trick that wave used to slip past scanners that only grep for install-script fields. And the build consumes a hash-pinned, gated artifact, so the drifted patch releases that delivered every wave never resolve into it to begin with.

  The payload never runs: nothing executes at install time, and the poisoned releases never resolve into the build.

• IronWorm May–Jun 2026

  JFrog's "rustier cousin" of Shai-Hulud: ~37 packages in the Arweave/WeaveDB ecosystem, republished from one stolen maintainer account and cleaned within a day. A preinstall hook launched a 976 KB native Rust binary — hidden in a tools/setup directory, never imported — carrying an eBPF rootkit and Tor C2 to steal environment variables, cloud and AI-tool keys, and crypto-wallet seeds. It self-propagated by backdating commits and republishing through stolen credentials.

  ChainStripThe binary sits in a directory nothing imports, so additive extraction never pulls it into the artifact; the preinstall hook that launches it is stripped; and pinning blocks the minor-version bumps it spread through.

  Blocked three ways — not shipped, not run at install, not pulled in by a pin.

• node-ipc May 2026

  Distinct from the 2022 protestware of the same name: on May 14, 2026 an attacker re-registered the lapsed domain behind the maintainer's email, took the account, and published three versions of node-ipc (~10M weekly downloads). An 80 KB obfuscated payload appended to node-ipc.cjs fired on every require("node-ipc") — no install script — harvesting 90+ categories of cloud, CI and SSH secrets; one version was hash-gated to a single targeted entry point.

  ChainStripChainStrip can't strip this one — code that runs on require of a package you use is part of your retained surface. But the poisoned versions never resolve into a pinned artifact, and evaluating the bump flags it retained-surface-changed: an 80 KB obfuscated blob appended to node-ipc.cjs is a glaring diff on a module you call, forcing review instead of a blind upgrade.

  Not removable, still stopped: the bump lands in review instead of shipping blind.

• axios Mar 2026

  The maintainer account behind axios (~70M+ weekly downloads) was compromised and two patch versions published, live about three hours. The malware was not in axios at all: a phantom dependency, plain-crypto-js, that axios never imports — its postinstall dropped a cross-platform RAT, then deleted itself. Patch bumps over the safe versions meant ^/~ ranges resolved straight to the poisoned build.

  ChainStripA dependency axios never imports is outside its used closure, so extraction leaves it on the floor — and even installed, its postinstall is stripped and the drifted version never resolves against a pinned artifact.

  The RAT's package was never in the used closure and never on the install path. There is nothing to ship.

A scanner scans the dependencies, returns the list of vulnerabilities and washes hands, it’s your business now. Reachability tool goes further, it runs the static analysis and guesses the outcome. ChainStrip goes much deeper: it actively removes dead code, proves that removal is safe using your build and test suite and stands guard on every update to prevent the dead code and vulnerabilities from sneaking back. It doesn’t do penetration testing, doesn’t replay the attack.

Once ChainStrip has analyzed and rewritten your tree every CVE gets one of four verdicts, sorted by "strength", a measure of how much evidence caused each one. eliminated is the strongest, it means "total kill": the CVE was found, but the static and dynamic analyses proved that it could be removed from the code completely and it's gone. The proof is the green test suite and production build. The case study elimination from the top of the page is dissected below.

Two eliminations, and the seven still held

Won't this break my app?

The suite is no longer the ceiling

Every hold is one piece of missing evidence away from a removal, and the ceiling moves from both sides: coverage --prompt names the exact suite tests that would raise it, and ChainStrip gathers execution evidence from three places the suite can't reach — probes it generates to make your app run unproven code, an end-to-end pass against the served production build, and browser-side coverage (all below). Held code graduates to removed as the evidence lands.

"Eliminated" means removed from your artifact and proven by your gate; it does not mean "verified safe in production." The closest thing to that claim is an opt-in counter compiled into the shipped artifact that records, locally in your own infrastructure, whether production ever tried to call a removed function.

Dependency changes become classified diffs your CI can block

Run `chainstrip update` with no arguments and it becomes a PR gate: it classifies every dependency change in the diff — version bumps, brand-new dependencies, and new call-paths your code opens into existing ones — by building and validating a candidate artifact and diffing the retained surface, a diff small enough for a human to actually review. Blocking is policy-driven: an in-policy finding sets a non-zero exit so CI fails the check, and a reviewer waives it with a committed, fingerprint-bound approval that re-blocks the moment that dependency changes again. Compare that to the usual blind N-day version hold: instead of waiting and hoping, you learn in about an hour (measured on Cal.diy's ~230 runtime dependencies) whether the release added a capability or changed code you run — and that cost is paid only on PRs that change dependencies or usage; every other PR stays the one-second fingerprint check. Capability changes are caught from two directions. The new code is scanned for gained capability markers (network, spawn, filesystem writes, environment and secret reads), so a dormant payload is flagged without ever firing. And during validation, a runtime layer instruments the actual built-in surface and attributes every filesystem, network, DNS, and child-process call to the dependency that made it. Obfuscation is handled as its own signal: packing can hide what code does, but it can't hide that the code is packed, and a bump that puts packed code onto a path you run is a blockable finding in itself. The flag points a reviewer at hidden code you execute; it does not pronounce malware.

Removal is possible because ChainStrip rebuilds your dependency tree from evidence of what your app runs, one validation-gated decision at a time.

1. Inventory dependencies and app usage

   Scan project source for import sites; union with what other installed packages import from each shared dependency. The result is a usage fingerprint per package.

2. Extract dependency source into a controlled workspace

   Your checkout is never modified. Validation runs in disposable copy-on-write clones; extraction emits vendored packages with licenses, notices, and per-file provenance preserved. Extraction is dual-engine: rollup by default (measured 48.9% fewer emitted bytes than esbuild on a six-dependency comparison set, 2026-06-10), with a per-dependency esbuild fallback for the cases where rollup would drop a named export.

3. Remove the provably dead, hold the rest

   Each dependency lands in exactly one tier. Tier A — statically clean: bundle additively from your real import sites; tree shaking removes dead branches for free. Tier B — contained dynamism: subtractive, validation-gated file and function pruning. Tier C — frameworks, native modules, heavy dynamism: retained whole, lifecycle-stripped, hash-pinned, and update-gated. One disposition rules every tier: a function is removed only with lexical proof of death, and reachable-but-unexecuted code is held, because a missing test is not proof. Three precision passes keep the held set small without touching that bar: build-executed dependencies are held per function the toolchain actually runs rather than whole, a class method counts as reachable only where a caller names it (dynamic dispatch degrades to held), and identifiers resolve by exact lexical scope. On Cal.diy the precision work tripled proven-dead removals, from 5 dependencies to 16, with zero change to the guarantee.

4. Validate against the target project's test suite

   Differential: baseline vs overlay, your full suite plus a production build run from scratch — no build cache, no cached replay, so a dependency that only builds because a stale cache remembers it can't slip through. Beyond pass/fail, an export-shape oracle proves every subpath still exports what your code reaches, the class of silent bundling breakage a green suite misses. A hardened dependency is accepted only at zero new failures; one that passes tests but breaks the build auto-demotes to a pruned-but-complete copy. A failed extraction demotes, it never blocks the run.

5. Publish reports and reusable hardened artifacts

   Validated packages are packed into per-dependency tarballs keyed by content fingerprint. The store is a plain directory in ChainStrip's state (.chainstrip under your repo by default; relocatable by config), so it travels through your normal CI cache; on Cal.diy it weighs about 124 MB. That state stays out of version control — the only ChainStrip files your repo tracks are the config and any committed waiver approvals. Builds consume artifacts; reports record every decision and the evidence behind it.

Evidence

The numbers below are from measured runs on our biggest testbed, Cal.diy (the Cal.com OSS release, a production monorepo), each recorded in a dated run report. The CVE verdicts, the proven-dead counts, and the surface-reduction bars all come from one full run of 2026-07-31; the bars cover the 152 dependencies whose extractions passed validation in it. The deploy side has its own measured strip: a burn-in of 2026-07-17 applied the artifact, ran the production build, then removed development-only build twins and non-runtime files (type declarations, source maps, docs; licenses always kept) — the served `node_modules` went from 3.3 GB to 2.0 GB with build, boot, and login e2e green, and zero strip-induced regressions. Your numbers depend on how much of each package you actually use.

$ chainstrip reachability

advisories     189 in the installed tree (OSV 2026-07-31)
  not shipped  103   never entered the artifact
  eliminated     1   glob HIGH: bin.mjs pruned, gates passed
  reached       48   16 HIGH · 26 MODERATE · 6 LOW
  unresolved    37   too coarse to map to a symbol

proven dead    removals in 18 advisory-carrying deps;
               glob's reached the advisory itself
validation     full suite: differential pass
               production build: from-scratch pass

$ chainstrip exceptions

[no-test-evidence]  cron-parser · 312 KB at stake
  No test imports this package, so test evidence
  is unavailable for it.
  do now     add one test that imports it — the next
             sweep promotes it to full test evidence
  meanwhile  production-build gate + update gate
             still cover it

[build-gate]  glob · overlay rejected
  Production build failed: require condition
  resolved as ESM (error persisted verbatim below).
  do now     nothing — auto-demoted, stock copy
             pinned and update-gated
  meanwhile  regression pinned; retried next sweep

You do not run a full scan on every commit. The from-zero run behind the hero (start-ui-web, 67 dependencies) took 24 minutes on one machine; the one behind Cal.diy's numbers (232 runtime dependencies) took 70. After that, pruning runs when its inputs change; everything else is a fingerprint comparison.

$ chainstrip score --dir .

$ chainstrip drift
$ chainstrip pack --check

$ chainstrip sweep --tier AB
$ chainstrip reachability

$ chainstrip apply --dest .
$ chainstrip bundle --production

Start with a cold score and stop wherever your risk tolerance is met; each mode is useful on its own.

$ chainstrip score --dir .
$ chainstrip report

$ chainstrip reachability --gaps
$ chainstrip update

$ chainstrip apply --dest .
$ chainstrip bundle --production

How it ships

ChainStrip is self-hosted: a runnable bundle for x86 and arm64 that lives where your code lives; if Node runs there, ChainStrip runs there. Your source, lockfiles, and reports stay in your infrastructure. (The lockfile ask in the demo box above is for the demo itself; the product never sends anything out.) Onboarding is white glove: we integrate ChainStrip into your GitHub or GitLab CI/CD pipeline ourselves, free of charge. chainbot, the robot user, ships in the same bundle as an optional component and isn't priced separately. Licensing is commercial, with source available to customers. It isn't open source today for a plain organizational reason: a healthy OSS project takes maintenance resources we are putting into the tool instead. Pricing isn't public yet; ask in the demo.