How Dependabot Missing Cooldown happens in GitHub Actions and how to fix it

How Dependabot Missing Cooldown Happens in GitHub Actions and How to Fix It

Summary

A Dependabot configuration in .github/dependabot.yml was missing a cooldown block, meaning dependency updates could be proposed immediately after a new package version was published — including potentially malicious or unstable releases. Adding a cooldown with default-days: 7 ensures a 7-day waiting period before Dependabot opens pull requests for newly published versions, giving the security community time to detect and flag compromised packages.

Introduction

The .github/dependabot.yml file is the heartbeat of automated dependency management in GitHub repositories. It tells Dependabot which package ecosystems to monitor, where manifests live, and how often to check for updates. But a subtle omission in this configuration — the absence of a cooldown block — can quietly turn your automated dependency updater into a vector for supply chain attacks.

In this repository, the Dependabot configuration at .github/dependabot.yml (line 8) was set to check for updates on a daily interval with no cooldown period defined. This means the moment a new package version hit the registry, Dependabot could open a pull request to adopt it — no waiting, no vetting window, no buffer against malicious or broken releases.

This is a high severity finding because supply chain attacks increasingly target the window immediately after a legitimate package is published or a package name is squatted. Without a cooldown, automated tooling can pull those versions into your codebase before anyone has noticed something is wrong.

The Vulnerability Explained

What the Vulnerable Configuration Looks Like

Here is the relevant section of .github/dependabot.yml before the fix:

# .github/dependabot.yml (vulnerable)
updates:
  - package-ecosystem: "npm"  # or pip, bundler, etc.
    directory: "/" # Location of package manifests
    schedule:
      interval: "daily" # Check for updates daily

The schedule.interval: "daily" setting means Dependabot checks for new versions every day. Without a cooldown block, there is zero delay between a package version being published to the registry and Dependabot proposing it in a pull request.

Why This Is Dangerous

Software supply chain attacks have grown dramatically in sophistication. Attackers use several techniques that exploit the "freshly published" window:

1. Typosquatting: Publishing a malicious package with a name similar to a popular one (e.g., lodahs instead of lodash), hoping automated tools pick it up.
2. Account takeover: Compromising a maintainer's registry account and publishing a malicious version of a legitimate, widely-used package.
3. Dependency confusion: Publishing a public package with the same name as an internal private package at a higher version number, tricking package managers into pulling the malicious public version.
4. Protestware / sabotage: A maintainer intentionally introducing malicious code into a new release (as seen with node-ipc and colors in 2022).

In each of these scenarios, the malicious version exists on the registry for a window of time — often hours to a few days — before it is detected, reported, and removed. An automated tool configured with no cooldown can propose (and a developer can merge) that compromised version during that exact window.

The Attack Scenario for This Repository

Consider this concrete scenario:

1. A popular npm package used by this project releases version 3.2.1.
2. At the same time, an attacker has compromised the maintainer's npm account and published a malicious 3.2.1 alongside the legitimate one (or the legitimate 3.2.1 itself contains malicious code).
3. With interval: "daily" and no cooldown, Dependabot opens a PR to update to 3.2.1 within 24 hours.
4. A developer, trusting the automated PR, merges it without deep review.
5. The malicious code executes in CI, in production, or in developer environments.

The 7-day cooldown window is specifically designed to interrupt step 3 — giving the security community, the registry maintainers, and automated malware scanners time to detect and flag the compromised version before it reaches your codebase.

The Fix

What Changed

The fix adds exactly two lines to the updates entry in .github/dependabot.yml:

@@ -9,3 +9,5 @@ updates:
     directory: "/" # Location of package manifests
     schedule:
       interval: "daily" # Check for updates daily
+    cooldown:
+      default-days: 7

Before vs. After

Before (vulnerable):

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

After (fixed):

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7

How This Solves the Problem

The cooldown block instructs Dependabot to wait a minimum number of days after a package version is published before it will propose that version in a pull request. With default-days: 7, any package version published less than 7 days ago will be silently skipped — Dependabot will only open a PR once the version has been available on the registry for at least a week.

This 7-day window is significant because:

• Security researchers monitoring package registries typically detect and report malicious packages within hours to a few days of publication.
• Registry maintainers (npm, PyPI, RubyGems, etc.) can yank or flag compromised versions.
• Automated malware scanners like Socket.dev, Snyk, and others have time to analyze and flag suspicious new releases.
• Community vetting through download counts, issue reports, and public discussion can surface problems.

