GitHub Adds Three-Day Waiting Period to Dependabot to Block Malicious Package Releases

GitHub has rolled out a new cooldown mechanism in Dependabot that delays pull requests for non-security dependency updates by three days after a release is published. The change aims to narrow a critical window that attackers exploit when malicious code slips into widely-used packages.

The Supply Chain Vulnerability#

The motivation behind the shift stems from real-world incidents where compromised package versions reached millions of developers in minutes. A notorious case involved popular npm packages with billions of weekly downloads being swapped for tainted versions. Although the malicious releases were caught and purged within roughly two hours, that window proved sufficient for automated tools to fetch the new code, generate pull requests, and place it in front of development teams.

GitHub product manager Carlin Cherry framed the underlying threat: "The malicious code rides in on a brand-new release, is published to a public registry, and gets pulled into build pipelines within minutes, before a human or a scanner has even looked at it." This pattern has become increasingly common as attackers race to compromise supply chains at scale.

How the Cooldown Works#

The three-day delay is now the default behavior in Dependabot, though teams can adjust or disable it through the cooldown option in dependabot.yml. Critically, the waiting period does not apply to security patches—fixes for known vulnerabilities are issued immediately, preventing attackers from exploiting disclosure delays.

The three-day window aligns with an emerging consensus among the developer community. As Cherry explained, this timeframe gives security researchers and community scanners enough runway to identify and flag poisoned releases before widespread adoption.

Broader Defense Strategy#

The cooldown is positioned as one layer in a multi-faceted defense. Cherry emphasized that teams should also:

• Pin dependencies using lockfiles
• Disable installation scripts in CI environments where feasible
• Limit token scope in build pipelines
• Review updates before merging

Developers have broadly supported the approach. One Reddit commenter noted that "three days feels about right for catching the worst breakage before it hits your CI. Most dodgy releases get flagged on GitHub or Reddit within a day or two anyway, so the wait gives you time to see the drama unfold before merging anything."