GitHub Dependabot Adopts Cooldown to Thwart Supply Chain Attacks
GitHub's Dependabot now defaults to a three-day delay for non-security dependency updates, a move aimed at preventing the automatic inclusion of malicious code in software supply chains.
GitHub has implemented a significant change to its popular Dependabot service, introducing a default three-day cooldown period for non-security dependency version updates. This strategic delay is designed to mitigate the growing threat of supply chain attacks, where malicious code is injected into newly released software packages and rapidly adopted by unsuspecting developers.
The new default behavior, which took effect recently, means that Dependabot will wait at least three days after a new package version is published before automatically creating a pull request for its integration. This pause provides a crucial window for security researchers, automated scanners, and the broader developer community to identify and flag any potentially malicious code before it can be incorporated into production systems. The change was directly influenced by incidents where compromised packages, such as chalk and debug, were exploited within hours of their release, demonstrating the speed at which vulnerable code can propagate.
Dependabot performs two primary functions: security updates and version updates. Security updates, which address known vulnerabilities, will continue to be issued immediately upon detection of a relevant advisory. The new cooldown policy, however, specifically targets version updates, where the goal is to keep dependencies current with the latest releases, irrespective of security concerns. This distinction is critical, as delaying a security patch could leave systems exposed, while delaying a routine version update allows for a necessary vetting period.
GitHub's decision is informed by a pattern observed in numerous supply chain attacks. In many cases, attackers compromise popular open-source packages, publish a malicious version, and see it automatically pulled into build pipelines within minutes. The previous rapid adoption cycle meant that compromised code could be integrated before human review or automated analysis could detect it. The three-day cooldown aims to disrupt this rapid propagation, ensuring that new releases undergo a period of scrutiny.
Data from the GitHub Advisory Database supports the need for such a measure. In the year ending May 2026, the database cataloged over 6,500 npm malware advisories, averaging approximately 18 new malicious packages daily. Analysis of past incidents, including compromised versions of widely used libraries like Axios and Solana web3.js, revealed that malicious code was often detected and removed within hours of publication. A three-day delay would have effectively filtered out the majority of these short-lived malicious releases.
The choice of three days as the default cooldown period represents a balance between mitigating immediate threats and avoiding unnecessary delays in dependency updates. This duration is long enough to surpass the typical window for fast-moving, malicious package releases but not so long as to unduly impede development workflows. This aligns with practices adopted by other community members who have also implemented similar cooldown periods.
While the cooldown is a valuable layer of defense against time-sensitive attacks, GitHub emphasizes that it is not a panacea. It does not protect against more insidious threats like dormant backdoors, maintainer sabotage, or compromised build systems. Therefore, it is recommended as part of a broader defense-in-depth strategy, which includes practices such as pinning dependencies with lockfiles, disabling install scripts in CI environments, scoping build pipeline tokens, and conducting thorough code reviews.
This new default setting is automatically enabled for all users, requiring no manual configuration to activate. Users retain the flexibility to customize the cooldown period via the dependabot.yml configuration file to suit their specific project needs and risk tolerance. GitHub is actively seeking community feedback on the performance of this new feature to further refine its supply chain security measures.