GitHub Made Dependabot Wait Three Days. Your AI Agent Doesn't Use Dependabot.
- Patrick Duggan
- 1 hour ago
- 4 min read
On July 14, GitHub made a quiet change with more security value than most CVEs: Dependabot version updates now wait until a release has been on the registry for at least three days before opening a pull request. It is the default. It requires no configuration.
Security updates are exempt and still open immediately, so a critical fix is never delayed. That distinction is the whole design and it is correct.
The reasoning is exactly right. A brand-new release is the highest-risk moment in a package's life. Compromised versions get yanked fast — usually within hours, once someone notices. Waiting three days does not make the package safe; it lets other people's detection happen before you merge. You are buying time you were previously spending as the canary.
Credit where it belongs
Cooldowns are not GitHub's idea and they are not ours.
Christian Schneider has been making the case in writing. There is a dedicated tool at cooldowns.dev and Miroslav Prpic's cooldowns project on GitHub. pnpm, Homebrew, and VS Code shipped the mechanism before this. npm added a min-release-age option in 11.10.0. Anyone running a caching proxy — Artifactory, Nexus — has been able to quarantine newly published versions at the registry layer for a configurable period across npm, PyPI, and Maven all along.
What changed on July 14 is that it became a default at the largest dependency-update surface in the world. Defaults are the entire game. An opt-in control protects the people who already knew; a default protects everyone else, which is the population we exist to serve.
We will note that we shipped an age-based signal in our own package-reputation scorer on July 13 — packages under 30 days old score +30 toward a review-or-block verdict. That is one day before GitHub's changelog. It is a coincidence and convergent thinking, not a lead, and we are not going to pretend otherwise. Two parties reading the same attack pattern reached the same conclusion in the same week. That is what a real signal looks like.
The gap that actually matters
Here is the part worth your attention.
Dependabot gates the pull request. It decides whether to propose an upgrade.
Nothing about that touches the moment a package is actually fetched and executed. A developer running an install command pulls whatever the registry serves right now. A CI job resolving a floating range pulls whatever satisfies it right now. And an AI coding agent told to "add a JSON parser" or "fix this dependency" runs an install directly — it does not open a PR against itself and wait three days for Dependabot to weigh in.
That is the install layer, and the cooldown does not live there.
It is also where the interesting attacks have been landing all year. ChocoPoC was a normal-looking proof-of-concept repo that pulled one poisoned PyPI dependency — aimed at researchers who clone and run untrusted PoCs, a workflow with no PR in it anywhere. The install-time execution hooks we have been hunting in binding.gyp and extconf.rb fire during install, before any human reviews anything. The AsyncAPI compromise pushed malicious commits and let each repository's own release workflow publish through npm's trusted-publisher integration — the attack rode the pipeline, not a dependency bump.
None of those are stopped by a three-day wait on a pull request. Most of them are not stopped by anything at the PR layer, because the PR layer is not where they happen.
What to do about it, in order
Take the Dependabot default. Do nothing. It is on. Do not disable it to chase version freshness. The three days cost you nothing that matters.
Add a cooldown at the registry proxy if you run one. Artifactory or Nexus quarantine overrides project and CI configuration, works across ecosystems, and catches the install layer as well as the PR layer. This is the strongest version of the control available and hardly anyone has turned it on. If you run a proxy and do only one thing from this post, do this one.
Set `min-release-age` in npm (11.10.0 or later) so the cooldown applies to installs, not just proposals.
On PyPI, check your tooling reads upload times. They are only exposed by the JSON version of the Simple API. If your proxy or scanner speaks only the HTML format, it cannot see how old a release is and cannot enforce age at all. Artifactory needs the PyPI Simple JSON API enabled, available from their February 2026 SaaS and April 2026 self-hosted releases. A cooldown you believe is running but which cannot read a timestamp is worse than none, because you will stop looking.
Give your agent a check it can make. If an AI agent installs dependencies in your environment, it needs to ask something before it runs the install, because there is no pull request in that loop to gate. Ours is free and needs no key — check-package scores an unknown package on registry existence, age, and download volume before allowing it, and returns block, review, or allow. Any equivalent will do. The requirement is that something sits between the agent's decision and the install.
The honest limit
A cooldown is a bet that somebody else finds the bad package during your waiting period. It is a good bet and it is not a guarantee. A patient attacker publishes and waits four days. A stolen maintainer token used on a package nobody audits may not get caught in three days, or thirty.
Cooldowns raise the cost and shrink the window. They do not close it. Layer them with a reputation check at install time and a deny-list your pipeline actually consults, and treat any single one of those three as insufficient on its own.
We are 95 percent confident the next notable supply-chain compromise routes around the PR layer entirely — through install-time execution, a hijacked release pipeline, or an agent that installed something no human proposed. The remaining five percent is the possibility that defaults like this one shift attacker economics enough to push them somewhere else entirely. That would be a good outcome and we would happily be wrong about it.
Free malicious-package deny-list (npm + PyPI, ~225k named-bad packages) and the check-package tool at analytics.dugganusa.com. No key, no sales call.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.