The Clock Is Ticking — But Only for Attackers
Two of the most critical pillars of the open source ecosystem just tightened their defenses. GitHub and the Python Package Index (PyPI) have each introduced policy changes aimed squarely at one of the most insidious attack vectors in modern software development: the rapid spread of poisoned packages.
The moves are separate, but the logic is the same. Give the good guys a head start. Make it harder for bad code to slip into production before anyone notices.
Dependabot Now Waits Three Days Before Bumping Dependencies
GitHub’s Dependabot, the automated tool that keeps your project’s dependencies up to date, will now cool its jets for 72 hours after a new release before opening a pull request. The idea is simple: attackers often publish malicious versions and rely on automated tools to pull them immediately into thousands of projects. A three-day buffer gives maintainers, security researchers, and automated scanners a window to spot the poison and get the release yanked.
GitHub’s own documentation frames it bluntly: “Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests.”
Only Non-Security Bumps Are Affected
That three-day cooldown doesn’t apply to everything. Security-related version bumps — patches for known vulnerabilities — bypass the delay entirely. You can also override the default by tweaking the configuration in your dependabot.yml file. GitHub says three days was chosen as a balance point: long enough to catch the bulk of supply chain attacks, short enough to avoid holding back legitimate updates unnecessarily.
PyPI Locks the Door on Old Releases
Over at PyPI, the threat model is different but equally dangerous. An attacker who compromises a maintainer’s publishing token or CI/CD workflow could upload a malicious file to an old, trusted release — one that thousands of projects have depended on for years without a second thought. PyPI’s new policy shuts that down by rejecting file uploads to any release older than 14 days.
PyPI’s team acknowledged that, as far as they can tell, no one has actually exploited this vector yet. But the vulnerability was real. “There is no technical reason beyond that attackers weren’t aware it was possible,” they noted. That’s a chilling admission.
Minimal Impact on Legitimate Workflows
The change won’t be enforced until the ‘Upload 2.0 API’ and ‘Staged Previews’ are standardized under PEP 694. But early testing suggests the disruption to normal publishing practices will be tiny. PyPI reports that out of the top 15,000 packages, only 56 had published a Python 3.14-compatible wheel more than 14 days after the original release. That’s a fraction of a percent.
Beyond protecting users, the policy simplifies cleanup after a potential breach. If all files on a release are from the same timeframe, it’s far easier to tell which ones are legitimate and which are compromised.
What This Means for Developers and Security Teams
If you’re running Dependabot, you’ll likely see a small delay on non-critical dependency updates. That’s fine. If you’re a package maintainer on PyPI, the 14-day upload window means you need to be more deliberate about tagging releases. Both changes are designed to make the kind of supply chain attacks that have plagued open source — from North Korean hacker campaigns to NPM package poisoning — significantly harder to pull off at scale.
The broader lesson is that platform-level security can’t just be about scanning code. It has to be about changing the economics of an attack. Make it slower. Make it riskier. Make it easier to detect. That’s exactly what these two policy shifts do.
