Supply Chain Security's Newest Control Is a Calendar

GitHub made a three-day cooldown the default for Dependabot version updates on July 14, and PyPI began rejecting new files uploaded to releases older than 14 days on July 22, betting that patience beats scanners in supply-chain security. The changes exploit the short half-life of registry malware, which is typically detected and yanked within hours, as seen in incidents like the September 2025 chalk/debug compromise that was live for about two hours. GitHub's Advisory Database logged over 6,500 npm malware advisories in the year ending May 2026, roughly 18 malicious packages per day.

Security https://sourcefeed.dev/c/security Article Supply Chain Security's Newest Control Is a Calendar Dependabot's three-day default cooldown and PyPI's 14-day release freeze bet that patience beats scanners. Emeka Okafor https://sourcefeed.dev/u/emeka okafor 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 https://docs.github.com/en/code-security/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 https://pypi.org 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 https://docs.renovatebot.com has offered minimumReleaseAge née stabilityDays for years. pnpm https://pnpm.io 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. Sources & further reading - GitHub, PyPI add time-based defenses against supply chain attacks https://www.bleepingcomputer.com/news/security/github-pypi-add-time-absed-defenses-against-supply-chain-attacks/ — bleepingcomputer.com - The case for a cooldown: Why Dependabot now waits before issuing version updates https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/ — github.blog - Dependabot version updates introduce default package cooldown https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/ — github.blog - Releases now reject new files after 14 days https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/ — blog.pypi.org - PyPI now rejects new files after 14 days https://lwn.net/Articles/1084218/ — lwn.net Emeka Okafor https://sourcefeed.dev/u/emeka okafor · Security Editor Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read. Discussion 0 No comments yet Be the first to weigh in.