Dependabot 默认冷却期：为什么依赖更新慢三天可能更安全

来源: https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/

GitHub 调整了 Dependabot 版本更新 pull request 的默认节奏：普通版本更新会先等待三天冷却期，然后才创建 PR。这个设置反映了软件供应链安全的现实变化。维护者、研究人员和下游团队需要时间发现恶意版本、错误发布或兼容性问题，避免新包在大量代码库中被自动扩散。

要点：更慢的自动化也可能更安全

对 BTTC 读者来说，这也是选择开发者工具时的重要信号。自动化不应只追求最快，还应提供安全默认值、策略开关和人工审查路径。浏览 BTTC 软件目录 或 BTTC 博客 时，可以用同样标准评估 CI、代码审查、包扫描和生产力工具。

为什么这个默认值现在重要

冷却期并不意味着忽略更新，而是把普通版本升级和紧急安全修复分开。三天窗口能让社区检查包内容，让扫描器发现异常，让维护者发布修复版本，也让团队在收到 PR 时拥有更多上下文。如果所有依赖一发布就自动进入队列，审查者很容易疲劳，自动合并也会变得危险。

三天窗口带来的实际价值

现代应用依赖庞大的开源包图谱。一个项目可能包含直接依赖、传递依赖、构建插件、测试框架和发布工具。过去几年出现的恶意包、被盗维护者账户、意外破坏性更新和注册表污染都说明，速度本身不是安全策略。GitHub 的公告把团队常见经验变成默认防护。

团队应如何调整依赖策略

冷却期在上游发布和下游采用之间创建缓冲。早期使用者的问题报告、维护者的补丁、注册表的移除动作和安全公告，都可能在这段时间出现。但它不能替代漏洞管理，关键 CVE 仍需要快速通道、负责人和紧急部署。

选择工具时应关注什么

团队应把依赖更新分成不同通道：关键安全修复走快速通道，普通补丁和小版本使用冷却期，重大版本升级需要迁移计划和兼容性检查。生产依赖至少需要 CI 通过和人工审查；构建、认证、加密和部署相关包应要求更高审批。

本周可执行清单

评估依赖管理、CI、代码审查或发布自动化工具时，不要只听“更快”。应检查是否支持冷却期、分组规则、严重性路由、审计日志、忽略规则过期和公告链接。好工具应提供清晰默认值和可控例外，而不是把风险隐藏在便利性背后。

常见问题

本周可以检查依赖机器人覆盖哪些生态、检查频率、是否区分安全更新和普通更新，以及谁负责审查队列。若使用自动合并，只让它处理低风险包并确保测试和回滚可靠。还要检查事故预案：如何暂停机器人、固定版本、回滚包、清理缓存和撤销 token。

结论

Dependabot 冷却期会让项目更不安全吗？

不会必然如此。它放慢普通版本更新，但紧急安全修复仍可走快速通道。

依赖机器人适合自动合并吗？

低风险更新在测试充分且可回滚时可以自动合并；高影响依赖应人工审查。

最佳冷却期是多久？

三天是实用默认值，但应根据包的重要性、发布频率、测试覆盖和风险承受能力调整。

额外实施建议

如果团队已经使用 Dependabot 或类似机器人，可以先从一个仓库试点冷却期，并记录 PR 数量、失败率、回滚次数和审查耗时。安全团队还应把关键包列表写入文档，例如认证、加密、部署、构建和遥测相关依赖。这样，自动化工具不仅能减少重复劳动，也能让审查者把注意力放在真正高风险的变化上。

指标与治理

团队还应把冷却期和安全指标结合起来，例如平均更新时间、关键漏洞修复时间、自动合并比例、失败构建数量和回滚次数。只有记录这些指标，才能判断策略是否真的降低风险，而不是只是让队列变慢。