Table of Contents
TL;DR – Key Takeaways
- Dependabot now defaults to waiting three days before opening pull requests for routine version updates, giving maintainers and scanners more time to detect malicious releases.
- PyPI blocks the addition of new files to releases older than 14 days, reducing the risk of attackers tampering with trusted package versions.
- The changes recognize that rapid automated rollout has become part of the attack surface for the software supply chain.
- Cooldowns help, but teams still need lock files, tightly capped tokens, human review, and secure CI/CD practices.
GitHub and the Python Package Index (PyPI) have just added a new layer of defense against supply chain attacks that doesn’t involve scanning code or blocking uploads entirely. It’s about waiting.
GitHub’s Dependabot now applies a three-day cooldown by default before opening a pull request for a routine version update. PyPI, on the other hand, no longer accepts new files uploaded to a version that is older than 14 days. Neither change prevents a malicious actor from publishing malicious code in the first place. Both are intended to reduce the time window in which code can sneak into production systems before anyone notices.
The reason for both steps is simple. A newly released package version often enters build pipelines within minutes of going live, long before a person or scanner has had time to review it. Security tools are usually quick to flag suspects. But marking is not the same as repairing. A maintainer still needs to pull the broken version, and until that happens, anyone updating on the old schedule is at risk. A cooldown gives back some of the lost time. By waiting a few days to roll out a new version, GitHub gives maintainers, researchers, and automated scanners the opportunity to detect and remove a malicious version before it ever ends up in a pull request.
GitHub chose three days as the default after balancing two competing needs: to keep teams updated on their dependencies without suspending them on releases that couldn’t yet be verified. Teams that want a shorter or longer delay can still configure this themselves via Dependabot’s cooldown settings – the default setting only changes what happens for anyone who doesn’t.
The change to PyPI addresses an associated but different risk. Instead of protecting against a brand new malicious package, it closes off an avenue attackers could use to manipulate a version that has already been trusted and in use for weeks. Once a release exceeds the 14 day mark, PyPI simply stops accepting new files added. This protects against a scenario where an attacker gains access to a compromised publishing token or workflow and secretly injects malicious code into an old, stable version rather than releasing something new and noticeable. PyPI said it had no knowledge of this technique being used in a real attack – the restriction is preventive in nature, closing a door before someone tries to pass through it.
The data behind this decision is worth noting. When the PyPI team checked how often projects legitimately published new files in old versions, the number was small even in edge cases: only a tiny fraction of the platform’s most popular packages had added a Python 3.14-compatible build more than two weeks after the original version was released. This gave the Python Software Foundation enough confidence that the restriction would not disrupt the normal workflows of most maintainers.
Neither change occurred in isolation. Both platforms have responded to a steady stream of high-profile incidents over the past year – compromises involving widely used npm packages, the S1ngularity campaign, the Shai Hulud worm, and the GhostAction attack on PyPI release data. GitHub had already announced changes to NPM security last month, and this cooldown builds directly on those efforts.
“Elapsed time now determines when an automated update reaches a pull request and how long a published version remains open to new files,” said Mitch Ashley, VP and practice lead, Software Lifecycle Engineering and AI-native Software Engineering at The Futurum Group.
None of this replaces the basics, and GitHub has been open about this. A cooldown does little to combat an attack that lasts for months rather than days – the kind where an attacker spends time gaining the trust of a handler before sneaking in something harmful. GitHub still recommends combining cooldown with lock files for dependency pinning, narrow access tokens, and disabling installation scripts that are not strictly needed in CI pipelines. Time helps. It is not a substitute for judgment.
Ashley pointed out that the cooldown doesn’t apply equally everywhere. “Dependabot’s cooldown only covers version updates,” he said. “Security updates will continue to be opened immediately, so the fastest automated path into a build pipeline remains unchanged. Teams performing unattended merges should confirm which path the new standard has actually closed.”
For DevOps and platform engineering teams, the concrete numbers are less important than the change in attitude they represent. Package registries have long been optimized for speed – release the latest version, adopt it, and move on. These changes are a tacit admission that speed itself has become part of the attack surface. Teams that rely heavily on automated dependency bots without a human review step now receive a small, built-in buffer by default. Teams already pinning dependencies to commit hashes or run their own internal package mirrors already had a version of this protection in place; Now it will become the standard at the platform level for everyone else.
It’s a modest change with an outsized rationale. When it comes to software supply chain security, the first few days after release are often the most dangerous. Giving the window a little more room to close may be one of the simplest and most cost-effective defense measures currently available.
Frequently asked questions
Why is GitHub delaying Dependabot updates?
The three-day cooldown period gives maintainers, researchers, and security tools more time to identify and remove malicious package releases before they enter development pipelines.
Why would attackers target an older version?
An attacker with stolen release data could add a malicious file to a trusted, established version, potentially avoiding the attention that comes with releasing a new version.
Are these changes enough to prevent supply chain attacks?
No. They reduce exposure in the most dangerous early days of a release, but should be combined with dependency pinning, lock files, limited permissions, secure release credentials, and human review.
https://devops.com/github-and-pypi-bet-on-time-to-slow-down-software-supply-chain-attacks/
