Two of the most-used platforms in the open-source ecosystem—GitHub and PyPI—have rolled out new policies designed to close well-known windows in the software supply chain. The changes are surgical rather than sweeping, but they address real attack vectors that have been exploited in the wild.
GitHub Dependabot Gets a Three-Day Cooldown
GitHub is adding a configurable three-day waiting period before Dependabot opens a pull request for a newly published package version. The window applies only to non-security version bumps; critical security updates are unaffected and continue to flow immediately.
The rationale is straightforward: when a malicious package version is published, it can take hours or days before security researchers, automated scanners, or the original maintainer detect and yank it. A brief cooldown gives the community time to respond before Dependabot starts proposing that downstream repositories adopt the bad version.
"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." — GitHub
The cooldown is configurable via dependabot.yml, so teams that need immediate updates for non-security reasons can opt out. For most projects, however, the default delay represents a meaningful reduction in exposure to short-lived poisoning attempts without adding meaningful friction to the update workflow.
PyPI Blocks Late File Uploads
PyPI is introducing a rule that blocks new file uploads to any release that is older than 14 days. This targets a specific and underappreciated attack path: an attacker who compromises a maintainer's publishing token or CI workflow can silently add a malicious wheel or sdist to an already-published stable release—one that users have been safely downloading for months or years.
PyPI's own data shows the blast radius of this change is small: only 56 of the top 15,000 packages actually publish files to older releases outside the 14-day window under normal circumstances. For the handful of maintainers with legitimate reasons to do so, adjustments will be needed before the policy takes full effect. PyPI will wait until the Upload 2.0 API and Staged Previews defined in PEP 694 are standardized before enforcing the rule broadly.
The restriction prevents attackers from "poisoning old and long-stable releases" if publishing tokens or workflows become compromised. — PyPI
Why This Matters
Supply chain attacks have become a primary vector for both opportunistic and nation-state-sponsored intrusions. Campaigns like SolarWinds, XZ Utils, and numerous PyPI/npm typosquatting incidents have demonstrated how a single compromised package can reach thousands of downstream organizations. Historically, both GitHub and PyPI have relied on after-the-fact detection and removal; these new policies add proactive friction that makes the "publish malicious version, hope no one notices in time" play meaningfully harder.
Neither change requires action from most developers. Consumers of open-source packages benefit automatically. Publishers who add files to older releases will need to review their release processes before the PyPI enforcement date is announced.
What to Watch
- The PyPI Upload 2.0 standardization timeline under PEP 694
- Whether npm follows with analogous policies (similar discussions are ongoing)
- How quickly threat actors adapt to work within the new cooldown windows
- Downstream impact reporting once Dependabot delays are broadly enabled
These are incremental hardening steps, not silver bullets—but hardening the defaults is exactly the kind of systemic improvement the open-source ecosystem has needed for years.