Dependabot now delays package updates for 72 hours, and PyPI will refuse new files added to releases older than 14 days — two time-based gates intended to choke off a class of fast-moving supply-chain attacks.
How GitHub’s 72-hour Dependabot cooldown works
GitHub has added a default three-day “cooldown” to Dependabot, its dependency-update service. Dependabot reads package manifests and opens pull requests to update dependencies; with the new setting it will delay creating those update pull requests for 72 hours after a package is published. GitHub said the 72-hour window was chosen as “a balanced point between avoiding risky releases while keeping up with the latest upgrades,” and that organizations may alter the delay through Dependabot’s configurable ‘cooldown’ option.
The change is designed to reduce the chance that projects automatically adopt newly published, malicious packages. In many recent incidents, malicious npm packages were detected and flagged by security tools within minutes of publication — but quick detection does not eliminate the risk, because repository maintainers and vendors still must remove flagged packages, leaving a window in which developers can download and incorporate malicious code.
PyPI’s 14-day cutoff to block release poisoning
PyPI (the Python Package Index) implemented a complementary rule: maintainers can no longer add new files to an existing release once 14 days have passed since that release was published. The platform described the change as preventive, aimed at stopping attackers who might compromise publishing tokens or CI workflows and then “poison” old, trusted releases by appending malicious files.
PyPI noted that only a very small percentage of projects legitimately upload files more than two weeks after a release, and that no known past attacks on PyPI have been confirmed to use the exact release-poisoning technique this measure blocks. Nonetheless, the measure closes a plausible avenue for abuse.
Recent attacks that put time-based defenses on the table
Both changes follow a year of high-profile supply-chain intrusions across development ecosystems. The source lists several notable campaigns: the “chalk” and “debug” attacks, the “s1ngularity” operation, the Shai‑Hulud campaign, and the GhostAction supply-chain attack. GitHub announced other supply-chain hardening changes last month and described the new cooldown as a continuation of that process.
Limitations of time gates — and GitHub’s additional recommendations
GitHub itself acknowledged the cooldown is not a panacea for longer-term compromises. To mitigate attacks that unfold over a longer window, GitHub recommended complementary controls: using lockfiles to pin dependency versions, adopting restricted-scope tokens for publishing, and disabling unnecessary installation scripts in CI environments. The platform framed the 72-hour delay as one layer among several.
The practical problem these measures target is the operational lag between detection and remediation. The source cites a Picus whitepaper statistic that “security teams log 54% of successful attacks and alert on just 14%,” underscoring how many incidents are discovered but not effectively turned into timely action — a gap that time-based controls aim to narrow.
What this means for maintainers, security teams, and adversaries
- Maintainers and package publishers: Expect fewer late edits to published releases on PyPI and a short, default delay for automated dependency updates on GitHub. Maintainers who legitimately need to update a release after two weeks will face a tighter constraint; organizations can customize Dependabot’s cooldown.
- Security teams and CI owners: The measures reduce the window in which new malicious packages can automatically propagate, but teams must still move to remove compromised packages and harden publishing tokens, CI workflows, and dependency pinning to address longer-term compromises.
- Adversaries and threat actors: Time-based controls complicate rapid “throwaway” publishing of malicious packages and the late poisoning of established releases, shifting the calculus toward longer-running or different kinds of compromise if adversaries want to persist.
The changes from GitHub and PyPI are incremental but concrete: short, mandatory waits where previously there were none, and a hard cutoff for late edits to releases. Both platforms describe the measures as preventive — an attempt to make a familiar attack vector more awkward, and thus less likely to succeed. The hardening process, GitHub said, is continuing; PyPI has closed one plausible route to abuse even as it acknowledged the technique has not been tied to confirmed past incidents.
