colors.js had a trusted maintainer.
That was the problem.

Nothing was hacked

On January 8, 2022, npm served versions 1.4.1 and 1.4.2 of colors — a terminal-string library with roughly 27 million weekly downloads and about 19,000 dependent packages — and every application that pulled it began printing LIBERTY LIBERTY LIBERTY, then garbage, forever.

The payload was three lines. A loop — for (let i = 666; i < Infinity; i++) — inserted by the package's own maintainer, published with his own credentials, in protest of years of unpaid maintenance. faker, his other library, was gutted the same week. Thousands of builds broke overnight, including tooling at companies with nine-figure security budgets.

Here is the part worth sitting with: no security control failed. No account was compromised, no token stolen, no build server breached. The registry did exactly what a registry does — it handed you bytes, and a name to trust. The name was valid. The trust was the vulnerability.

We spent four years hardening the pipe

The industry's response to 2022 was real and well-executed. npm mandated 2FA for high-impact maintainers. Sigstore-signed provenance let packages prove which repo and CI workflow built them, and trusted publishing made it nearly automatic. SLSA gave us build-integrity levels. Google's OSS Rebuild independently rebuilds packages and attests that the artifact matches the source. Package managers added release cooldowns.

Every one of these answers a pipeline question. None answers the payload question:

The sabotage was the source. A malicious commit from a legitimate maintainer rebuilds perfectly, signs cleanly, and ships with flawless provenance. And the record since proves the point: the Shai-Hulud worm hit hundreds of packages in September 2025 after the 2FA mandate — then returned in November, and again in the spring. The axios compromise in March 2026 shipped a remote-access trojan to a library with 70 million weekly downloads. The LiteLLM backdoor arrived through a compromised security scanner. Roughly one major registry incident a month, for the last ten months, against the most hardened pipeline in the ecosystem's history.

Ship the contract, not the bytes

A rederive package ships its contract: a structural spec, plus a held-out oracle — worked input→output vectors stamped by executing the original code, which the shipped implementation has never seen. The oracle is published in full, hashes and all. It is an independent source of truth that no publisher — including us — can quietly move.

rdv check re-runs every unit's held-out oracle against the shipped source and verifies the recorded content hashes. It is deterministic, local, and free: no account, no network, no LLM, no trust in the vendor — you can audit the verifier itself; it's a few hundred lines of dependency-free Apache-2.0 code. Tamper with one byte and it fails two ways at once:

$ rdv check packages/colors        # after flipping one character in src/strip.js
  ✗ FAILED  strip
     held-out 5/10 miss=[ho_combined_sgr_leading,ho_csi_clear_screen,…]   hashes MISMATCH
  VERIFICATION FAILED — do not trust this src; rebuild with: rdv resynth packages/colors

The behavioral channel catches what changed; the hash channel catches that anything changed at all. A cosmetic, behavior-preserving edit passes every oracle vector — and still fails the hash. A subtle behavioral regression matches no known signature — and still misses the oracle.

And if verification fails — or you simply refuse to trust shipped bytes at all — rdv resynth rebuilds the implementation locally from the spec, with isolated workers accepted only on quorum, and the result must pass the very same rdv check. We don't ask you to trust the workers either. The oracle is the trust anchor. Not the publisher, not the registry, not us, and not any model.

What this doesn't prove — said plainly

A held-out oracle is evidence of behavior, not a proof of total correctness. Code can conform on every vector and differ on a path no vector exercises — which is exactly why check is dual-channel, why catalog packages are zero-dependency by construction, and why re-derivation requires quorum agreement from workers that never see each other's output. Smaller attack surface, honestly bounded — not magic.

The contract is honest about the code's limitations, too. Our first catalog package is @rederive/colors, a verified recompose of colors@1.4.0 — the last release before the sabotage. Its strip unit removes only single-parameter SGR codes; CSI and OSC terminal-injection escapes survive, and the oracle documents that. The original code has that limitation; the contract says so instead of papering over it. A trust primitive that flatters the code it verifies would be worthless.

Where this goes

The catalog stands at 218 verified, zero-dependency packages — three public in the repo today (colors, rdv, request), the rest rolling out — concentrated where the risk actually lives: the abandoned-but-load-bearing tail of npm that nobody audits and everybody ships. The SIR format is an open spec — we'd like nothing more than registry-native contracts to make our catalog redundant. Everything load-bearing is Apache-2.0, with a written charter of what we will never do to the community.

If you want to kick the tires, colors is small enough to audit in an afternoon — the whole contract, oracle vectors and all, is in the open:

$ npm i -g rederive
$ git clone https://github.com/rederive/rederive && cd rederive
$ rdv check packages/colors        → ✓ VERIFIED

Then flip a byte in src/strip.js and run it again.