From da7d46bb5ae9ee3ddeb1046d964b778c8a138706 Mon Sep 17 00:00:00 2001 From: jrfnl Date: Thu, 13 Aug 2026 01:51:05 +0200 Subject: [PATCH] Dependabot: add cooldown period 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. And as I control releases of the `xml-validate` action runner and the reusable workflows in the `PHPCSStandards/.github` repo and those will have their own 10 day `cooldown` for all action runners used within the packages, I'm making an exception for those two packages and will allow those to be updated immediately. 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 --- .github/dependabot.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 7abefcb0e..58a9a8c66 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -23,6 +23,8 @@ updates: update-types: - "minor" - "patch" + cooldown: + default-days: 10 # Handle updates for the orphan gh-pages branch. - package-ecosystem: "github-actions" @@ -42,3 +44,5 @@ updates: update-types: - "minor" - "patch" + cooldown: + default-days: 10