What happened
GitHub introduced a default three-day cooldown for Dependabot’s ordinary version-update pull requests. The delay does not apply to Dependabot security updates, which continue to open immediately when a known vulnerability requires a patched version. Repository owners can configure a different period in dependabot.yml.
GitHub’s stated objective is to avoid automatically proposing a package during the short interval after publication when malicious or compromised releases may not yet have been detected and removed. The company notes that a cooldown is only one layer and recommends lockfiles, restricted-scope tokens and disabling unnecessary installation scripts in continuous integration.
PyPI separately implemented a 14-day limit after which maintainers cannot add new files to an existing release. The measure is intended to prevent an attacker who compromises a publishing token or workflow from adding a malicious artefact to an old, trusted version. PyPI described the legitimate use of such late uploads as rare and did not claim that a known attack had already used this exact technique.
Why this matters now
Enterprise dependency automation has traditionally optimised for speed: detect a new version, open or merge a request and rebuild. That process can turn the first hours of a package compromise into a distribution advantage for the attacker. A short delay allows registry operators, researchers and scanners to intervene before routine updates reach production.
The distinction between version updates and security updates is essential. A blanket delay may protect against new-release poisoning but also postpone a patch for a publicly known vulnerability. The enterprise policy must classify the reason for the update rather than apply one timing rule to every package change.
The decision for security leaders
Direct platform engineering and application security to define default waiting periods based on application criticality, package risk and deployment environment. Internet-facing and privileged applications may require longer review for ordinary releases, while emergency security fixes need a tested expedited path.
Extend the review beyond GitHub-hosted repositories. Internal dependency mirrors, container rebuilders, Renovate or other bots, language-specific tooling and automated merge policies may bypass the ecosystem defaults. Ensure production builds use pinned versions and verifiable artefacts so a registry-side change cannot silently alter a previously approved release.
Evidence of closure
- Repository configuration showing the approved cooldown for ordinary version updates.
- Pipeline tests proving that security updates are not delayed by the routine-release policy.
- An inventory of automated dependency bots, internal mirrors and auto-merge rules covering critical applications.
- Lockfiles or equivalent integrity controls for production builds, with changes reviewed and reproducible artefacts retained.
The Security.io assessment
These controls do not eliminate malicious maintainers, long-lived compromises or dependency confusion. Their value is narrower and defensible: they reduce exposure to attacks that depend on immediate automation or the later poisoning of an established release.
The broader decision is whether the enterprise treats package age as a security signal. GitHub and PyPI have now embedded time into their trust models; organisations should determine where their own automation still equates newest with safest.
Questions for the morning meeting
- Which pipelines can move a public package into production within hours of publication?
- Can teams delay ordinary releases without delaying known security fixes?
- Are package-publishing credentials protected more strongly than ordinary developer accounts?