# The 72-Hour Hold: GitHub and PyPI Are Buying Time Against Supply Chain Attackers
The security story of the last 18 months in open source has been embarrassingly consistent: attacker compromises a maintainer account or CI pipeline, publishes a poisoned package, and automated tooling helpfully propagates it to thousands of downstream projects before anyone notices. Rinse, repeat. The Shai-Hulud campaign trojanized 19 science-focused PyPI packages. GhostAction hit GitHub Actions workflows directly. The "s1ngularity" operation showed how a patient attacker could sit on a legitimate package name, wait for an opportunity, then strike.
Now both GitHub and PyPI are responding with something that sounds almost too simple: time.
## Waiting as a Defense Strategy
GitHub has shipped a cooldown feature for Dependabot, its automated dependency-update service. The default is 72 hours — when a new package version drops, Dependabot will wait three days before opening a pull request to adopt it. PyPI is taking a different but complementary approach: new files can no longer be added to a release that's more than 14 days old.
The logic in both cases is the same, even if the threat models differ slightly. For Dependabot, the insight is that the worst malicious packages are getting flagged within minutes of publication — but fast detection means nothing if automated systems have already pulled the code into your build pipeline. A 72-hour buffer creates a window where human review and security tooling can do their work before Dependabot hands the attacker a free ride into your codebase.
For PyPI, the threat is different: a compromised maintainer token used to poison an old, trusted release. If you can quietly add a malicious wheel to a package version that's been considered stable for months, you inherit all the trust that version has accumulated. Defenders aren't watching old releases. Pinned dependencies point there. It's a clean shot.
PyPI's candid admission that no confirmed past attack has actually used this exact technique is either reassuring or alarming, depending on your perspective. It means they're thinking ahead. It also means we're watching the attacker community and assuming they will figure this out eventually, so let's close the door now.
## What's Still Left Open
Neither measure is a complete defense, and GitHub is being reasonably transparent about that.
The Dependabot cooldown has an explicit blind spot: supply chain compromises that persist for longer than three days. An attacker who gains access to a package maintainer's account and introduces a subtle backdoor into a release — not a cargo-dropped malicious binary, but crafted code — won't be caught by a waiting period. The malicious package simply ages out of the cooldown window. GitHub's own guidance acknowledges this, pointing users toward lockfiles, restricted-scope tokens, and disabling unnecessary install scripts in CI as complementary controls.
That's the right recommendation. It's also an honest acknowledgment that time-based defenses are fundamentally reactive to a specific attack pattern. They work well against the smash-and-grab: poison a package, hope automated tools vacuum it up before detection. They don't work against the patient, sophisticated attacker who is willing to play a longer game.
The configurable cooldown — users can set it longer or shorter than 72 hours — is sensible. A security-conscious organization might push to seven days; a team shipping fast might drop it lower. But the fact that it's opt-in configuration means the organizations who need it most (smaller teams without dedicated security) are also the ones most likely to leave it at default or disable it entirely for convenience.
## The Registry Layer Is Finally Getting Serious
What's notable here is the layer at which these defenses are operating. For years, the security community pushed responsibility for supply chain risk onto downstream consumers: pin your dependencies, run SCA tools, verify signatures, set up SBOM pipelines. The registries and platforms themselves largely stayed out of it.
That posture has shifted. GitHub announced broader npm security changes last month. This Dependabot update follows. PyPI has been progressively tightening publishing controls. The infrastructure is starting to treat itself as part of the trust boundary rather than a neutral conduit.
This matters because the downstream tooling approach has real limits. A small development team shipping a SaaS product isn't running a sophisticated software supply chain security program. They're using Dependabot because it makes keeping dependencies current manageable. If the platform itself adds a sensible default that protects them without requiring expertise, that's a genuine win for the actual population of developers at risk — not the enterprise security shops that already have controls in place.
## HackWire Analysis
These measures deserve credit, but they also illuminate a deeper problem with how the ecosystem still thinks about package trust.
The underlying assumption baked into both GitHub and PyPI's defenses is that time is a reasonable proxy for legitimacy. A package version that's been live for 14 days is safer than one published 10 minutes ago. A Dependabot PR opened after 72 hours is less likely to contain an active attack than one opened immediately. That's a reasonable heuristic, and the data on malicious package detection windows supports it.
But "reasonable heuristic" is not the same as "security property." The supply chain attacks that don't get caught in minutes — the ones that are genuinely dangerous — are precisely the ones that will survive these windows. Shai-Hulud's trojanized packages weren't flagged in three days. GhostAction's compromised GitHub Actions workflows didn't trigger alerts in 72 hours. The attacks sophisticated enough to evade rapid detection are also sophisticated enough to wait out a cooldown.
The pattern worth watching is whether these time-based defenses create a perverse incentive. If attackers learn that the first three days after a malicious package publication are high-risk (heavy scrutiny, automated detection firing), the optimization becomes: compromise a package in a way that survives initial inspection and then activates later. That's harder, but it's exactly the kind of arms race dynamic that leads to more sophisticated attacks.
For defenders, the practical takeaway is to treat these controls as necessary but not load-bearing. Pin dependencies with lockfiles. Enforce restricted-scope tokens for publishing workflows. Review what's actually running in your CI scripts. The 72-hour window buys you time to catch the dumb attacks. The smart attacks still need a human who's actually looking.
— HackWire Editorial
---
## Related Coverage