Dependabot: add cooldown period

[jrfnl]

Updating all dependencies immediately after release carries risks as the package may have been compromised. The package may also still have "teething problems", especially for new features. Aside from known security releases, waiting a few days/weeks is often the less risky option, in hopes that someone else find a potential problems before we update the package. This is called a "cooldown" period.

Or as Zizmor describes it:

Performing updates without an appropriate cooldown presents both stability and supply-chain security risks:

• Stability: updating to the newest version of a dependency immediately after its release increases the risk of breakage, since new releases may contain regressions or other issues that other users have not yet discovered.
• Supply-chain security: package compromises are frequently opportunistic, meaning that the attacker expects to have their compromised version taken down by the packaging ecosystem relatively quickly. Updating immediately to a newly released version increases the risk of automatically pulling in a compromised version before it can be taken down.

Of course, for frequently released packages, this cooldown period shouldn't be too long, as otherwise the package will never update, as the "latest" release will always be too young.

Since July 2025, the Dependabot config offers the possibility to add a cooldown period to delay the creation of dependency update PRs based on the number days since the release came out. Depending on the ecosystem, this cooldown period can be configured with more or less flexibility (only default-days or semver based differentiation). Unfortunately, the github-actions ecosystem only allows the default-days option.

Since then (July 2026), GitHub, in their wisdom, has introduced a standard "cooldown" period for all packages of three days. This is counter-productive as that means that the chances of a compromise being found within the first three days have decreased significantly.

The Zizmor tool recommends a cooldown of seven days, which, with increased adoption of zizmor, again decreases the likelihood of a compromise being found before it reaches this package.

With all this in mind, I propose setting a cooldown period of 10 days.

Refs:

• https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/
• https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/
• https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-
• https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates
• https://docs.zizmor.sh/audits/#dependabot-cooldown