GitHub and PyPI Add Waiting Periods to Slow Down Supply-Chain Attacks
Dependabot now waits three days before pulling in new package versions, and PyPI blocks file uploads to releases older than 14 days.

Key points
- GitHub's Dependabot, the tool that automatically updates software libraries, now waits 72 hours before pulling in a newly published version.
- PyPI, the main storage site for Python software packages, will refuse new file uploads to any release older than 14 days.
- Both changes are direct responses to a run of supply-chain attacks in 2024 and 2025, including the Shai-Hulud and GhostAction campaigns.
- Malicious packages are often spotted within minutes, but the window before they are pulled down is enough to poison downstream projects.
- Developers can still shorten or lengthen the Dependabot delay through its
cooldownsetting.
Two of the biggest homes for open-source code have added a simple but overdue defence: time.
GitHub and the Python Package Index, known as PyPI, both announced changes this week that force a pause between when a new software package appears online and when it can be pulled into other people's projects. The goal is to blunt supply-chain attacks, where criminals sneak malicious code into a legitimate library that thousands of other applications depend on.
First reported by BleepingComputer, the changes follow a bruising year for both ecosystems.
Why add a delay at all?
Because detection is fast, but cleanup is slow. Security researchers often flag a poisoned package within minutes of it going live. Getting it removed, and warning everyone who already downloaded it, takes far longer. In that gap, automated tools happily pull the malicious version into production code.
Recent examples make the point. The chalk and debug npm attacks, the s1ngularity operation, the Shai-Hulud worm, and the GhostAction campaign all relied on that short window between publication and removal.
What has Dependabot changed?
Dependabot is GitHub's automated helper. It reads a project's list of dependencies, spots when a newer version of a library is available, and opens a pull request, essentially a suggested code change, asking the maintainer to upgrade.
Starting now, Dependabot waits 72 hours before doing that for a newly published version. GitHub calls this a cooldown and says three days is a reasonable middle ground between security and staying current. Teams that want a shorter or longer wait can change the setting themselves.
GitHub was frank about the limits. A cooldown does nothing against attackers who play the long game and only activate malicious code weeks after publishing. For that, the company points to lockfiles (which pin dependencies to exact versions), tokens with narrow permissions, and turning off install scripts that are not needed during automated builds.
What has PyPI changed?
PyPI will now reject any new file uploaded to a package release that is more than 14 days old. This closes off a technique called release poisoning, where an attacker who steals a maintainer's publishing token quietly attaches malicious files to an old, trusted version that thousands of projects already rely on.
PyPI said its data showed that almost no legitimate project uploads new files to a release more than two weeks after it went out. No confirmed attack has used this exact trick on PyPI yet. The platform is closing the door before anyone walks through it.
The changes at a glance
| Platform | Measure | Window | Overridable? |
|---|---|---|---|
| GitHub Dependabot | Delay on new package updates | 72 hours | Yes, via cooldown config |
| PyPI | Block new files on old releases | 14 days | No |
What developers should do
If you maintain code that pulls from npm, PyPI or similar registries, the cooldown is a floor, not a ceiling. Pin your dependencies with a lockfile. Give your CI tokens the smallest possible scope. Turn off install-time scripts you do not actually need. And review Dependabot pull requests before merging them, rather than letting a bot auto-approve its own suggestions.
For ordinary users, there is nothing to do here. But the next time an app you rely on ships an update a few days late, this is part of the reason, and it is a good one.



