How missing cooldown periods in Dependabot configuration happen in GitHub Actions and how to fix it

Introduction

In a Node.js library's repository, we discovered a high-severity configuration vulnerability in .github/dependabot.yml at line 3. The Dependabot configuration for the npm package-ecosystem lacked a critical safety feature: a cooldown period. This meant that whenever a new version of any npm dependency was published—even seconds after release—Dependabot would immediately propose an update to adopt it.

This seemingly minor configuration gap creates a significant attack surface. The npm ecosystem has witnessed numerous supply chain attacks where malicious actors compromise legitimate packages or publish typosquatted packages. Without a cooldown period, this library would be among the first to adopt potentially malicious package versions, before the security community has time to identify and report them.

For a Node.js library consumed by downstream projects, this vulnerability is particularly concerning. Any malicious code introduced through a compromised dependency would propagate to all consumers of the library, multiplying the attack's impact across the entire dependency tree.

The Vulnerability Explained

Let's examine the vulnerable configuration in .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    versioning-strategy: increase
    groups:
      # ... group configurations

The problem: This configuration has no cooldown block. When Dependabot runs on its weekly schedule, it checks for newly available package versions and immediately creates pull requests to update them—regardless of how recently those versions were published.

Why This Matters: The Supply Chain Attack Window

The npm ecosystem processes over 1,000 package publishes per hour. Among these legitimate updates, attackers occasionally succeed in:

1. Account compromise: Gaining access to maintainer accounts of popular packages
2. Typosquatting: Publishing packages with names similar to popular libraries
3. Dependency confusion: Publishing malicious packages that shadow internal dependencies
4. Compromised build pipelines: Injecting malicious code during the package build process

When these attacks occur, there's typically a critical window of 24-72 hours before the security community identifies and reports the malicious package. During this window, projects without cooldown periods will happily adopt the compromised version.

Attack Scenario: The Real-World Impact

Consider this specific attack scenario against this Node.js library:

