Cooldown option for bundle update and bundle outdated

[mudge]

@woodruffw’s “We should all be using dependency cooldowns” makes a good case that supporting a cooldown (a window of time between when a dependency is published and when it’s considered suitable for use) when updating dependencies is an effective way to mitigate common supply chain attacks.

npm-check-update supports this natively via its cooldown option, pnpm via its minimumReleaseAge, and Dependabot via cooldown.

Could Bundler support this directly itself when calling the likes of bundle update and bundle outdated?

At the moment, it seems Dependabot separately queries the RubyGems (and private registries’) API to determine the release date for each gem version so I assume this isn’t already readily available via a CLI command.

[hsbt]

Could Bundler support this directly itself when calling the likes of bundle update and bundle outdated?

👋 I'm positive to add this proposal to rubygems and bundler. I think it should be in the settings rather than options like pnpm, what do you think?

FYI: https://docs.renovatebot.com/key-concepts/minimum-release-age/

[mudge]

Would that make it simpler for the cooldown to apply to all applicable commands (rather than having to add a command line flag to individual commands)? If so, and especially if it can be controlled by an equivalent environment variable, that would work for my use case (automatically running bundle update in a scheduled workflow to regularly raise dependency updates).

[hsbt]

I wrote the current my thought for "cooldown" feature: https://dev.to/hsbt/should-rubygemsbundler-have-a-cooldown-feature-40cp

[bdewater-thatch]

but it will be hard to use at the enterprise level when every developers have different bundler config

As someone who is now responsible for figuring this out at $job :) right now we have our main application that we have configured NPM cooldowns for on the project level, but as we grow I can imagine rolling out a company wide policy via MDM or dev bootstrap scripts. I don't care much about individual settings as long as they have this particular one.

[marcbest]

Great article, thank you! As @bdewater-thatch mentioned, I would love to be able to have this feature and be able to push something out company wide to enforce it using MDM. Thank you 🙇

[hsbt]

@marcbest Since the current gemspec's date parameter can accept any value, I think the project you created at rubygems/rubygems.org#6380 will be necessary someday. Thank you.

[mlarraz]

@marcbest I'm curious, what led you to close rubygems/compact_index#183? Seems like there is some loose consensus that an opt-in cooldown feature would not be a bad thing to have.

[marcbest]

@mlarraz I jumped the gun creating #9451 before realising it was a duplicate. Happy to help implement the suggestions from @hsbt's article if the maintainers feel it would be helpful and there's consensus on an approach.

[tilo]

Respectfully, I think cooldowns are beside the point. The real problem isn't the frequency of gem releases — frequent updates are actually a good thing, since they often carry important bug fixes. The real problem is account takeovers and unauthorized releases.

2FA on release/upload or Trusted Publishing already exist, and directly prevent the attack itself, rather than just limiting the damage.

A more effective solution would be to enforce 2FA at the moment of publishing — for example, requiring a second factor when running rake release or gem push. This way, even if someone's credentials are compromised, they can't push a malicious release without also controlling the maintainer's second factor.

Beyond that, 2FA should be mandatory for all RubyGems accounts, not just top gems. The typosquatting attacks mentioned in this article targeted obscure gems precisely because they're less protected — so the long tail is where enforcement matters most.

an additional angle might be to try to scan new gems as soon as they’re uploaded — but a mandatory delay, whether in Bundler or on the server, would do more harm than good.

Opt-in cooldowns are a workaround for a policy gap — if RubyGems enforced 2FA or Trusted Publishing for all gems, new malicious pushes would be blocked at the source. Combined with ongoing scanning to clear out existing bad gems, cooldowns would eventually become unnecessary.

What would it take for RubyGems to make 2FA or Trusted Publishing mandatory for all gem publishers?

[radanskoric]

This is a great proposal and definitely something that should be adopted, but I don't think that is the whole solution:

1. It doesn't address typo squatting or the gem owner having malicious intent (very unlikely on well know gems but possible on obscure small gems).
2. It's possible for maintainers to make a mistake and merge a malicious change unknowingly. (due to being tired or any of the other reasons for human fallibility).

