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

Introduction

In this repository's .github/dependabot.yml configuration, we discovered a high-severity security misconfiguration at line 4. The Dependabot setup for the npm package ecosystem was missing a critical cooldown block, which meant that any newly published package version—whether legitimate, compromised, or outright malicious—could be immediately proposed as an update.

This matters because supply chain attacks have become one of the most prevalent attack vectors in modern software development. When a bad actor publishes a malicious package version (through typosquatting, account compromise, or dependency confusion), the first 24-72 hours are critical. Without a cooldown period, your automated dependency updates could pull in compromised code before the security community even discovers the threat.

The Vulnerability Explained

The vulnerable configuration looked like this:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "dependencies"
      - "automated"
    commit-message:
      prefix: "chore"
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]

Notice what's missing? There's no cooldown block anywhere in this configuration. This means Dependabot would immediately propose updates to any newly published package version the moment it becomes available on npm.

How Could This Be Exploited?

Consider this attack scenario specific to this configuration:

1. An attacker compromises the npm credentials of a maintainer for one of the project's dependencies
2. They publish a malicious patch version (e.g., lodash goes from 4.17.21 to 4.17.22 with embedded malware)
3. Within minutes, Dependabot detects the new version and opens a pull request
4. A developer, trusting the automated process and seeing it's "just a patch update," merges it
5. The malicious code now runs in CI/CD pipelines, potentially exfiltrating secrets or compromising the build

The ignore block in this configuration only filters out major version updates—patch and minor versions would still be proposed immediately. Since the configuration also auto-labels PRs as "dependencies" and "automated," there's a risk that these updates receive less scrutiny than they should.

Real-World Impact

For this web application (as noted in the threat model context), a compromised dependency could:
- Inject malicious JavaScript that executes in users' browsers (XSS via supply chain)
- Exfiltrate environment variables and secrets during CI/CD runs
- Modify build outputs to include backdoors
- Steal user credentials or session tokens

The Fix

The fix adds a cooldown block to the npm package-ecosystem entry at line 18-19:

Before:

    commit-message:
      prefix: "chore"
    ignore:
      - dependency-name: "*"

After:

    commit-message:
      prefix: "chore"
    cooldown:
      default-days: 7
    ignore:
      - dependency-name: "*"

How This Solves the Problem

The cooldown configuration with default-days: 7 instructs Dependabot to wait 7 days after a new package version is published before proposing an update. This delay provides several critical protections:

1. Community Detection Window: Most malicious packages are discovered and reported within 24-72 hours. A 7-day delay gives the security community time to identify and flag compromised versions.

2. Registry Removal Buffer: npm and other registries typically remove malicious packages quickly once reported. By waiting 7 days, you're unlikely to ever see a PR for a package that's been yanked.

3. Stability Verification: Beyond security, new releases sometimes have critical bugs. A cooldown period lets early adopters discover stability issues before your project is affected.

4. Reduced Attack Surface: Attackers often rely on the speed of automated systems. A cooldown fundamentally breaks the "publish and immediately compromise" attack pattern.

Prevention & Best Practices

Always Configure Cooldown Periods

For every package-ecosystem entry in your dependabot.yml, add:

cooldown:
  default-days: 7

For high-security environments, consider longer periods (14-30 days) for non-critical dependencies.

Additional Dependabot Hardening

1. Use allow lists instead of ignore lists when possible to explicitly control which dependencies can be updated

2. Require manual approval for dependency updates in CI/CD pipelines

3. Enable Dependabot security alerts separately from version updates—security patches may warrant faster adoption

4. Review the diff of every dependency update, not just the PR description

Detection Tools

• Semgrep: Use the package_managers.dependabot.dependabot-missing-cooldown rule to detect this misconfiguration
• GitHub's own security features: Enable repository security settings
• Lockfile auditing: Tools like npm audit and yarn audit can catch known vulnerabilities

Security Standards

This vulnerability relates to:
- CWE-1188: Insecure Default Initialization of Resource
- OWASP Supply Chain Security: Protecting against compromised dependencies
- SLSA Framework: Supply chain Levels for Software Artifacts

Key Takeaways

• Never rely on Dependabot's default behavior for production repositories—always explicitly configure cooldown periods
• The 7-day cooldown in .github/dependabot.yml provides a critical buffer against supply chain attacks targeting the npm ecosystem
• Patch and minor version updates are not inherently safe—this configuration previously allowed immediate adoption of any non-major update
• Automated dependency updates require automated protections—the convenience of Dependabot must be balanced with security controls
• Supply chain attacks exploit trust and speed—the cooldown configuration breaks both attack vectors by introducing delay and encouraging review

How Orbis AppSec Detected This

• Source: The .github/dependabot.yml configuration file at line 4, specifically the package-ecosystem: "npm" entry
• Sink: Dependabot's automatic PR creation for newly published package versions
• Missing control: No cooldown block to delay adoption of newly published packages
• CWE: CWE-1188 (Insecure Default Initialization of Resource)
• Fix: Added cooldown: default-days: 7 to the npm package-ecosystem configuration, ensuring a 7-day waiting period before proposing updates

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

This seemingly small configuration change—adding just two lines to a YAML file—provides significant protection against one of the most dangerous attack vectors in modern software development. Supply chain attacks have compromised major organizations and infected thousands of downstream projects. By implementing a 7-day cooldown period, this repository now has a critical buffer that allows the security community to identify and report malicious packages before they can be adopted.

Remember: automation is powerful, but it must be configured defensively. Every Dependabot configuration should include cooldown periods, and every dependency update should be reviewed with appropriate scrutiny. The convenience of automated updates should never come at the cost of security.

References

• CWE-1188: Insecure Default Initialization of Resource
• GitHub Dependabot Cooldown Documentation
• OWASP Dependency Check
• Semgrep Dependabot Rules
• SLSA Supply Chain Security Framework
• fix: this dependabot configuration does not set a co... in...