Cooldown Support for Ruby Bundler：引入“冷却期”以抵御供应链攻击

背景

Ruby 生态系统长期以来一直面临供应链攻击的威胁，尤其是针对 RubyGems 的利用。这类攻击通常利用一个狭窄的时间窗口：当某个维护者的账户被攻破后，攻击者会立即发布一个恶意版本。在随后的几分钟或几小时内，任何执行 bundle install 的项目都可能直接解析并安装到这个未经审查的恶意版本上。

为了应对这一风险，Bundler 4.0.13 版本引入了名为 Cooldown（冷却期） 的新功能。这是一个基于时间的过滤器，旨在防止解析器在版本发布后的“黄金窗口期”内将其纳入依赖项。该功能的设计是公开透明的，借鉴了其他软件生态系统处理类似问题的经验。它作为现有防御措施（如强制双因素认证 2FA 和可信发布机制）的补充，而非替代，且默认处于关闭状态（Opt-in），允许团队根据自身安全策略灵活启用。

核心内容

工作原理与机制

Cooldown 功能依赖于 rubygems.org 提供的元数据。具体而言，它读取每个 gem 版本在 v2 compact index（v2 紧凑索引）中提供的 created_at 时间戳。

• 时间窗口过滤：如果一个版本的 created_at 时间距今不足设定的天数（N 天），Bundler 在解析依赖时将拒绝解析到该版本，转而选择在该时间窗口之前发布的、经过更长时间审查的版本。
• 兼容性处理：对于未暴露 created_at 时间戳的源（如较旧的 gem 服务器、v2 切换前的历史条目，或仍使用 v1 格式的内部私有注册表），Cooldown 将其视为不在窗口限制内，因此这些版本仍可正常解析。
• 非静默阻塞：Cooldown 不会默默地阻止解析。它仅对能够证明“过于新鲜”的版本进行延迟。如果所有候选版本都在冷却期内，Bundler 会报告被排除的版本数量，并提示用户可以使用 --cooldown 0 强制继续。

配置与使用方法

Cooldown 功能在 Bundler 4.0.13 中提供。对于早期版本的用户，建议先更新 Bundler 并在 lockfile 中锁定该版本，以确保团队环境一致。

1. 基础设置（推荐）

最推荐的设置方式是在 Gemfile 中针对特定源声明冷却期。这种方式随代码提交，确保所有开发者和 CI 环境执行相同的策略。

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

gem "rails"
gem "puma"

• 生效时机：在解析依赖时生效。
  • 若无 Gemfile.lock，运行 bundle install 时应用冷却期。
  • 若已有 Gemfile.lock，运行 bundle update 时重新解析并应用冷却期。
  • 已锁定的版本不受影响，添加冷却期不会改变已确定的依赖版本。
• 默认行为：若未设置冷却期，项目将解析到最新版本。

2. 其他配置方式

除了 Gemfile 中的源级别配置，还可以通过以下方式设置全局或项目级冷却期：

• 项目级配置（存储在 .bundle/config）：

  $ bundle config set cooldown 7
  

• 用户级全局配置：

  $ bundle config set --global cooldown 7
  

• 环境变量（适用于无 lockfile 的新 CI 环境或临时覆盖）：

  $ BUNDLE_COOLDOWN=7 bundle install
  

• 命令行参数（单次运行覆盖）：

  $ bundle install --cooldown 7
  $ bundle update --cooldown 7
  $ bundle add rails --cooldown 7
  

3. 优先级规则

当多种配置同时存在时，Bundler 遵循固定的优先级顺序： 命令行标志 (--cooldown) > 配置设置 (bundle config 或环境变量) > Gemfile 中的源级冷却期。

• 值必须为非负整数（天数）。字符串、浮点数、负数或数组将导致 InvalidOption 错误。

4. 混合源策略

当不同注册表需要不同的安全策略时，可以使用 Gemfile 中的源级配置进行差异化设置。例如，对公共源启用冷却，而对可信的内部源禁用：

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

source "https://gems.internal.example.com", cooldown: 0 do
  gem "internal-tool"
end

• cooldown: 0 使内部源永久豁免冷却限制。
• 注意：命令行 --cooldown N 会覆盖所有源的设置，包括豁免源。

5. 紧急退出机制（Escape Hatch）

在某些紧急情况下（如修复被积极利用的 0-day 漏洞或紧急安全披露），等待冷却期可能不是最佳选择。此时可以使用 --cooldown 0 或 BUNDLE_COOLDOWN=0 来临时禁用冷却期，强制解析到最新版本。

• 当所有候选版本都在冷却期内时，Bundler 会停止并提示用户。
• 使用 --cooldown 0 允许用户在不永久移除策略的情况下获取最新修复。

6. 查看被延迟的版本

bundle outdated 命令现已支持冷却期感知。它会标注那些较新但仍在冷却期内的版本，并显示剩余等待天数，从而区分“已更新”和“故意等待”的状态：

$ bundle outdated --cooldown 7
Gem              Current     Latest          Requested  Groups
aws-partitions   1.1251.0    1.1256.0 (cooldown 3d) = 1.1251.0 default

关键要点

• 防御目标：专门针对账户被盗后恶意版本发布的短暂时间窗口，防止自动解析到未经审查的新版本。
• 实现机制：基于 rubygems.org v2 compact index 提供的 created_at 时间戳，在客户端（Bundler）进行时间过滤。
• 安全性补充：不替代 2FA 或可信发布，而是作为纵深防御的一环，与 rubygems.org 的服务端验证（如推送时内容校验、密码泄露检查）形成互补。
• 灵活性：
  • 默认关闭，不影响现有项目。
  • 支持项目级、全局、环境变量及命令行多种配置方式。
  • 支持针对不同源设置不同的冷却策略。
• 兼容性：对不支持 created_at 的旧源或私有注册表自动降级处理，确保解析不中断。
• 紧急覆盖：提供 --cooldown 0 作为紧急通道，用于处理高危漏洞修复等需要立即升级的场景。
• 透明度：bundle outdated 清晰展示被冷却的版本及剩余时间，避免混淆。

意义与影响

1. 提升 Ruby 生态系统的供应链安全韧性

Cooldown 功能的引入标志着 Ruby 生态系统在应对供应链攻击方面迈出了重要一步。通过引入“时间”这一维度，它有效地增加了攻击者的操作难度和时间成本。即使攻击者成功发布了恶意版本，只要冷却期设置得当，大多数项目在默认情况下不会立即受到感染，为安全团队提供了宝贵的响应时间。

2. 客户端与服务器端防御的协同

该功能并非孤立存在，而是 rubygems.org 整体安全战略的一部分。rubygems.org 在服务端实施了内容校验、密码泄露检查（Have I Been Pwned）以及 AI 辅助的漏洞扫描（由 Alpha Omega 和 Anthropic 支持）。Cooldown 作为客户端过滤器，利用了服务端提供的元数据（created_at），形成了“服务端验证 + 客户端延迟”的协同防御体系。这种分层防御策略显著提高了攻击门槛。

3. 推动行业最佳实践

Cooldown 的设计借鉴了其他生态系统的经验，并在 Ruby 社区中公开讨论。这种开放的设计过程有助于确立行业最佳实践。通过提供细粒