Why GitHub PyPI Supply Chain Defenses Aren't a Complete Fix
We've all seen the headlines. Another supply chain attack, another scramble to patch. The past year alone brought us the 'chalk' and 'debug' attacks, the "s1ngularity" operation, the Shai-Hulud campaign, and the GhostAction supply-chain attack. Each one a reminder that our dependencies are often our biggest blind spot. So when GitHub and PyPI announced new time-based defenses, my first thought wasn't "problem solved," it was "is this enough?" These new GitHub PyPI supply chain defenses aim to slow down attackers.
The mainstream narrative frames these changes as a proactive, necessary step. And they are. But the real discussion, the one happening in the trenches and on forums like Hacker News, is about whether these GitHub PyPI supply chain defenses go far enough, or if they just add another layer of complexity to an already messy problem.
How a Little Time Can Buy a Lot of Detection
Here's what matters about what's actually happening.
GitHub's Dependabot, the tool many of us rely on to keep our dependencies fresh, now has a default three-day (72-hour) cooldown for package updates. The idea here is simple: when a new package version drops, Dependabot won't automatically pull it into your project for three days. This delay gives security tools a window to detect and flag malicious packages before they get widely adopted. It's a direct response to the speed at which attackers can publish a poisoned package and have it spread through automated update systems. These are key components of the new GitHub PyPI supply chain defenses.
You can tweak this cooldown, making it shorter or longer, using Dependabot’s 'cooldown' option. It's a good move for catching the quick-hit attacks, the ones where an attacker pushes something bad and hopes it spreads before anyone notices. But it's not a silver bullet. A longer-term compromise, where an attacker sits on a project for weeks before pushing malicious code, won't be stopped by a 72-hour delay. GitHub also points to other good practices: use lockfiles, restrict token scopes, and disable installation scripts in CI if you don't absolutely need them. These are solid recommendations, and frankly, they should be standard practice already.
PyPI's Hard Stop on Old Release Poisoning
PyPI, on its end, is tackling a different vector. They're now blocking maintainers from adding new files to a package release after 14 days have passed since its initial publication. This is about preventing attackers from poisoning old, trusted releases. Imagine an attacker compromises a publishing token for a popular, stable package. Without this cutoff, they could theoretically go back to a two-year-old release, inject malicious code into it, and suddenly everyone who installs that specific old version gets compromised.
The rationale is sound: very few projects legitimately upload files to a release more than two weeks after it first came out. This measure is preventative, which is key. PyPI hasn't confirmed past attacks using this exact technique, but it closes a potential door. It's a smart move to shut down a theoretical, but very real, attack path, forming a crucial part of the GitHub PyPI supply chain defenses.
The Part Nobody's Talking About (Or Is, Loudly)
These are positive steps, no doubt. But if you spend any time on Hacker News or Reddit, you'll see a lot of skepticism mixed with that cautious optimism. The core frustration? Many feel these GitHub PyPI supply chain defenses don't address the fundamental issues.
Take PyPI's 14-day window. Some argue it's "still too long." The desire is for true immutability: once a release is out, it's locked down. Period. The idea that you can still modify a release for two weeks feels like a compromise, not a definitive solution. I get it. When you're talking about trust in a supply chain, "mostly immutable" isn't the same as "immutable."
Then there's the broader skepticism about the complexity of current security solutions. Trusted Publishing, Sigstore – these are powerful tools, but they add layers. People are asking for simpler, more solid alternatives. Why can't PyPI just verify GitHub immutable tags? Why aren't builds running in isolated sandboxes by default? These aren't easy questions, but they point to a desire for security that's less about configuration and more about fundamental design.
And let's not forget GitHub Actions. The sentiment out there is that it's a "security nightmare" for some, with concerns about how easy it can be to compromise workflows and exfiltrate tokens. These new time-based defenses don't directly address the security posture of the CI/CD pipelines themselves, which are often the initial point of compromise in these supply chain attacks. This gap highlights a limitation of the current GitHub PyPI supply chain defenses.
On Reddit, I see a lot of frustration with the constant battle against malicious packages. There's a debate about whether "more restrictions" are the right approach, especially when they might burden hobbyist maintainers. The idea of delaying package adoption through local caches or user-controlled safeguards keeps coming up. It shows a clear desire for more agency in how we consume dependencies.
What We Really Need to Change
These new time-based defenses from GitHub and PyPI are a necessary evolution. They buy us time, and time is a critical resource in incident response. But they are not the final solution. They're a patch on a deeper architectural problem, and while important, are just one aspect of robust GitHub PyPI supply chain defenses.
The real shift needs to be towards simpler, more solid, and potentially more decentralized security practices. We need to push for enhanced package signing that's easier to implement and verify. We need to make local caching with custom delay policies a standard, giving developers more control over their own risk tolerance. And we absolutely have to re-evaluate our CI/CD security models. The ease of token exfiltration from compromised build pipelines is a vulnerability that a 72-hour delay won't fix, demanding more comprehensive GitHub PyPI supply chain defenses.
We're still playing whack-a-mole. These new measures make the mole a little slower, a little easier to hit. But until we redesign the game, the moles will keep coming. We need to move beyond just delaying the inevitable and start building systems where the inevitable is far less likely.