The default-days key applies to all packages in that ecosystem by default. GitHub's Dependabot documentation also supports semver-patch-days, semver-minor-days, and semver-major-days for more granular control if needed.

Prevention & Best Practices

Always Define a Cooldown in Dependabot Configurations

Every package-ecosystem entry in your dependabot.yml should include a cooldown block. A 7-day default is a reasonable baseline that balances security with keeping dependencies reasonably current:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
      semver-patch-days: 3   # Patch versions can move faster
      semver-minor-days: 5   # Minor versions get a bit more time
      semver-major-days: 14  # Major versions deserve the most scrutiny

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

Additional Supply Chain Hardening Measures

Beyond the cooldown, consider these complementary controls:

1. Pin dependencies to exact versions or commit SHAs — especially for GitHub Actions, where uses: actions/checkout@v4 is less safe than uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683.

2. Enable Dependabot security alerts in addition to version updates — security updates should bypass the cooldown since they address known CVEs.

3. Use a dependency review action in your CI pipeline:
   yaml - name: Dependency Review uses: actions/dependency-review-action@v4

4. Audit your dependabot.yml with static analysis — tools like Semgrep can catch misconfigurations like missing cooldowns before they reach production.

5. Require PR reviews for Dependabot PRs — even with a cooldown, a human review of dependency update PRs adds a final layer of defense.

6. Use allowlists and blocklists in your Dependabot config to restrict which packages can be automatically updated.

Relevant Standards

• CWE-1104: Use of Unmaintained Third-Party Components — broadly applicable to unvetted dependency updates.
• OWASP A06:2021 – Vulnerable and Outdated Components — highlights the risk of both outdated and hastily updated dependencies.
• SLSA (Supply-chain Levels for Software Artifacts) — a framework for supply chain integrity that encourages verifying provenance of dependencies.

Key Takeaways

• The absence of a cooldown block in .github/dependabot.yml is a high severity finding — it's not just a configuration preference but a meaningful supply chain security control.
• interval: "daily" without a cooldown is particularly risky because it maximizes the chance that Dependabot proposes a newly published (potentially compromised) version within hours of it appearing on the registry.
• The 7-day default-days value is a community-tested baseline — it covers the typical detection window for malicious package versions while keeping dependencies reasonably current.
• Every package-ecosystem entry needs its own cooldown block — a cooldown on one ecosystem does not apply to others in the same dependabot.yml.
• Cooldown is distinct from Dependabot security updates — security alerts for known CVEs can still trigger immediate PRs; the cooldown only applies to routine version update proposals.

How Orbis AppSec Detected This

• Source: The .github/dependabot.yml configuration file directly controls when Dependabot proposes dependency updates, making it a direct input into the software supply chain.
• Sink: The package-ecosystem entry at .github/dependabot.yml:8 — specifically the schedule block — triggers Dependabot to open pull requests for newly published package versions with no waiting period.
• Missing control: No cooldown block was present under the updates entry, meaning there was zero delay between package publication and Dependabot proposing the update.
• CWE: CWE-1104 — Use of Unmaintained Third-Party Components (extended to include unvetted newly published components).
• Fix: Added a cooldown: default-days: 7 block to the package-ecosystem entry, introducing a 7-day vetting window before Dependabot opens update PRs.

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

A two-line addition to .github/dependabot.yml — a cooldown block with default-days: 7 — meaningfully reduces your exposure to one of the most active and damaging attack vectors in modern software development: supply chain compromise through newly published packages. Dependabot is a powerful tool for keeping dependencies current, but without a cooldown period, its speed becomes a liability. The fix here demonstrates that supply chain security doesn't always require complex changes; sometimes the most impactful improvements are small, targeted configuration updates that give the security community time to do its job before your automated tooling acts.

Review every package-ecosystem entry in your dependabot.yml files today, and make sure each one includes a cooldown block. It's one of the easiest high-value security improvements you can make to your GitHub repositories.

References

• CWE-1104: Use of Unmaintained Third-Party Components
• OWASP A06:2021 – Vulnerable and Outdated Components
• GitHub Docs: Dependabot cooldown configuration option
• GitHub Docs: Dependabot version updates configuration
• Semgrep rule: dependabot-missing-cooldown
• SLSA Supply Chain Security Framework
• fix: this dependabot configuration does not set a co... in...