How a missing cooldown period happens in Dependabot configs and how to fix it

Introduction

The .github/dependabot.yml file controls how GitHub's Dependabot bot behaves when it scans your dependency manifests and proposes version bumps. It's easy to think of this file as pure automation plumbing — but a missing setting in it can quietly turn Dependabot into a supply-chain liability. In this case, the configuration had no cooldown block on any of its package-ecosystem entries, meaning Dependabot would open pull requests for a package version the moment it was published on the registry, with zero delay.

That gap matters more than it sounds. Newly published package versions are, by definition, the least-vetted code in the entire dependency tree. Malicious actors have repeatedly compromised maintainer accounts or published typosquatted packages that get picked up by automated tooling within hours. Without a cooldown, Dependabot has no built-in defense against being the very automation that pulls a compromised release straight into your CI pipeline.

The Vulnerability Explained

A typical vulnerable dependabot.yml looks like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Notice what's absent: there is no cooldown key anywhere under either updates entry. As soon as a new npm package version or GitHub Action tag is published, Dependabot's scheduler is free to detect it on the very next run and open a PR proposing the bump — sometimes within minutes of the release hitting the registry.

Why this is dangerous in practice:

• Malicious package versions. Attackers who compromise a maintainer's npm token can push a backdoored patch release. If your dependabot.yml has no cooldown, an automated PR proposing that exact malicious version can land in your repo before the community, security researchers, or the registry itself has time to detect and pull it.
• Unstable releases. Even without malice, freshly published versions are more likely to contain regressions. A cooldown-less config means your CI could start testing against (or even auto-merging, if you have merge automation) an untested release the same day it ships.
• Automated exploitation chains. Bots that scan public repos for outdated Dependabot configs can specifically target repositories with no cooldown, timing malicious package publishes to coincide with a project's Dependabot schedule to maximize the odds of an unreviewed merge.

An attacker doesn't need to touch your code at all — they only need to publish a bad version of a dependency you already use, and your own automation does the rest.

The Fix

The remediation is to add a cooldown block to every package-ecosystem entry under updates, setting default-days: 7. This tells Dependabot: "don't propose a version until it has been publicly available for at least 7 days."

Before:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

After:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

Every package-ecosystem block now carries its own cooldown.default-days: 7, so Dependabot's scheduler filters out any version whose publish timestamp is less than seven days old before it even considers opening a pull request. This buys time for:

• Registry-side malware scanning and takedowns to catch compromised releases
• The maintainer/security community to flag broken or malicious versions
• CVE databases and advisory feeds to catch up with newly disclosed issues in the dependency

Because the fix is applied uniformly across every ecosystem entry (not just one), there's no ecosystem left with a silent gap — npm packages and GitHub Actions references are both covered under the same seven-day rule.

Prevention & Best Practices

• Always configure cooldown explicitly. Don't rely on defaults; GitHub's docs recommend setting default-days explicitly so the intent is visible in version control and reviewable in PRs.
• Tune cooldown per ecosystem if needed. High-risk ecosystems (e.g., npm, given its history of supply-chain incidents) can use a longer cooldown than lower-risk ones, using the ecosystem-specific cooldown overrides GitHub supports.
• Pair cooldown with review requirements. A cooldown reduces risk but isn't a substitute for requiring human review/approval on Dependabot PRs before merge, especially for major version bumps.
• Audit your dependabot.yml in CI. Add a linting/Semgrep check (rule: package_managers.dependabot.dependabot-missing-cooldown) to your pipeline so any new package-ecosystem entry added later doesn't silently reintroduce the gap.
• Reference the official docs. GitHub's cooldown configuration option documents both default-days and per-package overrides.

Key Takeaways

• .github/dependabot.yml had zero cooldown settings, meaning both the npm and github-actions update entries could propose brand-new, unvetted package versions instantly.
• The fix adds cooldown: default-days: 7 to every package-ecosystem block, not just one, closing the gap across all ecosystems tracked by Dependabot.
• A missing cooldown is a supply-chain risk multiplier: it turns your own update automation into the delivery mechanism for a compromised or unstable dependency release.
• Cooldown settings should be treated as a required field in any Dependabot config review, not an optional hardening step.
• Automated config linting (e.g., Semgrep's dependabot-missing-cooldown rule) can catch this class of misconfiguration before it ships.

How Orbis AppSec Detected This

• Source: The public package registry feed (npm registry, GitHub Marketplace/Actions releases) that Dependabot polls for new dependency versions.
• Sink: Dependabot's automatic pull-request creation for each package-ecosystem entry in .github/dependabot.yml, with no delay gate before proposing the newest available version.
• Missing control: No cooldown block (default-days) on the npm or github-actions entries under updates, so no minimum age was enforced before a new version could be proposed.
• CWE: CWE-1357 — Reliance on Insufficiently Trustworthy Component.
• Fix: Added a cooldown: default-days: 7 block to every package-ecosystem entry in .github/dependabot.yml, requiring new package versions to be publicly available for at least seven days before Dependabot proposes them.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

Dependency automation is only as safe as its configuration. A dependabot.yml without a cooldown block trusts every new package release the instant it appears on the registry — including the ones that turn out to be malicious, broken, or both. Adding cooldown: default-days: 7 to each package-ecosystem entry is a small YAML change with an outsized security benefit: it gives the ecosystem time to catch bad releases before your CI, and potentially your production environment, ever sees them. Treat cooldown configuration as a mandatory part of your Dependabot setup, not an optional extra.

References

• CWE-1357: Reliance on Insufficiently Trustworthy Component — https://cwe.mitre.org/data/definitions/1357.html
• OWASP Software Supply Chain Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security.html
• GitHub Docs: Configuration options for the dependabot.yml file (cooldown) — https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown
• Semgrep rule reference — https://semgrep.dev/r?q=dependabot-missing-cooldown
• harden: sanitize child_process call in npm-commands.js...