What happened

GitHub is pushing a simple but meaningful change into Dependabot by default: non-security version update pull requests now wait at least three days after a package release is published.

That matters because a growing class of supply-chain attacks depends on speed. A malicious package version lands in a public registry, automated tooling sees the latest release immediately, and the poisoned dependency can make its way into active pull requests before maintainers, scanners, or registry operators have time to react.

GitHub is betting that a short default delay changes that risk profile without forcing teams to stop using automated dependency updates.

What the official source confirms

GitHub’s official blog post says Dependabot now applies a default three-day cooldown before opening non-security version update pull requests. GitHub says the goal is to give maintainers, security researchers, and automated scanners enough time to catch a malicious or compromised release before it reaches downstream repositories.

The post also explains why GitHub chose that default. It points to recent supply-chain incidents involving packages such as chalk, debug, axios, ua-parser-js, and Solana web3.js, where poisoned versions were identified and pulled within hours. GitHub also says its Advisory Database published more than 6,500 npm malware advisories in the year ending May 2026, which it frames as roughly 18 newly cataloged malicious npm packages per day.

GitHub is not presenting the cooldown as a complete defense. The company says it is designed for the fast-moving case where a malicious version ships and gets caught quickly, and it notes that teams should still rely on other safeguards such as lockfiles, scoped tokens, review before merge, and tighter CI controls.

Official source:

• https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/

Why the story is trending on X

This is getting attention on X because GitHub turned a quiet security control into a sharp, easy-to-understand product message. In the official @github post, the company says Dependabot now waits three days before non-security version update pull requests so scanners have time to catch a poisoned release first.

That framing travels well on X because it connects directly to a live developer fear: automation pulling bad packages faster than humans can verify them. The post is also getting visible traction, with about 94,000 views, 275 likes, and measurable repost and reply activity on the public X page at the time of writing.

X discovery source:

• https://x.com/github/status/2091575699073016098

What this means for developers, builders, or product teams

For developers, the biggest takeaway is that dependency automation is becoming more opinionated about timing, not just convenience. The default assumption is no longer that the newest version should be proposed immediately. GitHub is effectively saying that a little delay is often safer than instant freshness.

For engineering teams, this is also a broader signal about software supply-chain design. More tools are likely to adopt policies that slow down default adoption windows, especially for public-registry packages where short-lived compromise is a realistic threat model.

For product teams building developer tools, GitHub’s move is strategically important because it reframes security as a workflow default rather than an optional enterprise add-on. If developers accept short latency in exchange for safer updates, other automation products may need to follow the same pattern.

What remains unclear

The biggest open question is how much friction teams will tolerate before they start overriding the default. A three-day delay is modest, but some fast-moving projects may still see it as too slow for trusted dependencies.

There is also a limit to what this change can solve. GitHub is explicit that a cooldown does little against longer-lived backdoors, maintainer sabotage, or compromises that remain undetected for days or weeks.

And because the default applies to non-security version updates, teams still need to understand how their broader Dependabot configuration behaves across different dependency classes and risk levels.

Sources

• GitHub Blog: https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/
• X discovery post from @github: https://x.com/github/status/2091575699073016098