Ruby Fights Supply-Chain Attacks With Filter Offering 'Cooldown' Before Installing New Packages (rubygems.org)
(Tuesday June 09, 2026 @11:00AM (EditorDavid)
from the what-a-Gem dept.)
Most supply-chain attacks using Ruby's package hosting site " [1]exploit a narrow window ," according to a new blog post form Ruby core maintainer Hiroshi Shibata.
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window."
> The feature was [2]designed in the open , drawing on [3]how other ecosystems approach the same problem . It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
>
> Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in [4]Protecting rubygems.org from the outside in . A dedicated team is running [5]AI-assisted vulnerability scanning against the most critical gems , backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a [6]public roadmap . Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
[1] https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
[2] https://github.com/ruby/rubygems/discussions/9113
[3] https://dev.to/hsbt/should-rubygemsbundler-have-a-cooldown-feature-40cp
[4] https://blog.rubygems.org/2026/04/09/protecting-rubygems-from-the-outside-in.html
[5] https://blog.rubygems.org/2026/04/29/scaling-rubys-defenses-with-ai.html
[6] https://blog.rubygems.org/2026/04/15/rubygems-org-has-a-public-roadmap.html
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window."
> The feature was [2]designed in the open , drawing on [3]how other ecosystems approach the same problem . It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
>
> Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in [4]Protecting rubygems.org from the outside in . A dedicated team is running [5]AI-assisted vulnerability scanning against the most critical gems , backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a [6]public roadmap . Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
[1] https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
[2] https://github.com/ruby/rubygems/discussions/9113
[3] https://dev.to/hsbt/should-rubygemsbundler-have-a-cooldown-feature-40cp
[4] https://blog.rubygems.org/2026/04/09/protecting-rubygems-from-the-outside-in.html
[5] https://blog.rubygems.org/2026/04/29/scaling-rubys-defenses-with-ai.html
[6] https://blog.rubygems.org/2026/04/15/rubygems-org-has-a-public-roadmap.html