Patch Fast, But Let It Bake: Why Package Cooldowns Now Matter More Than Speed

Greg Heffner June 21st, 2026

In March 2026 the first machine hit by a backdoored release of axios, a package with more than a hundred million weekly downloads, was infected about 89 seconds after the malicious version went live. Not minutes. Seconds. Nobody there failed to patch fast enough. They got hit precisely because they pulled the newest version the moment it shipped.

For most of my career the rule was simple and it was right: patch fast and patch often. The danger lived in old, unpatched code. The longer a known bug sat in your stack, the longer an attacker had a free door. So we automated updates, we shrank our patch windows, and we measured ourselves on how quickly we could pull the newest version.

That instinct is now half wrong, and the half thats wrong can get you breached. Package-repository poisoning has quietly inverted the threat model. In a growing share of attacks the most dangerous code in your supply chain isnt the old version you havent patched yet. Its the brand new version youre about to pull, because a freshly compromised release is the least-vetted code on the registry. The fix isnt to patch slower. Its to stop treating every update as the same kind of update.

The threat model flipped

The volume tells the story. Using one vendor's consistent methodology, Sonatype logged 245,032 malicious open-source packages in 2023, then reported a 156% year-over-year surge to roughly 704,000 cumulative by October 2024. Through 2025 it kept climbing, and the year ended with a 476% jump in the fourth quarter alone, nearly all of it on npm, as attackers automated package publishing faster than the ecosystem could weed it out. Cumulative malicious packages tracked since 2019 are now well past a million.

These are not typos in a corner of the registry. The targets are the packages everyone depends on, and the delivery method has shifted from "publish a fake package and hope" to "take over a real, trusted one and ship malware to its existing millions of installs." When the attack rides an account you already trust, "it is the newest version of a package I already use" stops being reassuring.

The attacks that prove it

A few recent incidents make the pattern concrete:

• xz-utils (CVE-2024-3094), March 2024. A maintainer persona spent roughly two to three years building trust on a small but critical compression library, earned release rights, and then hid a pre-auth SSH backdoor in obfuscated test files inside the release tarballs. It was caught almost by accident, when a Microsoft engineer chased down a half-second SSH login delay. The Akamai writeup is the clearest summary. This is the long-game attack, and it is the one a cooldown does not solve. Hold that thought.
• chalk and debug, September 2025. A prolific npm author got phished with a convincing fake npm domain, and the attacker pushed crypto-stealing versions of around eighteen packages whose combined reach is more than two billion weekly downloads. The payload was a browser clipboard hijacker that swapped wallet addresses in flight.
• Shai-Hulud, September and November 2025. First a self-propagating npm worm that stole tokens and spread to hundreds of packages within a day, then a second wave that backdoored nearly 800 packages across more than a thousand versions and littered GitHub with thousands of malicious repositories. A worm in your dependency graph is the purest argument against auto-pulling the latest tag the moment it appears.
• axios, March 2026. An attacker used a stolen token to manually publish a backdoored release of a package with more than a hundred million weekly downloads. The Huntress timeline is the detail that should change how you think: the first victim was infected about 89 seconds after the malicious version went live.

Why "patch fast" still backfires

Let me be fair to the old doctrine, because it is not dead. Speed genuinely matters for known bugs. Mandiant has tracked the average time-to-exploit collapsing from 63 days in 2018 and 2019 to about 5 days in 2023. CISA's own data on its Known Exploited Vulnerabilities catalog is starker: a large share of those bugs are exploited on the day they go public, and most within a month. If a vulnerability is being actively exploited in the wild, every hour you wait is a gift to the attacker. For that category, patch yesterday.

But here is the trap. The same automation that lets you patch a known bug in hours is exactly what pulls a freshly poisoned package into thousands of builds before anyone notices. And the timing data cuts the other way once you separate the two cases. The detection window for malicious packages is short, and it is on your side if you simply do not go first:

• In the axios case the package was live for only about three hours, and Socket flagged it within roughly six minutes of publication.
• StepSecurity reports that most malicious releases are discovered within the first 24 hours.
• Andrew Nesbitt's analysis in Package Managers Need to Cool Down found that eight of ten recent attacks had exploitation windows under a week, meaning a simple seven-day delay would have dodged most of them.

There is a structural reason this works. Language package managers like npm and PyPI let a single compromised maintainer account push straight to millions of downstream installs with no human review layer in between. System package managers like apt, Homebrew, and Fedora have maintainers and integration delays that act as a gate. The language registries traded that gate for speed, and we are now paying for it. And the cost is real: IBM's 2025 Cost of a Data Breach report put supply-chain compromise at 15% of breaches, averaging $4.91 million, and taking the longest of any vector to resolve at 267 days.

What the guidance actually says

