GitHub and PyPI Add Time-Based Defenses Against Supply Chain Attacks in Dependabot
Software supply chains are getting harder to defend. Attackers don't need to breach your perimeter anymore — they just need you to pull a compromised package. That's why GitHub and PyPI (Python Package Index) have introduced time-based defenses inside Dependabot, a move that puts friction directly between malicious releases and the developers who might unknowingly adopt them.
Both platforms are responding to a string of high-profile incidents: the 'chalk' and 'debug' attacks, the 's1ngularity' operation, the Shai-Hulud campaign, and the GhostAction supply-chain attack. These weren't isolated blips. They exposed a pattern — attackers publish malicious code, wait for adoption, and exploit the lag between publication and detection.
The new time-based mechanisms don't eliminate the risk. They just make it significantly harder to exploit.
How Dependabot's 72-Hour Cooldown Works
Dependabot is GitHub's dependency-update service. It reads manifest files, spots newer package versions, and opens pull requests so maintainers can review and merge updates. Simple. Useful. Now, by default, it also waits.
The new cooldown setting delays package updates for 72 hours. That's three full days before Dependabot opens an update pull request.
Why three days? GitHub landed on that number as a compromise. Malicious npm packages are often flagged by automated security tools within minutes of being published. But detection isn't the same as protection. Vulnerability researchers still need time to investigate. Package maintainers still need time to respond. And repository owners still need time to decide whether to pull the trigger on an update.
That window — that gap between publication and response — is exactly where attackers operate.
The 72-hour delay shrinks it. Whether it eliminates the risk entirely? No. But it gives security teams a fighting chance.
And GitHub isn't forcing this on everyone. The cooldown is configurable. If your workflow demands faster updates, you can reduce the delay. If you prefer extra caution, you can extend it. The default is three days, but the setting lives squarely in your hands.
What the 72-Hour Delay Actually Prevents
Here's the thing most developers don't think about: a malicious package sitting on npm or PyPI isn't dangerous until someone installs it. And once someone does, the damage can be immediate.
Recent supply-chain campaigns showed this clearly. Attackers publish a compromised package. It looks legitimate. Maybe it even passes basic checks. But it contains a backdoor, a credential stealer, or a crypto miner. Developers pull it into their projects. The compromise spreads.
A three-day buffer doesn't stop the publication. It stops the automatic adoption. Security teams get those extra 72 hours to notice the pattern, raise alerts, and push back before the malicious code becomes part of someone's production environment.
It's a delay tactic, not a silver bullet. But in supply-chain security, delays matter. They create breathing room. They turn a surprise attack into a manageable incident.
PyPI's 14-Day Release Poisoning Block
While GitHub tightened Dependabot, PyPI went after a different attack surface: release poisoning.
PyPI now blocks maintainers from adding new files to a package release after 14 days have passed since its original publication.
Think about what that prevents. An attacker compromises a publishing token or a CI workflow. They don't need to publish a brand-new version. They just modify an existing, trusted release — inject malicious files into something developers already trust and download regularly. That's release poisoning.
PyPI found that very few projects legitimately upload files more than two weeks after their initial release. So the platform drew a hard line: no new files after day 14.
No known past PyPI attacks used this specific technique. PyPI is acting preventatively, which is worth noting. They're not patching a hole that's currently being exploited. They're closing one before attackers figure out how to use it.
That's the kind of proactive defense that actually makes supply chains more resilient.
Why This Matters for AI and Agentic Security
The rise of AI coding assistants and agentic development workflows changes the equation. AI agents pull dependencies automatically. They review code, suggest updates, and sometimes even merge them without human intervention.
That's efficient until the dependency is malicious. When an AI agent pulls a compromised package, there's no human to second-guess the decision. The agent follows its instructions. The compromised code enters the build. The supply chain attack succeeds.
Time-based defenses like Dependabot's cooldown and PyPI's 14-day block are particularly relevant here. They introduce friction at the exact point where agentic automation is most vulnerable — the moment of package adoption.
For teams deploying AI agents in their development pipelines, these mechanisms aren't optional. They're foundational security practices.
The threat is already real. The Miasma Worm demonstrated how self-replicating supply chain attacks can target AI coding agents, spreading across repositories automatically. And 73 malicious packages were identified specifically designed to steal credentials from AI-powered development workflows.
These incidents show why time-based defenses matter more than ever. When attackers are actively targeting AI agent ecosystems, every hour of delay buys security teams critical response time.
Beyond the Cooldown: A Layered Defense Strategy
GitHub doesn't recommend relying on the cooldown alone. And for good reason. Time-based controls are one layer, not the entire defense.
The platform suggests several complementary measures:
Lockfiles for dependency pinning. Lockfiles pin your dependencies to specific versions, preventing surprise updates from slipping into your build. They're not perfect — attackers can still compromise pinned versions — but they remove the automatic update variable from the equation entirely.
Restricted-scope tokens. Don't give your CI workflows broad access. Use tokens with the minimum permissions necessary. If an attacker compromises your workflow, restricted tokens limit what they can actually do.
Disable unnecessary installation scripts. Some packages run scripts during installation. Those scripts can execute arbitrary code. If you don't need them, disable them. It's a simple step that blocks a common attack vector.
Each of these measures handles a different part of the supply-chain attack surface. Together, they create a defense that's far stronger than any single control.
The Bottom Line
Supply-chain attacks aren't going away. They're evolving. Attackers are getting smarter, more patient, and more sophisticated.
GitHub and PyPI's time-based defenses are a step in the right direction. The 72-hour Dependabot cooldown and PyPI's 14-day release block don't solve the problem. They make it harder to exploit.
For development teams, that's exactly what you want — friction against bad actors, breathing room for your security team, and a safety net for AI-driven workflows that move faster than humans can review.
The question isn't whether your supply chain is secure. It's whether you're using every tool available to make it harder to compromise. These new mechanisms are just the beginning.
