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

Introduction

In a repository's GitHub Actions configuration, we discovered a high-severity supply chain vulnerability in .github/dependabot.yml at line 3. The configuration for the npm package ecosystem lacked a critical security control: a cooldown period for newly published package versions. This oversight meant that Dependabot could immediately propose updates to packages published just moments ago—before the security community has any chance to identify if they're malicious, compromised, or unstable.

The vulnerable configuration looked like this:

updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    commit-message:
      prefix: ci

Notice what's missing? There's no cooldown block. This seemingly small omission creates a dangerous window where attackers who compromise package registries or conduct typosquatting attacks can get their malicious code into your repository within minutes of publication.

The Vulnerability Explained

Supply chain attacks have become one of the most effective vectors for compromising software projects. In 2024 alone, we've seen numerous cases where attackers published malicious packages to npm, PyPI, and other registries, hoping that automated dependency tools would quickly adopt them before anyone noticed.

Here's the specific problem with the vulnerable configuration in .github/dependabot.yml:

updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    # ⚠️ NO COOLDOWN PERIOD HERE
    commit-message:
      prefix: ci

When Dependabot runs on its weekly schedule, it checks npm for the latest versions of all dependencies. Without a cooldown period, it will immediately propose updates to packages published just seconds ago. This creates several attack scenarios:

Attack Scenario 1: Compromised Maintainer Account

An attacker gains access to a popular npm package maintainer's account and publishes version 2.5.0 containing malicious code on Monday morning. By Monday afternoon, Dependabot has already opened a PR to update your project to the compromised version. If your team has automated PR merging or quickly approves dependency updates, the malicious code enters your codebase before security researchers have time to analyze the new release.

Attack Scenario 2: Typosquatting with Timing

An attacker publishes a typosquatted package name (e.g., react-domnnn instead of react-dom) and waits. If your team accidentally introduces a typo in package.json, Dependabot without cooldown will immediately start tracking and proposing updates to this malicious package, treating it as legitimate.

Attack Scenario 3: Dependency Confusion

In enterprise environments with private package registries, an attacker publishes a public package with the same name as an internal package but with a higher version number. Without cooldown protection, Dependabot might immediately propose switching to the public (malicious) version.

The real-world impact is severe: malicious code could exfiltrate environment variables (including API keys and secrets), modify build artifacts, establish backdoors, or compromise the entire CI/CD pipeline. Since this is in the production codebase (not test-only code), any malicious dependency would directly affect the application's production behavior.

The Fix

The fix is straightforward but critical. We added a cooldown block to the npm package ecosystem configuration:

Before (Vulnerable):

updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    commit-message:
      prefix: ci

After (Secure):

updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    cooldown:
      default-days: 7
    commit-message:
      prefix: ci

This two-line addition fundamentally changes Dependabot's behavior. Now, when a new version of any npm package is published, Dependabot will wait 7 days before proposing it as an update. This waiting period provides crucial time for:

1. Security researchers to analyze new releases for malicious code
2. The community to test new versions and report stability issues
3. Package maintainers to catch and fix critical bugs in new releases
4. Security scanners to update their databases with new vulnerability information

The 7-day cooldown strikes a balance between security and staying current. It's long enough to catch most supply chain attacks (which are typically detected within 24-72 hours) but short enough that you're not falling too far behind on legitimate updates.

Why This Change Is Effective

The fix works because it introduces a time-based defense layer into your dependency update process. Even if an attacker successfully publishes malicious code to npm, your repository won't be exposed to it immediately. During the 7-day window:

• Security tools like Snyk, Socket, and npm audit have time to analyze the new version
• GitHub's own security advisory database gets updated
• Community members report suspicious behavior
• Automated malware detection systems scan the package

By the time Dependabot proposes the update, the security community has had a full week to identify and report any issues. If the package is flagged as malicious, you'll see security warnings before merging the PR.

Prevention & Best Practices

1. Always Configure Cooldown Periods

Make cooldown configuration a standard part of your Dependabot setup. For every package-ecosystem entry in .github/dependabot.yml, add:

cooldown:
  default-days: 7

For higher-security environments, consider extending this to 14 or even 30 days.

2. Use Multiple Defense Layers

Cooldown periods are just one layer of supply chain security. Combine them with:

• Dependency pinning: Lock to specific versions rather than version ranges
• Software Bill of Materials (SBOM): Track all dependencies and their provenance
• Automated security scanning: Use tools like Dependabot security updates, Snyk, or Socket
• PR review requirements: Never auto-merge dependency updates without human review
• Signature verification: Verify package signatures when available

3. Monitor New Dependencies

Set up alerts for:
- New direct dependencies added to package.json, requirements.txt, etc.
- Unusual patterns in dependency updates (e.g., many updates in a short time)
- Dependencies from new or unknown publishers

4. Implement Package Allowlists

For critical applications, maintain an allowlist of approved packages and versions. Only dependencies on this list can be added to the project.

5. Regular Security Audits

Run npm audit, pip-audit, or equivalent tools regularly. Integrate these into your CI/CD pipeline to catch known vulnerabilities before deployment.

6. Stay Informed

Follow security advisories for your package ecosystems:
- npm: https://github.com/advisories?query=ecosystem%3Anpm
- PyPI: https://github.com/advisories?query=ecosystem%3Apip
- RubyGems: https://github.com/advisories?query=ecosystem%3Arubygems

OWASP Recommendations

This vulnerability aligns with OWASP Top 10 2021 - A06:2021 – Vulnerable and Outdated Components. The OWASP Software Component Verification Standard (SCVS) recommends:

• Verify the integrity of downloaded components
• Use only trusted repositories
• Monitor for security advisories affecting your dependencies
• Implement a time delay before adopting new component versions

Key Takeaways

• Missing cooldown configuration in .github/dependabot.yml line 3 created an immediate supply chain attack window for npm dependencies
• The 7-day cooldown period provides critical time for security researchers to identify malicious or unstable newly published packages before they reach your codebase
• Supply chain attacks target automated dependency tools like Dependabot specifically because they trust newly published packages by default
• This fix required only 2 lines of YAML but significantly reduces supply chain risk by adding a time-based defense layer
• Cooldown periods should be standard practice for all package ecosystems in Dependabot configurations, not just npm

How Orbis AppSec Detected This

• Source: Dependabot version update configuration in .github/dependabot.yml
• Sink: The updates block for the npm package ecosystem (line 3) lacking cooldown configuration
• Missing control: No cooldown block with default-days setting to delay adoption of newly published package versions
• CWE: CWE-1357: Reliance on Insufficiently Trustworthy Component
• Fix: Added a cooldown block with default-days: 7 to enforce a 7-day waiting period before proposing 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

Supply chain security requires defense in depth. While Dependabot is an excellent tool for keeping dependencies up to date, its default behavior of immediately proposing updates to newly published packages creates unnecessary risk. The simple addition of a 7-day cooldown period in .github/dependabot.yml provides a crucial safety window that allows the security community to identify threats before they reach your codebase.

This vulnerability demonstrates that security isn't just about the code you write—it's also about how you configure the tools that manage your dependencies. A two-line configuration change can be the difference between a secure supply chain and a compromised one.

Remember: trust, but verify—and give the community time to verify for you.

References

• CWE-1357: Reliance on Insufficiently Trustworthy Component
• GitHub Dependabot Configuration Options - Cooldown
• OWASP Software Component Verification Standard
• OWASP Top 10 2021 - A06: Vulnerable and Outdated Components
• Semgrep Rule: dependabot-missing-cooldown
• GitHub PR: fix: this dependabot configuration does not set a co... in...