New GitHub, PyPI Policies Hope to Boost Supply Chain Security (securityweek.com) 7
"GitHub and the Python Package Index (PyPI) have introduced new policies meant to boost supply chain security," reports SecurityWeek, "by preventing the fast propagation of poisoned package versions and the poisoning of old and long-stable releases."
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.
And the Python Package Index (PyPI) "now rejects new files being uploaded to releases that are older than 14 days," according to a recernt blog post from the Python Software Foundation's security developer-in-residence Seth Larson: 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... The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action...
To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases... [O]nly 56 projects of 15,000 had published a [Python] 3.14-compatible wheel more than 14 days after a release was available. This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.
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.
And the Python Package Index (PyPI) "now rejects new files being uploaded to releases that are older than 14 days," according to a recernt blog post from the Python Software Foundation's security developer-in-residence Seth Larson: 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... The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action...
To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases... [O]nly 56 projects of 15,000 had published a [Python] 3.14-compatible wheel more than 14 days after a release was available. This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.
blockchain parallel (Score:1)
Cool.. (Score:3)
The three-day cooldown only applies to non-security version bumps
So I guess a supply chain attack now needs to flag the version bump as 'security' then.
Re: Cool.. (Score:3)
And get substantially more attention if maintainers.
No. (Score:3)
Neither of these systems were designed to be secure software distribution systems, they were designed to be repositories for software development. Idiots decided, "hey, let's also build and distribute software using repositories meant for software development" and it went to shit as they should have expected. It bears repeating, these are not secure software distribution systems. Everyone needs to get a grip and stop pretending that they are and thus stop using them as such.
Re: (Score:2)
This feels a bit like a distinction without a difference?
Development feeds into distribution however you do it, so, at some point you have to deal with that.
Besides, pypi is more of a package distribution system than a software development system.
Re: (Score:2)
Look at actual distributions like Linux distributions. They do not only provide a build of the source package, but also have maintainers who vouch for their package, who patch out stuff like telemetry, apply safe defaults when the original project may have chosen convenience over safety and more. Everyone can bundle software together, but a distribution also adapts it and tests it.
Cooldown (Score:2)
Valid security update: Your software stays three more days vulnerable
Supply Chain Attack: Everyone waits three days, before the first may notice the attack. The problem stays the same as before with added three day delay
Ideas like "the attack is found in the first three days" do not work if you tell people to wait three days before trying the new version.