GitHub Introduces Default "Cooldown" Policy for Dependabot Version Updates

Sergio De Simone · rss · 2026-07-28 source ↗ Reader 🖥️

GitHub now defaults Dependabot to waiting three days before proposing a non-security dependency update, betting that this window gives dedicated security-scanning efforts — not end users — enough lead time to catch a malicious release before it reaches a build pipeline.

practical · expository — A news report on a product policy change; it recommends nothing itself but reports GitHub's rationale for a practice (delay before applying dependency updates) and juxtaposes unresolved community debate about whether that practice actually works.

Structure

Part	Role
The policy announcement and mechanics (default cooldown, security-update exemption, dependabot.yml configurability)	context
GitHub PM Carlin Cherry's rationale, grounded in a specific 2020-era incident where compromised packages (2B+ weekly downloads) sat live for ~2 hours	evidence
Reddit and Hacker News reactions, including the unresolved exchange between zihotki (skeptical: universal delay adoption could shrink detection odds) and woodruffw (the defense relies on scanners, not users)	counter-evidence / qualification

Key terms

cooldown
A mandatory minimum delay (three days by default) between a new non-security dependency release being published and Dependabot opening a pull request for it, configurable per-project via the `cooldown` option in dependabot.yml.

Propositions

explicitDependabot now waits at least three days by default before opening a pull request for a non-security dependency update.conf: high
extendsAttacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them · p8 — Where the WordPress piece frames unreviewed automatic updates as a supply-chain force-multiplier, this article describes GitHub's structural countermeasure for the equivalent risk in the npm/GitHub ecosystem: a default delay before an update is even proposed, not just before it's applied.
explicitThe cooldown does not apply to security updates, so vulnerability fixes are never delayed.conf: high
explicitcorroboratedThe policy directly answers a documented attack pattern: a malicious package release that is pulled into automated update pipelines within minutes, before any human or scanner reviews it.conf: high
supports ←The Claude Code active attack didn't stop. 294,842 secrets stolen from 6,943 machines. It evolved and now spreads through Python too and uses Claude Code itself to steal your secrets. The risk to your credentials just got bigger. · p17 — Practitioners respond to fast-moving malicious releases with release-age cooldowns.
explicitdevelopedA cooldown is one layer of defense among several and does not replace lockfile pinning, disabling install scripts in CI, scoping build-pipeline tokens, or manual review before merge.conf: high
extends ←vlt 1.0 Ships as a Drop-in npm Replacement with Phased Installs, Graph Queries, and Malware-Blocking · p2 — That piece lists 'disabling install scripts in CI' as one of several manual mitigations that a cooldown doesn't replace; vlt's phased install turns exactly that mitigation into a default, client-level feature rather than a CI configuration choice.
implicitThe security model behind a cooldown assumes malicious releases will be caught by dedicated scanning efforts during the delay window, not by ordinary end users encountering and reporting them.conf: medium
implicitIf cooldown-style delays become universal practice, the population of unpatched early adopters available to trip over and flag a malicious release shrinks, which could reduce rather than increase detection odds.conf: medium

Arguments

A default three-day cooldown meaningfully reduces the chance that a malicious dependency release gets merged before detection. strength: medium

Explicit premises:

A real incident showed malicious releases can be pulled into pipelines within minutes of publication.
That same incident showed ~2 hours was enough for detection and removal once it happened.
Three days is emerging as a community-consensus default across tooling.

Implicit premises:

Detection probability rises roughly monotonically with elapsed time since publication.
Attackers will not systematically adapt their timing (e.g., dormant payloads, delayed activation) to outlast a known, fixed public window.
The scanning infrastructure needed to catch releases within three days actually exists and is applied broadly enough to matter for any given package.

Inferences:

If a fixed public delay becomes the default, a patient or well-resourced attacker could design payloads to activate only after the cooldown elapses, which would erode the defense over time — an inference the HN thread gestures at (zihotki) but the article never draws or examines explicitly.

Narratives

A 2020-era incident in which several npm packages collectively downloaded more than 2 billion times a week were replaced with compromised versions and remained live for roughly two hours before detection and removal.
→ Grounds the abstract cooldown policy in a concrete case that shows both the attack pattern (fast, automated pickup of a new release) and the rough timescale (hours, not days) the policy is designed to outlast.

Questions addressed

✅ How can automated dependency-update tools avoid becoming an unwitting vector for fast-moving supply-chain attacks?
Insert a default multi-day delay before proposing non-security updates, giving scanners time to flag malicious releases first.
⭕ Does a fixed, publicly known delay window remain effective once attackers know it exists and can time or delay their payloads accordingly?

Gaps

incompleteThe article never examines whether a fixed, publicly documented three-day window changes attacker economics rather than just attacker timing. A determined, patient adversary who knows the cooldown exists can simply delay a payload's malicious behavior (or the release's promotion/discovery) past three days, converting the defense from a real obstacle into a filter that only catches unsophisticated or rushed attacks. Neither Cherry nor the article's own framing engages this beyond the brief, unresolved HN exchange between zihotki and woodruffw — the closest it gets to acknowledging the limit is woodruffw's caveat that three days is 'a relatively short delay.'
Read next: Look for analysis of adaptive/patient supply-chain attacks (dormant payloads, delayed activation, sleeper dependencies) and for any post-launch data on how cooldown adoption actually shifted detection rates or attacker behavior.
incompleteNo quantitative evidence is offered for the policy's effectiveness beyond a single anecdote (the ~2-hour 2020 incident) and an assertion of 'community consensus.' There is no base rate for how many historical malicious releases would actually have been caught within three days versus requiring a longer or shorter window, so the choice of exactly three days reads as a round-number convention rather than a data-derived threshold.
Read next: Look for empirical studies measuring the distribution of time-to-detection for malicious package releases, which would let you evaluate whether three days is well-calibrated or arbitrary.