1. Day 0, 9:00 AM: An attacker compromises the npm account for a popular utility package that this library depends on (let's say a package used by one of the dependencies listed in package.json)

2. Day 0, 9:15 AM: The attacker publishes version 2.4.1 of the compromised package containing:
   - Credential-stealing code that exfiltrates environment variables
   - A backdoor that executes commands from a remote server
   - Code that injects malicious scripts into build artifacts

3. Day 0, 9:30 AM: Dependabot's weekly check runs and detects the new version 2.4.1

4. Day 0, 9:35 AM: Without a cooldown, Dependabot immediately creates a PR to update to version 2.4.1

5. Day 0, 10:00 AM: An automated CI/CD pipeline or a developer merges the PR, thinking it's a routine dependency update

6. Day 0, 10:15 AM: The malicious code is now in the library's codebase and will be included in the next release

7. Day 2, 3:00 PM: The security community identifies the compromised package and npm unpublishes it—but the damage is done

8. Downstream impact: Every project that depends on this library now includes the malicious code, creating a cascading supply chain compromise

With a 7-day cooldown, this attack would have been prevented. The security community would have identified the compromise on Day 2, and Dependabot would still be in its cooldown period, never proposing the malicious update.

The Fix

The fix is straightforward but critical. Here's the exact change made to .github/dependabot.yml:

 version: 2
 updates:
   - package-ecosystem: "npm"
     directory: "/"
     schedule:
       interval: "weekly"
+    cooldown:
+      default-days: 7
     open-pull-requests-limit: 10
     versioning-strategy: increase
     groups:

Before and After Comparison

Before (Vulnerable):

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

When Dependabot runs, it proposes updates to packages published at any time, including those released just seconds ago.

After (Secured):

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

Now, Dependabot only proposes updates to package versions that were published at least 7 days ago, creating a safety window for security review.

How This Specific Change Solves the Problem

The cooldown block with default-days: 7 implements a time-based trust boundary:

1. Temporal filtering: Dependabot now filters out any package version published within the last 7 days when checking for updates

2. Community vetting window: The 7-day period allows the npm security team, security researchers, and the open-source community to identify and report malicious packages

3. Automated response time: npm's security team typically responds to reports of malicious packages within 24-48 hours, well within the 7-day window

4. Zero configuration overhead: Once set, the cooldown requires no maintenance and automatically protects against all future updates

The fix is minimal—just 2 lines added—but the security improvement is substantial. This configuration change transforms Dependabot from a potential attack vector into a defense mechanism that respects the wisdom of the security community.

Prevention & Best Practices

1. Always Configure Cooldown Periods

For every package-ecosystem entry in your .github/dependabot.yml, add a cooldown block:

cooldown:
  default-days: 7  # Minimum recommended

Consider longer cooldown periods (14-30 days) for:
- Production-critical systems
- Projects with strict security requirements
- Packages with a history of supply chain attacks in their ecosystem

2. Implement Defense in Depth

A cooldown period is one layer of defense. Complement it with:

Dependency pinning:

{
  "dependencies": {
    "express": "4.18.2",  // Exact version, not ^4.18.2
    "lodash": "4.17.21"
  }
}

Lock file integrity checks:

# In your CI/CD pipeline
- name: Verify lock file integrity
  run: npm ci --audit

Automated security scanning:

# Add to your GitHub Actions workflow
- name: Run security audit
  run: npm audit --audit-level=moderate

3. Monitor Dependabot PRs Carefully

Even with a cooldown:
- Review the changelog and release notes for each update
- Check the package's GitHub repository for recent security issues
- Look for unusual patterns (new maintainers, sudden major version jumps)
- Verify that the package version has been available for at least 7 days

4. Use Static Analysis for Configuration Validation

Implement automated checks for your Dependabot configuration:

// Example test (from the PR's regression test)
const config = yaml.load(fs.readFileSync('.github/dependabot.yml', 'utf8'));

config.updates.forEach((update) => {
  expect(update.cooldown).to.exist;
  expect(update.cooldown['default-days']).to.be.at.least(7);
});

5. Stay Informed About Supply Chain Security

• Subscribe to security advisories for your package ecosystems
• Follow npm security announcements: https://github.com/npm/cli/security/advisories
• Monitor the OpenSSF Scorecard for your critical dependencies: https://securityscorecards.dev/
• Review CISA's guidance on software supply chain security

Security Standards Reference

This vulnerability relates to several security frameworks:

• CWE-1357: Reliance on Insufficiently Trustworthy Component
• OWASP Top 10 2021 - A06:2021: Vulnerable and Outdated Components
• SLSA Level 2: Requires verification of provenance for dependencies
• NIST SSDF: Secure Software Development Framework recommends vetting third-party components

Key Takeaways

• The npm package-ecosystem in .github/dependabot.yml had no cooldown configuration, allowing immediate adoption of newly-published packages without any safety window for security review

• A 7-day cooldown period creates a critical defense layer against supply chain attacks by allowing the security community time to identify and report malicious packages before they reach your codebase

• This vulnerability is particularly dangerous for Node.js libraries because malicious code propagates to all downstream consumers, multiplying the attack surface across the entire dependency tree

• The two-line fix (cooldown: { default-days: 7 }) provides substantial security improvement with zero runtime overhead or maintenance burden

• Static analysis tools like Semgrep can automatically detect missing cooldown configurations through the package_managers.dependabot.dependabot-missing-cooldown rule, enabling proactive security validation

How Orbis AppSec Detected This

• Source: Dependabot configuration in .github/dependabot.yml that controls when package updates are proposed
• Sink: The missing cooldown block in the npm package-ecosystem configuration at line 3, allowing immediate adoption of newly-published packages
• Missing control: No time-based filtering to wait for community security review before proposing updates to new package versions
• CWE: CWE-1357 (Reliance on Insufficiently Trustworthy Component)
• Fix: Added cooldown block with default-days: 7 to enforce a 7-day waiting period before Dependabot proposes updates to newly-published npm packages

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

The missing cooldown period in this Dependabot configuration represented a significant supply chain security risk. While the fix is simple—just two lines of YAML—its impact on security posture is substantial. By enforcing a 7-day waiting period before adopting newly-published packages, this configuration change provides a critical window for the security community to identify and report malicious packages.

For Node.js libraries and any project with downstream consumers, supply chain security isn't optional—it's a responsibility. This vulnerability demonstrates that security isn't just about the code you write, but also about how you manage the code you depend on. A properly configured Dependabot with cooldown periods transforms automated dependency management from a potential attack vector into a security-conscious process that respects the collective wisdom of the open-source security community.

Review your own .github/dependabot.yml configuration today. If any package-ecosystem entry lacks a cooldown block, add one. Your future self—and your users—will thank you.

References

• CWE-1357: Reliance on Insufficiently Trustworthy Component
• GitHub Dependabot Configuration Options - Cooldown
• OWASP Software Component Verification Standard
• Semgrep Rule: dependabot-missing-cooldown
• npm Security Best Practices
• Original Pull Request: fix: this dependabot configuration does not set a co... in...