# The Three-Day Pause That Could Stop the Next Supply Chain Disaster
The attack pattern is nearly identical every time. A maintainer's token gets compromised — phishing, credential stuffing, a leaked CI secret — and within hours, a malicious version of a widely-used package is live. Dependabot picks it up. Automated pipelines install it. By the time anyone notices, the blast radius spans thousands of downstream projects.
GitHub and PyPI both moved this week to put friction back into a system that has been optimized almost entirely for speed. The changes are modest by design. The implications are not.
## How Attackers Exploit Automation's Best Feature
Dependabot exists to make dependency hygiene effortless. The moment a new version drops, it opens a pull request. Merge it, ship it, done. For legitimate releases, that's a genuine win — the alternative is engineers ignoring dependency updates for months until a CVE forces their hand.
For attackers, that same automation is a delivery mechanism. Compromise a PyPI account, push a malicious release, and watch thousands of Dependabot PRs fan out across the ecosystem. The attacker doesn't need a sophisticated exploit chain. They need one maintainer credential and about fifteen minutes.
GitHub's new Dependabot cooldown puts a three-day hold on that pipeline for non-security version bumps. New release drops on Monday? Dependabot opens the PR Thursday at the earliest. The rationale is explicit in GitHub's own language: most of these attacks live in the window immediately after a poisoned release goes live — when the package is new, scrutiny is low, and automated scanners haven't yet flagged anything.
Three days is not arbitrary. It reflects where the detection ecosystem actually operates: security researchers who catch these attacks, PyPI's own abuse detection tooling, and community watchers who monitor high-value packages all need time. Compressing that window to zero, which Dependabot previously did, was betting entirely on pre-upload prevention. That bet has been losing repeatedly.
The cooldown doesn't apply to security updates — a legitimate distinction. If a CVE drops and a patch releases the same day, you don't want a three-day delay before your automated tooling picks it up. That carve-out requires GitHub to correctly classify security bumps, which introduces its own surface for gaming, but that's a second-order problem compared to what the cooldown addresses.
## PyPI's Preemptive Strike
The Python Package Index's change is arguably the more interesting policy of the two, because it closes an attack vector that, by PyPI's own admission, has never been exploited at scale.
The restriction: no new files can be uploaded to releases older than 14 days. If a publishing token or GitHub Actions workflow gets compromised, an attacker can no longer quietly slip a malicious wheel into a release that's been sitting stable for two years. That release is locked.
The honesty in PyPI's framing deserves acknowledgment. "As far as we are aware, this has not yet been abused, but there is no technical reason beyond that attackers weren't aware it was possible." That is a rare thing in security: a platform closing a hole proactively rather than waiting for the inevitable incident report.
The affected surface is genuinely small. Testing against the top 15,000 packages found 56 that publish new files to older releases more than 14 days out — mostly compatibility wheels for new Python versions added retroactively. Those maintainers will need to adjust their release workflows. For everyone else, nothing changes.
The more significant benefit PyPI points to: in the event of any future compromise, distinguishing poisoned from clean releases becomes dramatically simpler. If the policy is "nothing touches a release after 14 days," then any file in an old release that was uploaded after the policy took effect is immediately suspect. That's forensic clarity that the current model doesn't provide.
## What This Looks Like Against the Broader Threat
Supply chain attacks on open-source repositories have moved from theoretical to routine. North Korean state actors ran sustained campaigns targeting npm and PyPI contributors. The Jscrambler compromise hit multiple downstream packages from a single poisoned dependency. XZ Utils — the most analyzed supply chain attack in recent memory — showed that patient, sophisticated actors will invest months into a single maintainer relationship to get code into a release.
The GitHub and PyPI changes don't stop a patient adversary who compromises a maintainer from within. They stop the opportunistic attack that relies on speed — credential stolen, package pushed, automation does the rest before anyone looks. That's a narrower threat model than the XZ-style long-con, but it's also the more common one. Most supply chain compromises aren't nation-state operations. They're fast, financially motivated, and they depend entirely on nobody looking for three days.
Defenders running Dependabot should verify the cooldown configuration is active and understand that it's adjustable via dependabot.yml. That adjustability is good for legitimate edge cases and a potential regression point if engineering teams disable it without understanding why it exists. Security teams should own that configuration, not leave it to whoever set up the original Dependabot integration.
## HackWire Analysis
The timing of these policy changes reflects something that doesn't get said often enough: the open-source packaging ecosystem has been running on trust infrastructure that was designed for a threat landscape that no longer exists.
PyPI and npm were built when the dominant concern was someone accidentally publishing broken code, not state actors and criminal groups systematically hunting for compromisable maintainer accounts. The controls that exist — 2FA enforcement, token scoping, upload limits — are all retrofits on a foundation that assumed good faith.
What GitHub and PyPI announced this week is systems-level skepticism baked into the tooling itself. The three-day cooldown isn't trusting that new releases are clean; it's betting that three days of exposure will surface a problem before automation spreads it. The 14-day upload freeze isn't trusting that old releases stay clean; it's removing the technical possibility that they can be quietly altered.
That's a meaningful shift in how these platforms are thinking about their role. They're not just package registries anymore — they're part of the software supply chain's immune system, and they're starting to act like it.
The risk in both policies is complacency: if developers see these controls as a complete solution rather than one layer of defense, they'll stop asking harder questions about token hygiene, CI secret management, and whether their Dependabot PRs are being reviewed by someone who would actually spot a malicious commit. The controls buy time. What defenders do with that time still depends entirely on human attention.
For organizations running large dependency graphs, this is the moment to audit Dependabot configurations, review who approves auto-merge PRs, and confirm that security version bumps are correctly classified so the cooldown doesn't delay genuine patches. Three days of protection is only useful if you're actually looking during those three days.
— HackWire Editorial
## Related Coverage