Basically I think that what you propose is definitely part of solution, but the story after publishing also needs improvement and I agree that cooldowns are not the full solution.

[raesene]

I'd say that I don't think dependency cooldown and MFA for publishers is mutually exclusive. MFA isn't a perfect defence (for example in this week's Axios compromise the maintainer has stated they had MFA enabled), so having cooldown as an option allows users to suit their own risk appetite.

[radanskoric]

Building on the article's comment about how the actual value is allowing time for gems to be scanned, I'm wondering if a different mechanism than passage of time would be better. What if security firms and researchers could sign a release as vetted?

The mechanism would allow anyone to sign a release as vetted: another developer or a security company can sign the release after they've done their checks (automated or manual). Everyone else can declare who's signatures they want to wait for before installing. A lot of people might opt to wait for Maicej's Diffend signature before installing. Others might decide they trust their circle of developers they personally know and if any of them sign it, they will proceed to install.

Basically, the idea would be to shift from: "Wait a week and hope that someone will check it.".
To: "Wait until someone from the list of sources I trust has confirmed they checked it."

We might have a small default list of security signers vetted by the RubyGems team so everyone has a core list to start with. If someone wants faster checks, they can add their own trusted sources to their personal list. A large company might use their own security team. Once their signing directly on RubyGems for their own benefit, anyone else can decide to also add them to their trusted list. It might even provide a beneficial incentive to security firms to dedicate resources to becoming a well known source of security signatures, as a marketing avenue for their primary services.

[captn3m0]

Security Teams rarely operate in a vetting model. Calling out a release as safe is a much higher bar than labelling something as "potentially malicious".

PyPi uses the same model: they have an API for security firms to report something as malicious: https://blog.pypi.org/posts/2024-03-06-malware-reporting-evolved/

[radanskoric]

That's a great point. I'm wondering if it's a matter of incentives. Because waiting a week to see if someone else will get burnt is also a matter of incentives: who has the incentive to install the gems early?

[raesene]

Different users will have different risk appetites and incentives, so some users will patch early others would like to be more conservative. Security research companies might also be scanning but unless they're being paid for the service you probably wouldn't want to rely on it.

[stevenwilliamson]

Just adding my strong support for introducing a cooldown feature here.

Much of the ongoing debate seems to centre on the premise that cooldowns or grace periods aren't a silver bullet. From a risk management perspective, very few individual controls are perfectly effective. However, when deployed as part of a defence-in-depth strategy, they provide a meaningful improvement to the overall security posture. Cooldowns have empirically prevented supply chain breaches in the past; in that regard, they are an effective control. I agree they aren't the only solution, but the balance of implementation effort versus security effectiveness is compelling.

The referenced article raises some valid concerns, but I have a few thoughts on those points.

First, regarding the idea that if everyone implements a cooldown it becomes less effective: this assumes uniform implementation. In reality, organisations have varying risk tolerances and will adopt different cooldown windows. More importantly, forcing an attacker to wait increases their dwell time. The longer a malicious payload sits, the broader the window for the community, security researchers, and automated tools to discover it before it is widely deployed.

Second, on the risk of delaying legitimate security updates: while true, there are standard mitigating controls for this. When CVEs are published, they can be scanned for and risk-assessed. Automated tools like Dependabot, for example, can bypass the cooldown period to raise an immediate PR for a critical security fix.

Securing the software supply chain requires a collective industry effort across prevention, detection, and recovery. It's a massive undertaking, and unfortunately, requiring MFA for maintainers won't completely resolve the issue of compromised dependencies on its own. Adding a cooldown feature is a pragmatic, high-value addition to our collective defence toolkit.

[hsbt]

I've drafted an initial design proposal for the cooldown feature. Feedback is welcome.

---

Design: Cooldown option for RubyGems and Bundler (v2)

Configuration

Setting name and unit

cooldown with an integer value representing days. --cooldown 3 means "only consider versions published 3 or more days ago." Disabled by default (opt-in). --cooldown 0 temporarily disables cooldown regardless of other settings.

