Dependabot 默认三天冷静期：依赖更新不再追求第一时间

明确结论

Dependabot 现在默认等待新版本在包注册表中存在至少三天，再创建常规版本更新 PR；安全更新不受影响，仍会立即创建。这是对软件供应链现实风险的默认策略调整，而不是停止及时修补漏洞。

三天窗口的价值在于让维护者、社区和自动化扫描有时间暴露损坏或被入侵的版本。它降低了“刚发布就自动合并”的风险，但不能替代锁文件审查、测试和来源验证。

核心技术要点

• 默认冷静期只作用于 version updates，不延迟 security updates。
• 该默认值覆盖 github.com 上 Dependabot 支持的全部生态系统，并计划随 GitHub Enterprise Server 3.23 提供。
• 团队仍可在 .github/dependabot.yml 中通过 cooldown 选项修改等待窗口或明确退出。
• 等待依据是版本在注册表中的可用时间，不是对包内容、维护者身份或漏洞状态的安全认证。

适用场景

• 启用了 Dependabot 且存在自动合并流程的应用与基础设施仓库。
• 依赖数量多、更新频繁，难以逐个进行人工供应链审查的团队。
• 希望把常规升级速度与紧急安全修复分开治理的组织。

实践建议

• 检查现有 dependabot.yml 是否已设置 cooldown，避免新默认值与团队原策略叠加后产生误判。
• 保持安全更新的独立高优先级通道，并为常规版本更新保留锁文件差异、测试、许可证和发布者异常检查。
• 对内部包、关键运行时和低风险开发依赖分别设定窗口；需要更快升级时，应记录退出冷静期的业务理由和回滚条件。

局限与风险

• 冷静期只能增加观察时间，无法证明三天后的版本安全，也无法发现尚未公开的供应链攻击。
• 常规缺陷修复会被同步延后；依赖上游快速修复生产故障的仓库可能需要缩短或关闭窗口。
• 规则只约束 Dependabot 的版本更新，不会自动治理其他机器人、手工升级或自建制品源。

延伸阅读

原始资料来自 GitHub Changelog。建议结合官方文档的最新版本核对具体 API、限制和配置。