GitHub 在 7 月 14 日的更新里宣布,Dependabot 的版本更新功能默认加入三天冷却期:一个新版本必须在软件源上存在满三天,Dependabot 才会去开自动升级的 PR。这个默认值不需要任何配置就生效,覆盖 github.com 上所有支持的生态系统,安全更新(security updates)不受影响,依旧立即触发。
这不是什么颠覆性功能,但它改的是 Dependabot 运行了多年的底层逻辑——上游一发新版本,Dependabot 立刻开 PR,很多团队还配了自动合并。效率是效率,风险也是风险:一旦某个包的维护者账号被盗、发布了带毒的版本,自动化流水线可能在社区反应过来之前,就已经把恶意代码合并进了成百上千个下游项目。
一个等了五年才落地的默认值
社区里关于"最小包年龄"的功能请求,最早可以追溯到 2021 年 5 月,当时就有人建议对 major、minor、patch 分别设置不同的冷却窗口。这个诉求足足等了五年才变成 GitHub 的默认行为,某种程度上说明供应链安全从"nice to have"变成"必须默认开启"的过程并不快。
配置层面其实比官宣里说的更细。.github/dependabot.yml 里的 cooldown 选项支持 default-days 之外,再单独设 semver-major-days、semver-minor-days、semver-patch-days——你可以让大版本升级等更久,小补丁走快车道。不设置分级字段,就统一按 default-days 走。这个粒度原文的一句话公告里完全没提,但对真正想做风险分级的团队来说,才是能用起来的部分。
3天够不够:GitHub的默认值不是行业上限
冷却期这条思路不是 GitHub 首创,同类工具 Renovate 早就支持类似机制。有意思的是,GitHub 选的默认窗口是 3 天,而企业安全实践里给出的建议往往更保守——Datadog 的安全规则就明确建议依赖冷却期至少设置 7 天。
这个差距值得琢磨。3 天可能是 GitHub 权衡了"安全"和"不要拖慢正常升级节奏"之后的折中,对依赖快速迭代的 SDK 消费方或需要同日跟进上游的兼容性测试项目来说,再长的默认窗口都会变成负担。但对安全团队而言,3 天只是给恶意版本被发现的时间窗开了个头,不是天花板。
默认值给了一个及格线,不是安全上限
企业用户如果按合规要求需要更长的观察期,还是得自己在 cooldown 里把 default-days 调高,或者按 major/minor/patch 分级设置。
这道闸门只管住了一条路
原文和大多数报道都容易让人产生一个错觉:供应链攻击的入口被堵上了。但冷却期只作用于 Dependabot 自动开出的 PR 这一条路径。手动执行 npm install 升级、CI 里重新生成锁文件、其他更新机器人、包管理器直接解析安装依赖——这些路径完全不受这个开关约束,传递依赖(transitive dependency)的安装更是天然在覆盖范围之外。Reddit 上的社区讨论也特意提醒过,不要把它误解成一个覆盖所有安装场景的通用年龄门槛。
- 风险.恶意新版本若尚未被标记为漏洞公告(CVE/advisory),冷却期结束后依旧会被当成普通版本更新合并,"安全更新立即触发"的例外并不能提前拦截未知威胁。
对企业安全团队来说,3 天冷却期值得打开,但不能当成供应链治理的终点。真正的多层防御,还得配合锁文件锁定版本、安装时做最小发布年龄校验、对关键依赖做签名或来源验证——冷却期解决的是"Dependabot 会不会替你踩坑",不是"你的项目会不会踩坑"。