Cooldown applies uniformly to all gems within a source — per-gem granularity (e.g., gem "rails", cooldown: 7) is intentionally not supported. An attacker can target any gem, so protecting only a subset leaves the rest exposed.

Per-source configuration in Gemfile

Cooldown is specified per source in the Gemfile. This allows private registries to be excluded from cooldown naturally:

source "https://rubygems.org", cooldown: 7
source "https://your.privateserver"  # no cooldown

Sources without a cooldown option are not subject to cooldown checks.

Precedence (highest to lowest)

1. CLI flag: --cooldown 3 (applies to all sources)
2. Bundler config (local > global): bundle config set cooldown 3 (applies to all sources)
3. Gemfile: source "https://rubygems.org", cooldown: 7 (per-source)

For gem install / gem update, configurable via CLI flag or ~/.gemrc. Environment variable BUNDLE_COOLDOWN is also supported for CI/CD use.

Since CLI flag takes the highest precedence, urgent updates (e.g., CVE fixes) can bypass cooldown with bundle update rails --cooldown 0 without changing any configuration.

Behavior

Command	Cooldown applied	Behavior
bundle install (with lockfile)	No	Resolves from lockfile
bundle install (without lockfile)	Yes	Filters candidates during version resolution
bundle update	Yes	Falls back to the newest version satisfying cooldown
bundle add	Yes	Same as bundle update
bundle outdated	Yes	Excludes or marks versions within cooldown period
gem install / gem update	Yes	Version unspecified: fallback. Exact version (-v 8.0.1): error if within cooldown

Versions within the cooldown period are excluded from the candidate set during version resolution — they are treated as if they do not exist. If no candidates satisfy cooldown, resolution fails with an error. Versions already recorded in Gemfile.lock are not subject to cooldown checks.

--cooldown 0 and transitive dependencies

--cooldown 0 disables cooldown for all gems, including transitive dependencies.

An alternative was considered: applying --cooldown 0 only to the specified gem while maintaining cooldown for its transitive dependencies. This was rejected because RubyGems/Bundler resolves dependencies by seeking the newest version satisfying constraints. When a new version of a direct dependency requires a new version of a transitive dependency (e.g., rails 8.0.2 requires activesupport = 8.0.2), cooldown on the transitive dependency would make resolution impossible — even with --conservative.

When using --cooldown 0 for urgent updates (e.g., CVE fixes), combining with --conservative is recommended to minimize changes to transitive dependencies:

bundle update rails --conservative --cooldown 0

Out of scope for initial implementation

• Per-gem cooldown values: Per-source covers the primary use case (private registries). --cooldown 0 serves as the escape hatch for everything else.
• Security update bypass: The package manager does not have CVE awareness. Dependabot and Renovate handle this at the update-tool level.
• semver-level differentiation (e.g., different days for major/minor/patch): Update tools are better positioned for this.

[hsbt]

For example applications that have private (self hosted) gems will want to ignore the cooldown.

I thought the problem would be solved if the Gemfile's cooldown option could be specified per source.

source "https://rubygems.org", cooldown: 7
source "https://your.privateserver"

This would allow us to use gems provided by our internal server immediately. How about this?

[booniepepper]

ピッタリ！ That would really serve the enterprise/private-repo use-case well. It also handles public transitive deps of private deps succinctly.

[tenderworks]

I thought the problem would be solved if the Gemfile's cooldown option could be specified per source.

Ah yes, that makes sense. I think it's a better idea!

[hsbt]

I agree with @bdewater-thatch. Combining with --conservative should be sufficient for most cases to minimize changes to transitive dependencies.

This is consistent with how other bundle update flags like --conservative and --strict work — they apply to the entire resolution, not just the named gem.

[stevenwilliamson]

Per source cooldowns would work for how we would use it, assuming the cooldown does not just factor in the "last" released package, ie to ensure its a rolling delay. Per gem cooldown i can see adds flexibility but complexity.

Dependabot for example has this bug/feature at present, if you have a cooldown of 7 days and a package is released every 2 days (aws boto sdk for example) it will never be suggested for update. dependabot/dependabot-core#14234 for example.