Dependabot 为什么开始故意晚三天升级？最新版本未必最安全

OC 原创示意图。

据 GitHub Changelog 公告，Dependabot 现在会默认等一个新版本在软件包注册表中存在至少三天，再为普通版本升级创建 Pull Request；安全更新不受影响，仍会立即发出。

一句话结论： GitHub 不是认为旧依赖更安全，而是承认软件供应链攻击最危险的窗口，常常就在“新版本刚发布、自动化机器人争相合并”的头几天。

Dependabot 过去代表一种很直觉的工程习惯：有新版就尽快开 PR，测试通过便合并。问题是，自动化更新同样会放大恶意发布的传播速度。维护者账号被盗、构建流程被篡改，或者一个正常版本带着严重缺陷上线时，攻击者最希望看到的正是一批机器人在社区发现异常前把它送进成千上万个项目。

三天冷却期做的事情很朴素：先让新包在注册表、CI、Issue 和使用者环境中“暴露”一段时间。若版本存在后门、崩溃或兼容性问题，社区通常会撤包、标记风险或快速发布修订版。Dependabot 晚一点行动，便有机会绕开最早的爆炸半径。

OC 原创解释图：冷却只针对版本更新，不延迟 Dependabot security updates。

这项默认值并不是所有升级都机械地“晚三天”。Dependabot 仍按照仓库原有的日程检查依赖；如果项目每周才跑一次更新，实际等待时间可能本来就超过三天。GitHub 的配置文档还允许团队在 .github/dependabot.yml 中设置不同窗口，按 major、minor、patch 或指定包分别处理，也可以完全退出冷却。

读者最容易问的是：如果刚发布的版本修复了严重漏洞，岂不是也会被等三天？GitHub 把两条路径分开了。由安全公告触发的安全更新仍然立即创建，默认冷却只作用于“有新版本可用”的常规升级。这个区分很重要，因为版本号变新和安全风险下降并不是同一件事。

当然，三天不是魔法数字。一个维护良好的大型项目，发布候选版和签名流程可能已经提供足够信号；一个冷门包的后门，也可能几周后才被发现。更稳健的供应链策略还要包括锁文件、可复现构建、来源校验、最小化安装脚本权限，以及在合并升级前查看维护者和发布内容是否突然变化。

林岚认为，GitHub 这次最有价值的地方不是替所有项目选中了最佳等待时长，而是改变了自动化的默认方向。以前默认追求“尽快更新”，风险要由团队自己加配置控制；现在默认先观察，确实需要抢新的项目再主动退出。这是一种更符合供应链现实的安全默认值。

对普通开发团队来说，不需要因为这次变化去关闭 Dependabot。更应该做的是检查哪些依赖真的需要当天追新，例如浏览器内核、支付 SDK 或内部同步发布的包；其余依赖让社区先跑三天，通常损失不了什么。软件更新速度是工程指标，但把坏版本送进生产的速度不应该也是。

参考来源

• GitHub Changelog：Dependabot 默认冷却期：官方公告与适用范围。
• GitHub Docs：优化 Dependabot 版本更新 PR：用于核对冷却配置和 1 至 90 天的可配置范围。
• GitHub Docs：Dependabot options reference：用于核对不同包生态和版本类型的配置方式。