How missing Dependabot cooldown happens in GitHub Actions and how to fix it

Introduction

In this repository's .github/dependabot.yml file, a critical configuration oversight was discovered at line 10. The Dependabot configuration defined two package ecosystems—github-actions and npm—but neither included a cooldown block. This meant that whenever a new version of any dependency was published to the npm registry or GitHub Actions marketplace, Dependabot would immediately create a pull request proposing the update.

This might sound efficient, but it's actually a significant security risk. The first hours and days after a package is published are the most dangerous—this is precisely when supply chain attacks occur, before the security community has time to identify and flag malicious code.

The Vulnerability Explained

Let's examine the vulnerable configuration that was in place:

updates:
  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  # Maintain dependencies for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Notice that both ecosystem entries only specify a schedule with interval: "weekly". There's no cooldown block anywhere in this configuration.

Why This Matters

Supply chain attacks have become one of the most prevalent attack vectors in modern software development. Here's how an attacker could exploit this specific configuration:

1. Typosquatting Attack: An attacker publishes a malicious package with a name similar to a legitimate dependency used by this project (e.g., lodash vs 1odash)

2. Account Compromise: An attacker gains access to a legitimate package maintainer's account and publishes a malicious version

3. Dependency Confusion: An attacker publishes a package to the public npm registry with the same name as an internal package

In all these scenarios, Dependabot would immediately detect the "new version" and create a pull request. If a developer merges that PR without careful review—which happens frequently with automated dependency updates—the malicious code enters the production codebase.

Real-World Attack Scenario

Imagine this project depends on event-stream@4.0.0. An attacker compromises the maintainer's npm account and publishes version 4.0.1 containing a cryptocurrency wallet stealer (this actually happened in 2018). Without a cooldown period:

• Hour 0: Malicious version published
• Hour 1: Dependabot creates PR proposing update to 4.0.1
• Hour 2: Developer sees "patch update" and merges without deep review
• Hour 3: Malicious code is now in production

With a 7-day cooldown, the security community would likely identify and flag the malicious package before Dependabot ever proposes the update.

The Fix

The fix adds a cooldown block to both package ecosystem entries in .github/dependabot.yml:

Before (Vulnerable)

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

After (Secure)

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

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

How This Solves the Problem

The cooldown block with default-days: 7 instructs Dependabot to wait 7 days after a new package version is published before proposing an update. This waiting period provides:

1. Community Vetting Time: Security researchers and the community have time to analyze new releases
2. Malware Detection: Automated scanning services can flag malicious packages
3. Bug Discovery: Early adopters identify critical bugs before your project is affected
4. Rollback Window: Maintainers can yank malicious versions before they spread

Both ecosystems needed this fix because:
- GitHub Actions: Compromised actions can execute arbitrary code in your CI/CD pipeline with access to secrets
- npm: Compromised packages run in your application with full access to your codebase and user data

Prevention & Best Practices

Always Configure Cooldown Periods

For any new Dependabot configuration, include cooldown periods from the start:

cooldown:
  default-days: 7        # Wait 7 days for all updates
  major-days: 14         # Wait longer for major version bumps
  minor-days: 7          # Standard wait for minor versions
  patch-days: 3          # Shorter wait for patches (still risky!)

Additional Supply Chain Defenses

1. Use lockfiles: Always commit package-lock.json or yarn.lock
2. Enable npm audit: Run npm audit in your CI pipeline
3. Pin action versions: Use SHA hashes for GitHub Actions, not tags
4. Review all dependency PRs: Never auto-merge Dependabot PRs
5. Use private registries: Consider proxying public registries through Artifactory or similar

Detection Tools

• Semgrep: The dependabot-missing-cooldown rule catches this exact issue
• Socket.dev: Monitors for supply chain risks in real-time
• Snyk: Scans dependencies for known vulnerabilities

Key Takeaways

• The .github/dependabot.yml file lacked cooldown periods for both github-actions and npm ecosystems, leaving the project vulnerable to supply chain attacks
• A 7-day cooldown provides critical protection against malicious packages that are often detected and removed within the first week
• Both npm and GitHub Actions ecosystems require cooldown configuration—compromised actions are just as dangerous as compromised npm packages
• Weekly update schedules don't provide protection—the schedule only controls when Dependabot checks for updates, not how quickly it proposes newly published versions
• This configuration change has zero impact on legitimate updates—stable packages that have been published for more than 7 days are unaffected

How Orbis AppSec Detected This

• Source: Package registries (npm, GitHub Actions marketplace) where new versions are published
• Sink: The updates entries in .github/dependabot.yml at lines 10 and 17 that would immediately propose updates
• Missing control: No cooldown block was present to delay adoption of newly published packages
• CWE: CWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
• Fix: Added cooldown: default-days: 7 to both the github-actions and npm package ecosystem entries

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

Supply chain security is no longer optional—it's a critical component of any secure software development lifecycle. This Dependabot misconfiguration represented a high-severity vulnerability that could have allowed malicious packages to enter the codebase within hours of being published.

The fix is simple: add a cooldown block with default-days: 7 to every package ecosystem in your Dependabot configuration. This small change provides a crucial buffer against the most common supply chain attack vectors while having zero impact on your ability to receive legitimate updates.

Review your own .github/dependabot.yml files today—if you don't see cooldown blocks, you're at risk.

References

• CWE-829: Inclusion of Functionality from Untrusted Control Sphere
• GitHub Dependabot Configuration Options - Cooldown
• OWASP Software Component Verification Standard
• Semgrep Dependabot Rules
• fix: this dependabot configuration does not set a co... in...