Plumb

Dependency update cooldown configured

Checks whether the dependency update tool waits a few days after a new release before proposing it.
category
security
weight
4

How Plumb checks this

What is inspected, and how the result is decided.

When a package release is malicious or badly broken, it is usually discovered and pulled within the first few days. Projects that update the moment a release appears are the ones that get caught. A cooldown tells the update tool to wait a minimum number of days before proposing a new version, giving the wider community time to notice problems first. The 2024 xz-utils backdoor targeted exactly this early-adopter window.

Plumb reads the same configuration files as the updater check. In a Dependabot configuration it looks for a cooldown block on each update entry and takes the smallest of default-days, semver-major-days, semver-minor-days, and semver-patch-days. In a Renovate configuration it reads minimumReleaseAge, at the top level or inside packageRules, and takes the smallest value expressed in days.

The check passes when the smallest configured cooldown is at least 3 days. It warns with proportional credit when a cooldown is set but shorter than 3 days, and fails when the updater has no cooldown at all. It is not applicable when no dependency update tool is configured, since that is already reported by the updater check.

Doing it well

Why this matters

Update bots are good at bringing in new releases quickly. Sometimes that is too quick. When a package is hijacked and a malicious version is published, the projects that get hurt are the ones that installed it in the first hours or days, before anyone noticed. The same is true of releases that are simply broken.

A cooldown tells your update bot to wait until a release is a few days old before proposing it. Most bad releases are caught and pulled within that window. You still get every update, just slightly later, after the wider community has had a chance to try it first.

What good looks like

The update bot is configured to wait at least 3 days before proposing any new release. Fixes for known vulnerabilities are exempt from the wait, since those address a problem that already exists.

How to do it

Dependabot

Add a cooldown block to each update entry in .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: composer
    directory: /
    schedule:
      interval: weekly
    cooldown:
      default-days: 7
      semver-major-days: 14
      semver-minor-days: 7
      semver-patch-days: 3

Dependabot's security updates are handled separately from version updates and are not delayed by this setting.

Renovate

Set minimumReleaseAge in renovate.json:

{
  "extends": ["config:recommended"],
  "minimumReleaseAge": "7 days"
}

You can vary it with packageRules, for example a shorter wait for patch releases:

{
  "extends": ["config:recommended"],
  "minimumReleaseAge": "7 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "minimumReleaseAge": "3 days"
    }
  ]
}

Renovate's vulnerability alerts bypass the minimum release age, so security fixes are not delayed.

Things to watch for

  • Setting a cooldown on one ecosystem only. In Dependabot the cooldown block belongs to each update entry. Add it to Composer, GitHub Actions, and npm alike.
  • A packageRules entry that sets a shorter wait than you meant. The shortest configured value is the one that applies to the packages it matches.
  • Renovate durations are written in words. Use "3 days", not 3.
  • Mistaking schedule for cooldown. A weekly schedule controls when the bot looks. It does not stop the bot proposing a release published an hour ago.

Further reading