GitHub and PyPI both introduced new policies this week aimed at slowing down how fast malicious code can spread through the software supply chain. GitHub’s Dependabot will now wait at least three days before opening a pull request for a new package release, and PyPI is blocking new file uploads to any release older than 14 days, both closing the same window attackers have relied on: the gap between a malicious release going out and anyone noticing.
SecurityWeek has more:
To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request.
“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 explains.
The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml.
“Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary,” GitHub notes.
PyPI, on the other hand, is preventing the poisoning of releases older than 14 days by blocking the upload of new files to them.
“This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised. As far as we are aware, this has not yet been abused, but there is no technical reason beyond that attackers weren’t aware it was possible,” PyPI says.
The behavior will be enforced once ‘Upload 2.0 API’ and ‘Staged Previews’ have been standardized by PEP 694 and will affect only a small fraction of projects that still publish new files to older releases.
Maggie McDaniel, Global Head of Intelligence, iCOUNTER had this to say:
“This is exactly the kind of outcome effective public-private intelligence sharing is supposed to produce. Security researchers and the community kept surfacing the same pattern, a maintainer account gets compromised, a malicious release goes out, and automated tooling propagates it into thousands of projects before anyone has a chance to catch it, and instead of that staying a research finding, it became a platform-level policy change. A three-day cooldown on Dependabot and a 14-day lock on new uploads to existing PyPI releases won’t stop every attack, but they close the exact window that made this class of attack so effective: the gap between publication and detection. What I’d want to know now is whether other package ecosystems are watching this and building the same kind of delay into their own automation, because the ecosystems that don’t will be the ones attackers target next.”
This is a positive move. But it needs to be backed by knowing what goes into your applications without fail. Otherwise we will have a different version of the same problem.
GitHub and PyPI both just closed the gap attackers rely on for supply chain attack
Posted in Commentary with tags GitHub, GPyPI on July 27, 2026 by itnerdGitHub and PyPI both introduced new policies this week aimed at slowing down how fast malicious code can spread through the software supply chain. GitHub’s Dependabot will now wait at least three days before opening a pull request for a new package release, and PyPI is blocking new file uploads to any release older than 14 days, both closing the same window attackers have relied on: the gap between a malicious release going out and anyone noticing.
SecurityWeek has more:
To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request.
“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 explains.
The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml.
“Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary,” GitHub notes.
PyPI, on the other hand, is preventing the poisoning of releases older than 14 days by blocking the upload of new files to them.
“This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised. As far as we are aware, this has not yet been abused, but there is no technical reason beyond that attackers weren’t aware it was possible,” PyPI says.
The behavior will be enforced once ‘Upload 2.0 API’ and ‘Staged Previews’ have been standardized by PEP 694 and will affect only a small fraction of projects that still publish new files to older releases.
Maggie McDaniel, Global Head of Intelligence, iCOUNTER had this to say:
“This is exactly the kind of outcome effective public-private intelligence sharing is supposed to produce. Security researchers and the community kept surfacing the same pattern, a maintainer account gets compromised, a malicious release goes out, and automated tooling propagates it into thousands of projects before anyone has a chance to catch it, and instead of that staying a research finding, it became a platform-level policy change. A three-day cooldown on Dependabot and a 14-day lock on new uploads to existing PyPI releases won’t stop every attack, but they close the exact window that made this class of attack so effective: the gap between publication and detection. What I’d want to know now is whether other package ecosystems are watching this and building the same kind of delay into their own automation, because the ecosystems that don’t will be the ones attackers target next.”
This is a positive move. But it needs to be backed by knowing what goes into your applications without fail. Otherwise we will have a different version of the same problem.
Leave a comment »