Supply Chain Security's Newest Control Is a Calendar

The most effective new supply-chain defense of 2026 isn't a scanner, a signature database, or an AI triage bot. It's a calendar. Within eight days of each other this month, GitHub made a three-day cooldown the default for Dependabot version updates, and PyPI started rejecting new files uploaded to any release older than 14 days. Neither change detects anything. Both work anyway, because the economics of registry malware have a very short half-life.

What actually shipped

On July 14, GitHub flipped Dependabot's cooldown option — configurable since mid-2025 but off by default — to a three-day wait for every supported ecosystem on github.com, with GitHub Enterprise Server following in 3.23. Dependabot now sits on a new release for 72 hours before opening a version-bump PR. Security updates are exempt and still fire immediately, and you can tune or kill the delay in .github/dependabot.yml:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3
      semver-major-days: 14

Eight days later, PyPI announced that releases now reject new files after 14 days. Once a release has been up for two weeks, nobody — including the legitimate maintainer — can attach another wheel or sdist to it. That kills "release poisoning": an attacker with a stolen publishing token quietly adding a malicious platform-specific wheel to a two-year-old, universally trusted version, where no diff, no version bump, and no Dependabot PR would ever surface it.

Why waiting works

GitHub's own numbers make the case better than any pitch deck. The Advisory Database logged more than 6,500 npm malware advisories in the year ending May 2026 — roughly 18 malicious packages a day. But in GitHub's review of 21 high-profile incidents from 2018 to 2026, the poisoned versions of axios, ua-parser-js, Solana's web3.js, and Ledger Connect Kit were each yanked within hours of publication. The September 2025 chalk/debug compromise — packages with over two billion weekly downloads — was live for about two hours.

That's the whole insight: registry malware is detected fast, because registries, security vendors, and thousands of paranoid engineers are all watching the firehose. What kills you is being the project that auto-merged the bad version in hour one. A three-day cooldown doesn't find malware; it lets everyone else find it for you, then quietly skips the version that no longer exists.

The two changes attack different layers, though, and it's worth keeping them straight. Dependabot's cooldown is a consumer-side delay — it changes when you adopt new code. PyPI's rule is registry-side immutability — it changes what an attacker can do with a compromised token. Interestingly, PyPI's Seth Larson says there's no confirmed case of release poisoning in the wild; the change was reprioritized after the LiteLLM and Telnyx compromises earlier this year showed how plausible it was. PyPI closed the door before anyone walked through it, and the impact analysis says almost nobody will notice: of the top 15,000 packages, only 56 had ever added a Python 3.14 wheel to a release more than 14 days old. If you backfill wheels for new Python versions, you now cut a fresh release instead. That's the entire cost.

The ecosystem was already converging here

None of this is a GitHub invention. Renovate has offered minimumReleaseAge (née stabilityDays) for years. pnpm shipped its own minimumReleaseAge setting in 10.16 last September — in the direct aftermath of the chalk/debug and Shai-Hulud campaigns — and pnpm 11 now defaults it to 24 hours. What changed this month is that cooldowns stopped being a power-user flag and became the default posture of the largest dependency-update bot and the second-largest package registry. Defaults are the story. A feature protects the people who read changelogs; a default protects the other 95%.

Where the calendar doesn't save you

Two honest caveats before you file this under "solved."

First, Dependabot's cooldown only governs Dependabot PRs. npm install some-new-package in a dev's terminal, a CI job resolving a floating range without a committed lockfile, a npx invocation — all still pull the newest version the second it's published. If you want the delay at the install layer, you need your package manager to enforce it (pnpm's minimumReleaseAge does; for npm and yarn you're still mostly relying on lockfile discipline). The cooldown narrows the biggest automated pipe; it doesn't touch the manual ones.

Second, there's a free-rider problem baked into the model. Cooldowns work because someone is running day-zero versions and tripping the alarms. Today that someone is mostly registry-side scanning and security vendors, which is why the detection window is hours, not weeks. But if the entire ecosystem shifts right by three days, attackers adapt — either by getting patient (publish, wait out the cooldown quietly, then trigger) or by targeting the channels cooldowns don't cover, like install scripts on fresh direct installs. Time-based defenses raise the cost; they don't change the game.

The verdict

This is a genuine shift, not security theater — a rare case where the cheap, boring control is also the right one. The practical move for most teams: leave Dependabot's default alone (or stretch majors to a couple of weeks), set minimumReleaseAge if you're on pnpm or Renovate, and treat PyPI's change as free. Then remember what the calendar can't do, and keep the lockfiles committed, the CI tokens scoped, and --ignore-scripts on in automation. Waiting three days is the easiest security win you'll get this year. It's just not the last one you'll need.