Dependabot 版本更新引入默认软件包冷却期

GitHub 为 Dependabot 版本更新引入了默认的软件包冷却期。这一变化确保了新版本在各自的注册表中至少发布三天后，Dependabot 才会开启版本更新的拉取请求（pull request），从而降低了用户在供应链攻击期间自动采用受损软件包的风险。

即时安全更新与延迟版本更新

Dependabot 区分了安全更新和常规版本更新，以确保关键修复不会被延迟。虽然常规版本更新现在面临三天的等待期，但安全更新仍会立即开启。这种机制旨在防止标准发布中引入的恶意代码快速传播，同时确保关键漏洞补丁能够尽可能快地交付。

缓解供应链风险

冷却期作为一个缓冲期，允许社区和自动化扫描器在恶意软件包通过自动化 PR 广泛分发之前检测并报告它们。通过放慢对最新版本的采用速度，GitHub 旨在减少受损软件包发布的爆炸半径。

社区对冷却期有效性的看法

开发者之间的技术讨论引发了关于该冷却期有效性和时机的几点担忧：

• 检测窗口： 一些人认为三天窗口期可能不足，甚至可能适得其反。一位用户指出，恶意攻击者可能会安排在周二发布漏洞利用程序并在周五合并，从而可能在补丁修复能力有限的周末触发有效载荷。
• 报告延迟： 有人担心广泛的冷却期可能会推迟感染的发现。如果更少的用户立即更新，那么关注新代码的人就会更少，从而可能延迟对受损情况的报告。
• 版本更迭： 一些开发者对不断更新的压力表示沮丧，称频繁更新可能比维持一个稳定版本更糟糕。
• “3天 0-day”： 这一转变被戏称为将“0-day”变为“3-day”，突显了保持最新与保持安全之间的内在紧张关系。

生态系统影响与替代方案

一些开发者建议，安全责任应该向注册表本身转移。建议包括对具有高生态系统影响力的软件包（例如下载量达到数百万次的软件包）实施更严格的安全要求，以防止漏洞在最初阶段就进入注册表。

对于那些希望在 Dependabot 之外实现类似冷却策略的人，社区成员指出了像 npm、pnpm 和 yarn 等包管理器的配置方法，以便手动管理更新延迟。