How Missing Dependabot Cooldown Periods Happen in GitHub Actions and How to Fix It
The Risk of Moving Too Fast
In modern software development, staying on top of dependency updates is critical. But there's a hidden danger: moving too fast. When Dependabot automatically proposes updates to newly published packages without any waiting period, you're essentially trusting the npm registry, PyPI, or any other package manager to have already vetted those packages for malicious intent. That's a dangerous assumption.
In a recent security audit, we discovered that a project's .github/dependabot.yml configuration was missing a crucial safety mechanism: cooldown periods. This meant that the moment a package maintainer published a new version, Dependabot would immediately open a pull request proposing that update—regardless of whether the community had time to identify if the package was compromised, contained malware, or was simply broken.
Understanding the Vulnerability
What exactly is a missing Dependabot cooldown period?
Dependabot is GitHub's automated dependency management tool. It continuously scans your project's dependencies and opens pull requests when new versions are available. By default, without a cooldown configuration, Dependabot will propose updates to any newly published package version immediately.
Here's the original vulnerable configuration from .github/dependabot.yml:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
# Actions used by .github/workflows/build.yml
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
Notice what's missing: there's no cooldown block. This is a significant security gap.
Why is this dangerous?
The npm ecosystem (and other package managers) have been targets of supply-chain attacks. Attackers have published malicious packages under legitimate-sounding names, hoping developers would accidentally install them. In other cases, packages have been compromised after their initial publication when an attacker gained access to a maintainer's account.
Without a cooldown period, here's what could happen:
- Day 1, 10:00 AM: An attacker publishes a malicious version (e.g.,
lodash@4.17.99-malicious) to npm - Day 1, 10:15 AM: Dependabot immediately detects the new version and opens a PR proposing the update
- Day 1, 10:30 AM: A developer, seeing an automated PR from Dependabot (which they trust), approves and merges it
- Day 1, 10:45 AM: The malicious code is now running in your CI/CD pipeline, your production build, or your deployed application
A 7-day cooldown period gives the security community time to:
- Test the package thoroughly
- Report suspicious behavior
- Identify and publicize compromises
- Allow the legitimate maintainer time to revoke and re-publish if needed
Real-world context: In 2021, a compromised ua-parser-js package infected millions of projects within hours because developers trusted automated updates. A cooldown period wouldn't have prevented the attack entirely, but it would have reduced the blast radius significantly.
The Fix: Adding Cooldown Blocks
The fix is straightforward but critical. We added a cooldown block with default-days: 7 to each package-ecosystem entry:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
+ cooldown:
+ default-days: 7
# Actions used by .github/workflows/build.yml
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
+ cooldown:
+ default-days: 7
What does this change do?
The cooldown block with default-days: 7 instructs Dependabot to wait at least 7 days after a package is published before proposing an update to that version. This creates a safety window where:
- Package maintainers can publish security patches if vulnerabilities are discovered
- The security community can analyze and flag suspicious packages
- Your team has time to research and evaluate updates before they're automatically proposed
- Compromised packages can be yanked from registries before reaching your codebase
Why 7 days?
The 7-day window is a community-recommended standard that balances:
- Security: Enough time for the community to identify and report issues
- Practicality: Not so long that you fall dangerously behind on security patches
- Stability: Sufficient time to identify breaking changes or performance regressions
This aligns with best practices from:
- GitHub's official Dependabot documentation
- OWASP recommendations for supply-chain security
- Industry standards for dependency management
Impact of This Fix
After applying this fix, the behavior changes:
| Scenario | Before Fix | After Fix |
|---|---|---|
| Package published on Monday | Dependabot proposes immediately | Dependabot waits until following Monday |
| Malicious package discovered Tuesday | Already in your PR queue | Still waiting—you're protected |
| Security patch released Friday | Immediate PR (might conflict with other updates) | Batched with next week's cycle |
| Zero-day exploit disclosed | You might already be updated to vulnerable version | You have 7 days to respond |
Prevention & Best Practices
To avoid this vulnerability in your projects:
-
Always configure cooldown periods in
.github/dependabot.ymlfor all package ecosystems:
yaml cooldown: default-days: 7 -
Understand your risk profile:
- For critical applications (financial systems, healthcare), consider longer cooldowns (14+ days)
- For internal tools, 7 days is typically sufficient
- For development-only dependencies, you might use shorter periods (3-5 days) -
Combine with other security measures:
- Enable branch protection rules requiring manual approval for dependency PRs
- Useopen-pull-requests-limitto prevent overwhelming your team (as shown in the fix withlimit: 5)
- Implement automated security scanning on all dependency update PRs -
Monitor your Dependabot activity:
- Review which packages are being updated
- Watch for unusual patterns or suspicious packages
- Keep an eye on security advisories for your dependencies -
Use complementary tools:
- Dependabot alerts: Enable GitHub's native vulnerability alerts
- npm audit: Runnpm auditregularly in your CI/CD pipeline
- Snyk: Consider additional supply-chain security scanning
- Socket.dev: Analyze package behavior and detect supply-chain risks
Static Analysis & Automation
This vulnerability was detected using Semgrep, a static analysis tool that can identify missing security configurations in GitHub Actions files. The rule package_managers.dependabot.dependabot-missing-cooldown.dependabot-missing-cooldown specifically looks for Dependabot configurations that lack cooldown blocks.
You can run this check locally:
semgrep --config=p/security-audit .github/dependabot.yml
How Orbis AppSec Detected This
Source: The Dependabot configuration file .github/dependabot.yml at line 4, where the package-ecosystem entries are defined without cooldown specifications.
Sink: The updates section that controls how Dependabot processes package version changes for both npm and github-actions ecosystems.
Missing control: The absence of cooldown blocks means no grace period exists between package publication and Dependabot's proposal to update to that version.
CWE: CWE-1104 (Use of Unmaintained Third Party Components) — the lack of a vetting period for third-party package updates increases the risk of integrating compromised or unstable dependencies.
Fix: Added cooldown: default-days: 7 blocks to all package-ecosystem entries in the updates configuration, establishing a mandatory 7-day waiting period before Dependabot proposes updates to newly published 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.
Key Takeaways
- Never trust package registries blindly: Even automated tools like Dependabot need safety mechanisms to prevent rapid adoption of potentially malicious packages
- Cooldown periods are not optional: A 7-day grace period is a minimal security requirement for any project using Dependabot
- Supply-chain security requires layered defenses: Cooldown periods work best alongside branch protection, security scanning, and manual review processes
- Configuration gaps are security gaps: Missing security settings in infrastructure-as-code files can be as dangerous as missing input validation in application code
- Automation should enable security, not bypass it: Tools like Dependabot are valuable, but they must be configured with security-first defaults
Conclusion
The absence of a cooldown period in Dependabot configurations represents a significant supply-chain security risk. By adding a simple cooldown: default-days: 7 block to your .github/dependabot.yml file, you create a critical safety window that allows the community to identify and report malicious or unstable packages before they're automatically integrated into your codebase.
This fix exemplifies a broader principle in secure software development: automation should enhance security, not bypass it. Dependabot is a powerful tool for keeping dependencies current, but without proper safeguards, it can become a vector for supply-chain attacks.
Review your own .github/dependabot.yml files today. If you see package-ecosystem entries without cooldown blocks, apply this fix immediately. Your security posture depends on it.