GitHub and the Python Package Index (PyPI) just added a new layer of defense against supply chain attacks, and it doesn’t involve scanning code or blocking uploads outright. It involves waiting.
GitHub’s Dependabot now applies a default three-day cooldown before opening a pull request for a routine version update. PyPI, meanwhile, will no longer accept new files uploaded to a release once it’s more than 14 days old. Neither change stops a bad actor from publishing malicious code in the first place. Both are designed to shrink the window during which that code can quietly work its way into production systems before anyone notices.
The reasoning behind both moves is simple. A newly published package version often gets pulled into build pipelines within minutes of going live, well before a person or a scanner has had time to review it. Security tools are usually fast at flagging something suspicious. But flagging isn’t the same as fixing. A maintainer still has to pull the bad version, and until that happens, anyone updating on the old schedule is exposed. A cooldown period buys back some of that lost time. By holding off a few days before adopting a new release, GitHub gives maintainers, researchers, and automated scanners a chance to catch a malicious version and get it removed before it ever lands in a pull request.
GitHub settled on three days as its default after weighing two competing pressures: keeping teams current on their dependencies without exposing them to releases that haven’t had time to be vetted. Teams that want a shorter or longer delay can still configure it themselves through Dependabot’s cooldown settings — the default just changes what happens for everyone who doesn’t.
PyPI’s change addresses a related but different risk. Instead of guarding against a brand-new malicious package, it closes off a path attackers could use to poison a release that’s already been trusted and in use for weeks. Once a release passes the 14-day mark, PyPI simply won’t accept new files added to it. That protects against a scenario where an attacker gains access to a compromised publishing token or workflow and quietly slips malicious code into an old, stable release rather than pushing something new and conspicuous. PyPI has said it isn’t aware of this technique being used in a real attack yet — the restriction is preventative, closing a door before anyone tries to walk through it.
The data behind that decision is worth noting. When the PyPI team checked how often projects legitimately publish new files to old releases, the number was small even in edge cases: only a tiny fraction of the platform’s most popular packages had added a Python 3.14-compatible build more than two weeks after the original release went out. That gave the Python Software Foundation enough confidence that the restriction wouldn’t disrupt normal workflows for most maintainers.
Neither change happened in isolation. Both platforms have spent the past year responding to a steady run of high-profile incidents — compromises tied to widely used npm packages, the s1ngularity campaign, the Shai-Hulud worm, and the GhostAction attack against PyPI publishing credentials. GitHub had already announced changes to npm security last month, and this cooldown builds directly on that effort.
“Elapsed time now governs when an automated update reaches a pull request and how long a published release stays open to new files,” said Mitch Ashley, VP and practice lead, software lifecycle engineering and AI-native software engineering at The Futurum Group.
None of this replaces the fundamentals, and GitHub has been upfront about that. A cooldown does little against an attack that plays out over months rather than days — the kind where an attacker spends time earning a maintainer’s trust before slipping in something harmful. GitHub still recommends pairing the cooldown with lockfiles for dependency pinning, tightly scoped access tokens, and turning off installation scripts that aren’t strictly needed in CI pipelines. Time helps. It isn’t a substitute for judgment.
Ashley pointed out that the cooldown doesn’t apply evenly across the board. “Dependabot’s cooldown covers version updates only,” he said. “Security updates still open immediately, which leaves the fastest automated path into a build pipeline unchanged. Teams running unattended merges should confirm which path the new default actually closed.”
For DevOps and platform engineering teams, the specific numbers matter less than the shift in posture they represent. Package registries have long optimized for speed — get the latest release out, get it adopted, move on. These changes are a quiet admission that speed itself has become part of the attack surface. Teams that rely heavily on automated dependency bots without a human review step now get a small, built-in buffer by default. Teams that already pin dependencies to commit hashes or run their own internal package mirrors had some version of this protection already; now it’s becoming a platform-level default for everyone else.
It’s a modest change with an outsized rationale. In software supply chain security, the first few days after a release ships are often the most dangerous. Giving that window a little more room to close may be one of the simplest, cheapest defenses available right now.
from DevOps.com https://ift.tt/bwEk0Y7
Comments
Post a Comment