SURIQ
The supply-chain attack that reliably works is fast. Someone publishes a trojanized version of a widely used package, automation pulls it into thousands of projects within hours, and the poisoned release is yanked before most teams notice it existed. GitHub and PyPI are now betting that time is the cheapest counter to that pattern. GitHub's Dependabot will wait three days before it opens a pull request for a new version, and PyPI will stop maintainers from adding files to a release once it is two weeks old. Both changes help. Neither touches the attacks patient adversaries actually run.
That gap is the story, and most of the coverage buried it under the announcement.
What GitHub and PyPI changed
GitHub set a three-day default cooldown on Dependabot version updates, The Hacker News reported. The tool now holds a newly published version for a minimum of 72 hours before it raises an update pull request. That behavior is still governed by the cooldown setting in dependabot.yml, so a team can dial it shorter or longer per project. Security fixes are exempt, so a patch for a known flaw still lands right away.
PyPI took a different angle at the same idea. It now stops a maintainer from uploading fresh files into a release once it is 14 days old, BleepingComputer reported. The target there is narrow: an attacker who steals a maintainer's token and quietly slips a malicious artifact into an old, trusted release that nobody watches anymore. PyPI describes the change as preemptive, saying it is not aware of a past attack that used that exact technique.
GitHub's stated reason for three days is a bet on timing, not detection. Its own framing is that the window sits past where most fast package attacks operate while keeping dependencies from falling badly behind. The mechanism inspects one thing: how old a release is.
A cooldown taxes the smash-and-grab, and little else
The value here is narrow and real. If a poisoned version has to sit visible on the registry for three days before Dependabot will touch it, that is three days for a scanner, a researcher, or the registry's own abuse team to find it and pull it. It raises the cost of the publish-fast, yank-fast playbook by denying the attacker the quick, quiet adoption that playbook depends on.
| Supply-chain attack pattern | Stopped by a release cooldown? |
|---|---|
| Publish malware, win adoption in hours, yank it before removal | Yes |
| Malicious brand-new package, first-ever release | Mostly |
| Backdoor planted in a release, left dormant past the window | No |
| Hijacked maintainer ships a hostile later version | No |
| Compromised build or CI system | No |
GitHub is unusually direct about the limits. A cooldown does nothing against a backdoor left dormant in a release past the delay window, a maintainer account that is hijacked and later ships a hostile version, or a build system that is already compromised. Those are not edge cases. They are where the sophisticated end of supply-chain attacks has been heading for two years, and a rule that only reads a release's age cannot see any of them.
Read that way, the cooldown is an economics move more than a security control. It prices out the cheapest attack and pushes adversaries toward the patient game, which is the game that is hardest to defend.
The attacks it does not stop are the ones filling our feed
Look at what actually landed in package registries recently. packages published under Mastra's npm namespace passed inspection and were reported to turn hostile a day later. A compromised AsyncAPI npm release carried malware bearing valid provenance, so the cryptographic signal defenders were told to trust said nothing was wrong. A three-day delay barely dents either one. The malicious behavior did not arrive in the first noisy hours after publication. It arrived on a later version, or wearing a legitimate signature, on a timeline the attacker controlled.
This is the risk with time-based defaults: they can create a feeling of safety on precisely the attacks they were never built to stop. A team that sees the Dependabot cooldown switched on can reasonably assume its dependency intake is now guarded, when the guard only covers one lane. GitHub pairs the cooldown with the defensive-depth advice it always gives, and it is worth taking literally: pin dependencies with lockfiles, scope your tokens tightly, and switch off install scripts you do not need in CI. That last point echoes a bigger shift we covered when npm disabled install-script execution by default. The registries are hardening their defaults. None of it watches what a dependency does once it is inside your pipeline.
The three-day lag is a tradeoff, so set it per repo
There is a cost to the default the announcements skated past. Three days of cooldown means three days of lag on every non-security update: bug fixes, performance patches, and the fast-follow releases some teams pin to on purpose. Security fixes skip the wait, so the exposure is limited to feature and maintenance updates, but limited is not zero. A repository that stays current for stability reasons now trails by default.
The cooldown knob in dependabot.yml exists so you do not have to accept one number everywhere. Shorten it on repositories where a fast-moving upstream matters and you have other controls in place. Lengthen it on the dependencies you treat as high risk, where you would rather trade update speed for a wider detection window. Setting it deliberately is the point. Inheriting the default blindly is how the tradeoff bites you later.
Assume the dependency runs, then watch for it
Time-based defenses are a floor, not a ceiling. They are a good floor, and every team should take the free wins: leave the Dependabot cooldown on, tune it where it matters, and note that PyPI closed a token-poisoning path before anyone abused it. But the layer no registry can cover is the one you own. A poisoned dependency's whole purpose is to run, and it runs on your build hosts, your CI runners, and eventually your servers.
That is where detection has to live: watching build and CI environments as the execution environments they are, not the trusted zones we pretend they are. An unexpected outbound connection from a build step, a new process spawned during an install, a credential read that no legitimate build needs, these are the signals that catch the dormant backdoor a cooldown waved through. Treating dependency risk as something to detect and monitor rather than something a registry policy solves for you is the difference between a defense that scales and a checkbox that reassures. The registries did their part this week. The build pipeline is still yours to defend.