一句话看懂：GitHub 的 Dependabot 自动依赖更新工具现在默认在发现新版本后等待至少三天才会提交流程 Pull Request，以减缓因供应链攻击导致问题包被快速合并的风险。
事件核心：发生了什么
GitHub 宣布 Dependabot 版本更新引入了一项默认行为变更：从 2026 年 7 月 14 日起，Dependabot 在检测到某个包的新版本发布后，会等待至少三天，才自动创建版本更新的 Pull Request。这一冷却期目前默认生效，无需用户额外配置。需要注意的是，该规则仅适用于版本更新（version updates），而安全更新（security updates）不受影响，依然会立即发起修复请求。用户也可以通过在 .github/dependabot.yml 文件中设置 cooldown 选项来调整等待时长或完全关闭该功能。此默认设置已适用于 github.com 上所有受支持的生态系统的版本更新，并将随 GitHub Enterprise Server 3.23 版本生效。
为什么重要
新发布版本常被攻击者用作供应链攻击的入口——在维护者和社区尚未发现隐患前，一个被篡改或存在漏洞的包就可能通过自动更新流入项目。三天冷却期为社区和扫描工具留出了反应窗口，可以在问题包被大规模集成之前发出警报。这是 GitHub 在面对日益频繁的软件供应链攻击时，采取的一项主动防御措施，而非修复漏洞后的补救。它改变了 Dependabot 从“快速同步”到“谨慎同步”的默认行为逻辑，对整个依赖管理工具链的设计思路也具有参考价值。
对用户/开发者/创作者的影响
对于使用 Dependabot 自动管理依赖的开发者而言，主要影响是版本更新 Pull Request 的创建节奏变慢了。如果过去依赖 Dependabot 在第一时间更新所有小版本，现在需要容忍最多三天的延迟。对于内部开发流程依赖快速迭代的团队，可以考虑调整 cooldown 参数缩短等待时间或直接关闭。对于企业级用户，尤其是运行在生产环境中的项目，这一默认冷却期有助于降低因合并恶意包版本而引发安全事件的风险。目前公开信息显示，该默认设置不会影响安全更新，因此关键漏洞的修复速度不受影响。
值得关注的后续
第一，其他依赖管理工具（如 Renovate）是否会跟进类似的默认冷却机制；第二，冷却期的长短是否会根据包的安全记录、发布时间或社区评级进行动态调整；第三，用户对这一默认变更的接受程度，以及 GitHub 是否会根据反馈在下个版本中调整默认冷却时长或增加更细粒度的策略选项。