What gets me is that the official guidance already contains both halves of the answer; they just live in different documents. On speed, CISA has only gotten more aggressive. Its Known Exploited Vulnerabilities program set a two-week clock for remediating actively-exploited bugs, and its newer guidance is shifting to risk-based timelines that push the most urgent cases faster still, explicitly because adversaries are using automation to shrink the patch-to-exploit window. For genuine known-exploited bugs, the government wants you faster than ever.

On what you ingest, a separate body of guidance quietly says "slow down and verify." NIST's Secure Software Development Framework leans on provenance and release integrity, and SLSA formalizes signed build provenance you can actually check. Even the 2026 White House budget guidance moved away from a blanket attestation mandate toward agency risk judgment. Read together, the message is not "go fast" or "go slow." It is this:

The fix is a cooldown, and the tooling already agrees

Through 2025 and into 2026 the ecosystem converged on the same idea from every direction: wait a few days before adopting a new version so the fast, noisy attacks burn out in someone else's logs. What convinced me this is the real consensus is that every one of these tools exempts security updates from the delay, which is the split-pipeline thesis shipped as a default:

• GitHub Dependabot added a cooldown in July 2025, configurable by how big the version bump is, and crucially it applies only to routine version updates while security updates bypass it entirely.
• Renovate has minimumReleaseAge (it recommends 14 days if you automerge), npm added min-release-age, and pnpm shipped its own minimum-age setting.
• StepSecurity ships a check that fails a pull request introducing any npm version less than 48 hours old.
• The npm registry's own 24-hour unpublish window is what makes short cooldowns effective: a bad version is frequently yanked inside the very window your cooldown is waiting out.
• None of this is new in spirit. Debian has migrated packages from unstable to testing only after a multi-day soak for years. We are reinventing the apt gate for the npm world.

The recommended durations cluster around a week. Datadog's writeup on dependency cooldowns notes that one week is the commonly cited number, and that even a 12-hour cooldown would have blocked the axios attack outright. I will give the honest counterpoint too: Sonatype argues that a delay is a weak proxy for trust and pushes behavioral analysis at install time instead. They are not wrong, and the answer is not either/or. A cooldown buys you time. Provenance verification is what you do with that time.

The whole pipeline the “bake” step lives in — built weekly, scanned, signed, digest-pinned, soaked, and pruned. Every box is a gate. (Logical diagram, not a network map.)

What this looks like in my homelab

Here is the part that made me want to write this. Most of the cooldown tooling above is aimed at the language supply chain, npm and PyPI. But the same logic applies one layer down, at the container base image, and a single operator can implement the whole pattern without buying anything. My little cluster that serves this very page already bakes its updates, and I did not set out to follow a standard. I just arrived at the same place the standards bodies did.

The pipeline rebuilds my nginx image weekly from the current stable base, runs a vulnerability scan, and then does three things that map cleanly onto everything above:

• It lets the image bake for 72 hours on a standby color. A freshly built image does not serve a single live request for three days. It runs on the idle half of a blue/green pair while the live half keeps serving. That is a hand-rolled minimumReleaseAge at the image layer, long enough to clear the window where most poison and most "oops, we yanked that" releases get caught.
• It signs every image at build time. Keyless cosign signatures give me the provenance layer that the SSDF and SLSA keep pointing at. The soak buys the time; the signature is what I check during it.
• It refuses to promote anything unsigned. An admission policy on the cluster rejects any image that is not signed by my own build pipeline, so "we sign our images" becomes "unsigned images physically cannot serve traffic." That is the consumption-time check, made non-optional.

It wasnt all smooth. The first time I switched the signing gate to hard-reject, I nearly locked myself out: the image already running in production predated signing, so a strict policy would have refused to let those pods restart. I had to build, sign, and roll forward onto a signed image first, then flip the gate to enforce. Order of operations matters, and I learned that one the boring way.

And the split-pipeline rule is baked in too. Routine base-image bumps take the full soak. But a genuine known-exploited bug in nginx or OpenSSL can be fast-tracked through the same machinery without waiting three days, exactly the way Dependabot lets security updates skip the cooldown. Fast lane and slow lane, same road.

Final thoughts

I want to be careful not to oversell this. A 72-hour soak plus signing plus admission control is not a silver bullet, and it would not have stopped xz. A patient adversary who spends two years earning commit rights and ships a clean-looking release will sail through any cooldown, because the poison was never "new" in a way a timer can see. That class of attack needs different defenses entirely.

What a cooldown does is beat the attacks that actually dominate the data: the fast, loud, account-compromise smash-and-grabs that are live for hours, get caught within a day, and depend entirely on you pulling the newest version before anyone has looked at it. For those, time is the cheapest control you have, and you mostly get it by not going first.

So Im not telling you to stop patching fast. Im telling you to ask one question before each update: is this a fire, or is this a routine bump? If its a known-exploited fire, move now. If its everything else, let it bake. The reflex that kept us safe for twenty years was never really about speed. It was about exposure. And in 2026, the lowest-exposure move is often the patient one.