Pip 26.1 Ships Dependency Cooldowns and Experimental Lockfile Support to Combat Supply Chain Attacks

Pip 26.1 adds dependency cooldowns that enforce a waiting period before newly published packages can be installed. With --uploaded-prior-to=P7D, pip only pulls versions that have been on PyPI for at least seven days, giving time to detect and respond to upstream supply-chain compromises. Experimental support is added for pylock.toml lockfiles from PEP 751. Two CVEs are patched, and Python 3.9 support is removed. Cooldowns target common attack patterns where malicious versions are quickly picked up by CI pipelines and developer machines. Analysis of supply-chain incidents found most attacks had opportunity windows under a week, and longer cooldowns would prevent nearly all of them.

"In today's world, where supply-chain attacks on the upstream projects you depend on are occurring at an increasing rate, developers need a way to give themselves time to detect and respond to these security incidents."

"The cooldown mechanic is simple. Say an attacker compromises an upstream package. Under normal circumstances, every CI pipeline and developer workstation running pip install picks up the malicious version within hours. With --uploaded-prior-to=P7D, pip will only pull versions that have sat on PyPI for at least seven days. That buys the community time to catch the compromise before it reaches your builds."

"8/10 attacks had windows of opportunity of less than a week. Setting a cooldown of 7 days would have prevented the vast majority of these attacks from reaching end users. Increasing the cooldown to 14 days would have prevented all but 1 of these attacks."

"Recent incidents illustrate both the need and the limits of cooldowns. The Essential Plugin supply chain attack planted a backdoor that sat dormant for eight months before activating across 400,000 WordPress installations. The XZ Utils backdoor required two years of trust-building before the attacker made their move. A seven-day cooldown would not have caught those specific attacks, but it would catch the more common pattern of a compromised package being pulled into CI within hours of publication."

Read at InfoQ