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

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

The Vulnerability at a Glance

Introduction

The .github/dependabot.yml file is the gatekeeper for how and when your project adopts new dependency versions. In this Node.js library repository, that file was configured with sensible limits — a schedule, an open-pull-requests-limit of 15, and an assigned reviewer — but it was missing one critical safety net: a cooldown period.

Without a cooldown, Dependabot will immediately open a pull request the moment a new package version is published to the npm registry. That sounds helpful, but it creates a dangerous window: the first hours and days after a package release are exactly when supply-chain attackers are most active, and when the security community has had the least time to review what was just published.

Because this is a Node.js library, the risk compounds. A compromised dependency that slips into this project doesn't just affect one application — it affects every downstream consumer who installs this library.

The Vulnerability Explained

What the Configuration Looked Like Before the Fix

Here is the relevant portion of .github/dependabot.yml before the patch (around line 31):

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 15
    assignees:
      - 'bolliy'
    # ← No cooldown block here

The absence of a cooldown block means Dependabot operates with zero delay. The moment a new version of any npm dependency appears in the registry, Dependabot is eligible to open a pull request proposing that version.

Why "Zero Delay" Is a Security Problem

Modern supply-chain attacks against npm packages follow a predictable playbook:

1. Account hijacking: An attacker compromises a maintainer's npm credentials and publishes a malicious version of a legitimate, widely-used package.
2. Typosquatting / dependency confusion: A package with a name similar to an internal or popular package is published with malicious code.
3. Protestware / sabotage: A legitimate maintainer intentionally injects harmful code into a new release.

In all three scenarios, the attack has a short window of maximum effectiveness — the first few hours to days after publication, before npm's security team, community researchers, or automated scanners flag the package. During that window, any project with a zero-cooldown Dependabot configuration is at risk of automatically receiving a PR that, if merged, introduces the malicious code.

Attack Scenario Specific to This Repository

Imagine a popular npm utility this Node.js library depends on. An attacker compromises the maintainer's account on a Sunday evening and publishes version 3.2.1 with a postinstall script that exfiltrates environment variables.

With the old .github/dependabot.yml:
- Dependabot's weekly schedule fires Monday morning.
- It detects 3.2.1 and immediately opens a pull request.
- The assigned reviewer (bolliy) sees a routine dependency bump and merges it.
- The malicious postinstall script now runs in every environment that installs this library.

The npm security team flags the package Tuesday afternoon — but the damage is already done for this project and its downstream consumers.

The Fix

The fix is precisely two lines added to the existing npm package-ecosystem entry in .github/dependabot.yml:

Before

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 15
    assignees:
      - 'bolliy'

After

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 15
    assignees:
      - 'bolliy'
    cooldown:
      default-days: 7

What This Change Does

The cooldown block instructs Dependabot to wait 7 days after a package version is published before it will propose that version as an update. This means:

• A package published Monday will not appear in a Dependabot PR until the following Monday at the earliest.
• During that 7-day window, the npm security team, OSV database, Snyk advisories, and community researchers have time to identify and flag malicious or broken releases.
• The default-days: 7 value applies to all packages covered by this ecosystem entry, unless overridden with package-specific rules.

The cooldown configuration also supports more granular control. For example, you can set longer cooldowns for specific high-risk packages:

cooldown:
  default-days: 7
  semver-patch-days: 3   # Patch versions wait only 3 days
  semver-minor-days: 5   # Minor versions wait 5 days
  semver-major-days: 14  # Major versions wait 2 weeks

This is a non-breaking change — it does not remove any existing Dependabot functionality, does not change which packages are monitored, and does not affect the open-pull-requests-limit or the assignees configuration. It simply adds a mandatory maturation period before a new version is considered for adoption.

Prevention & Best Practices

1. Apply Cooldowns to Every package-ecosystem Entry

If your dependabot.yml manages multiple ecosystems (e.g., npm, docker, github-actions), each entry needs its own cooldown block. A cooldown on the npm entry does not apply to github-actions:

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

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

2. Combine Cooldowns with Branch Protection Rules

A cooldown slows Dependabot down, but it doesn't replace code review. Ensure your repository's branch protection rules require at least one human approval before merging Dependabot PRs, even for patch-level bumps.

3. Enable Dependabot Security Alerts Separately

dependabot.yml controls version updates. Dependabot security alerts (which respond to published CVEs) operate independently and should remain enabled at their default sensitivity. A 7-day cooldown on version updates does not delay security alert PRs for known vulnerabilities.

4. Audit Your Dependency Tree Regularly

Use npm audit or tools like Socket.dev and Snyk to continuously monitor for supply-chain risks beyond what Dependabot covers. These tools can detect suspicious package behaviors (new network calls, new install scripts) that a cooldown alone cannot prevent.

5. Use Lockfiles and Hash Pinning

Commit package-lock.json and consider pinning GitHub Actions to specific commit SHAs rather than mutable tags. This ensures that even if a malicious version is published, your existing builds remain reproducible and unaffected until a deliberate update is made.

Relevant Standards

• CWE-1104: Use of Unmaintained Third-Party Components — the risk of incorporating unvetted external packages
• OWASP A06:2021 — Vulnerable and Outdated Components: Addresses risks from dependencies without proper vetting processes
• SLSA Supply Chain Levels: Recommends provenance verification and controlled update processes for all third-party dependencies

Key Takeaways

• The absence of a cooldown block in .github/dependabot.yml is a concrete, exploitable misconfiguration — not just a theoretical concern. Dependabot will act on brand-new package versions with zero delay.
• A 7-day cooldown (default-days: 7) is the minimum recommended waiting period to allow the security community to identify malicious npm releases before they reach your project.
• This project is a Node.js library, meaning supply-chain compromises here cascade to every downstream consumer — the blast radius of a missed malicious update is significantly larger than for a standalone application.
• open-pull-requests-limit: 15 controls noise, not safety — it was already present in this config but provides no protection against malicious package versions. Only the cooldown block addresses that risk.
• Semgrep can statically detect this misconfiguration in CI/CD pipelines before it reaches production, making it straightforward to enforce as a policy across all repositories in an organization.

How Orbis AppSec Detected This

• Source: The npm registry — newly published package versions that Dependabot polls on its configured weekly schedule
• Sink: The Dependabot version update pull request creation process, triggered immediately upon detecting a new version in .github/dependabot.yml line 25 (the package-ecosystem: "npm" entry) with no waiting period configured
• Missing control: No cooldown block under the npm package-ecosystem entry, meaning zero delay between package publication and PR creation
• CWE: CWE-1104 — Use of Unmaintained Third-Party Components (unvetted newly-published versions)
• Fix: Added cooldown: default-days: 7 to the npm ecosystem entry in .github/dependabot.yml, enforcing a 7-day maturation period before any new package version is proposed

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 — cooldown: and default-days: 7 — closes a real supply-chain risk that many teams overlook. Dependabot is a powerful tool for keeping dependencies current, but without a cooldown period, it can become an automated pipeline for ingesting malicious package versions the moment they appear on the registry.

For Node.js libraries in particular, where a single compromised dependency can affect an entire ecosystem of downstream users, this kind of defense-in-depth configuration is not optional hygiene — it's a fundamental security control. The 7-day window costs almost nothing in terms of update latency, and it buys the security community the time it needs to catch supply-chain attacks before they land in your codebase.

Review your own dependabot.yml files today. If you don't see a cooldown block, you're one malicious npm release away from an automated PR that could introduce an attacker into your supply chain.

References

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