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

The Hidden Risk in Your Dependabot Configuration

Your .github/dependabot.yml file is easy to set up once and forget. It quietly opens pull requests, keeps your dependencies fresh, and generally feels like a solved problem. But there is a subtle misconfiguration that can turn this helpful automation into a supply-chain risk: the absence of a cooldown period.

In this repository — a Node.js library consumed by downstream packages — Semgrep flagged the updates block in .github/dependabot.yml at line 3 because it lacked any cooldown configuration. The fix was two lines. The implications, however, go well beyond those two lines.

The Vulnerability Explained

What was missing — and why it matters

The original .github/dependabot.yml configured Dependabot to monitor the npm ecosystem and automatically open pull requests when new package versions were published. The configuration looked like this (simplified to the relevant section):

# .github/dependabot.yml (before fix)
updates:
  - package-ecosystem: 'npm'
    directory: '/'
    schedule:
      interval: 'weekly'
    reviewers:
      - 'stefcameron'
    versioning-strategy: 'increase'
    # ← No cooldown block here

There is nothing technically wrong with this YAML — it is valid, it works, and Dependabot will happily open PRs. The problem is when it opens them.

When a new version of a package is published to npm, Dependabot can surface it almost immediately on its next scheduled run. That means your repository could receive a PR proposing an update to a package that was published hours ago — before:

• The npm community has had time to audit it
• Automated malware scanners have flagged it
• The package author has confirmed the release was intentional (not a hijacked account)
• Any downstream breakage has been reported

The supply-chain attack scenario

Consider a realistic attack against this specific repository:

1. An attacker compromises the npm account of a popular transitive dependency used by this Node.js library.
2. The attacker publishes a patched version that exfiltrates environment variables or injects malicious code into the build output.
3. Within hours, Dependabot opens a PR in this repository proposing the update.
4. A maintainer — trusting Dependabot's automation — reviews the semver bump, sees a minor version increase, and merges without deep inspection.
5. The malicious version ships as part of this library's next release, reaching every downstream consumer.

This is not a theoretical scenario. The ua-parser-js, event-stream, and node-ipc incidents all followed variants of this pattern. A 7-day cooldown would have given the community time to detect and report the malicious versions before they reached automated update tooling.

Why this library is higher risk

The PR's threat model context notes explicitly: "This is a Node.js library — vulnerabilities affect downstream consumers who use this package." A compromised dependency that makes it into a library's release does not just affect one project — it propagates to every application that installs the library. The blast radius of a missed supply-chain attack here is multiplied by the library's install count.

The Fix

The fix adds exactly two lines to the npm package-ecosystem entry in .github/dependabot.yml:

# .github/dependabot.yml (after fix)
updates:
  - package-ecosystem: 'npm'
    directory: '/'
    schedule:
      interval: 'weekly'
    reviewers:
      - 'stefcameron'
    versioning-strategy: 'increase'
    cooldown:           # ← NEW
      default-days: 7  # ← NEW

Before vs. after

How cooldown works

The cooldown block tells Dependabot to ignore package versions that were published fewer than default-days days ago. When Dependabot runs its weekly scan, it will only surface versions that have been available on npm for at least 7 days. Versions published more recently are silently skipped until the cooldown expires.

You can also set ecosystem-specific or package-specific overrides:

cooldown:
  default-days: 7          # applies to all packages in this ecosystem
  semver-patch-days: 3     # shorter wait for patch releases
  semver-minor-days: 5     # medium wait for minor releases

For this repository, the conservative default-days: 7 is the right starting point — it balances security hygiene with staying reasonably current.

Prevention & Best Practices

Always configure cooldown in new Dependabot setups

Any time you create or review a .github/dependabot.yml file, check that every package-ecosystem entry under updates includes a cooldown block. This applies to npm, pip, maven, nuget, bundler, cargo, composer, and all other supported ecosystems.

Tune cooldown values by ecosystem risk

Different ecosystems have different supply-chain risk profiles. npm has historically been a frequent target due to its size and the prevalence of transitive dependencies. Consider:

• npm / PyPI: default-days: 7 (higher risk ecosystems)
• Maven / NuGet: default-days: 3–5 (lower historical incident rate, but still worth a buffer)
• GitHub Actions: default-days: 7 (action hijacking is a real and growing threat)

Combine cooldown with other Dependabot hardening

Cooldown is one layer. Combine it with:

• ignore rules for major version bumps that require manual review
• groups to batch related updates and reduce PR noise
• Branch protection rules requiring at least one human approval before merging Dependabot PRs
• Dependency review via actions/dependency-review-action in your CI pipeline

Use static analysis to catch misconfigurations early

The Semgrep rule package_managers.dependabot.dependabot-missing-cooldown.dependabot-missing-cooldown detects this exact pattern. Add Semgrep to your CI pipeline or use a tool like Orbis AppSec to scan configuration files alongside application code.

Reference standards

• CWE-1104: Use of Unmaintained Third-Party Components — the closest CWE for uncontrolled dependency ingestion
• OWASP A06:2021 – Vulnerable and Outdated Components: Recommends processes to verify component integrity before adoption
• SLSA Supply Chain Levels: Encourages provenance verification and controlled dependency ingestion as part of supply-chain security posture

Key Takeaways

• The dependabot.yml file for this Node.js library had no cooldown block, meaning Dependabot could immediately propose updates to packages published minutes after a potential supply-chain compromise.
• A 7-day cooldown (default-days: 7) added to the npm ecosystem entry is the minimum recommended buffer to allow the community to detect and report malicious or unstable releases.
• Because this is a library with downstream consumers, a compromised dependency that slips through has a multiplied blast radius — the cooldown protects not just this repo but every project that depends on it.
• Semgrep can detect missing cooldown blocks automatically — this is not a vulnerability that requires manual code review to catch; it can be enforced in CI.
• Cooldown is not a substitute for code review of Dependabot PRs, but it ensures that by the time a PR is opened, the package version has survived at least one week of public scrutiny.

How Orbis AppSec Detected This

• Source: The .github/dependabot.yml configuration file, specifically the npm package-ecosystem updates entry starting at line 3, which controls how Dependabot fetches and proposes dependency updates.
• Sink: The absence of a cooldown block means Dependabot's update proposal logic has no minimum age gate — newly published (potentially malicious) package versions flow directly into PR creation.
• Missing control: No cooldown: default-days value was set, removing the only built-in mechanism Dependabot provides to delay proposals for freshly published packages.
• CWE: CWE-1104 — Use of Unmaintained Third-Party Components (extended here to unvetted/newly published components).
• Fix: Added cooldown: default-days: 7 to the npm package-ecosystem entry in .github/dependabot.yml, introducing a 7-day minimum age requirement before Dependabot proposes any package version update.

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

Two lines of YAML. That is all it takes to add a meaningful supply-chain safety net to your Dependabot configuration. The cooldown: default-days: 7 setting does not slow down your development workflow in any meaningful way — packages that are a week old are still current — but it does ensure that the version Dependabot proposes has had time to be scrutinized by the broader ecosystem.

For a Node.js library with downstream consumers, this kind of defence-in-depth matters. Supply-chain attacks targeting npm are not hypothetical; they are documented, recurring, and increasingly sophisticated. A cooldown period is a low-cost, high-value control that every Dependabot configuration should include from day one.

Audit your own .github/dependabot.yml files today. If you see a package-ecosystem entry without a cooldown block, add one.

References

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