一个 npm 恶意包，2小时毁掉数十亿下载？GitHub 终于给自动升级按下暂停键

GitHub 现在为 Dependabot 版本更新引入了默认“冷却期”（Cooldown）策略。与以往在依赖发布新版本后立即创建拉取请求不同，Dependabot 现在会等待三天后再建议升级，从而提高恶意版本在被集成之前被发现并移除的可能性。

GitHub 产品经理 Carlin Cherry 解释了这一新冷却策略的背景，并指出了几年前发生的一起真实依赖投毒事件。当时，多个广泛使用的软件包被替换为受攻击者控制的恶意版本，这些软件包每周累计下载量超过 20 亿次。虽然这些版本很快就被 npm 检测并移除，但它们在 npm 上存在的大约两个小时，“已经足够让自动更新工具发现新版本、创建拉取请求，并将其提交到你的团队面前”。

Cherry 表示：

这种模式正在成为越来越多供应链攻击的核心方式。恶意代码会随着一个全新的发布版本进入系统，被发布到公共仓库，然后在几分钟内进入构建流水线，而这时人类或者扫描工具甚至还没有查看过它。

为了帮助防止这类情况发生，Dependabot 现在会在新的非安全版本依赖发布后，至少等待三天才创建依赖更新拉取请求。该行为可以通过 dependabot.yml 中的 cooldown 配置项进行调整，让团队根据自身需求定制等待时间。冷却期不会应用于安全更新，从而确保已公开漏洞的修复不会被延迟。

Cherry 指出，三天延迟正在逐渐成为社区共识，“因此这一默认行为可以让 Dependabot 在开发者切换不同工具时保持一致”。

不过，冷却期并不能替代针对其他类型供应链攻击的防御措施：

因为冷却期只能解决快速传播的情况，所以它应该只是多层防御中的一层。其他可以采取的措施包括使用 lockfile 固定依赖版本、在 CI 环境中尽可能禁用安装脚本、限制构建流水线中的 Token 权限范围，以及在合并更新之前进行审核。

Reddit 用户 broaddiscovery_941 进一步强调了三天冷却期的有效性：

三天感觉刚刚好，可以在最严重的问题进入 CI 之前发现它。大多数可疑版本通常会在一两天内被 GitHub 或 Reddit 标记出来，所以等待时间能让你先看看事情的发展，再决定是否合并。

在 Hacker News 上，评论者 zihotki 则质疑冷却期是否会随着时间推移逐渐失效，并指出，如果“所有人都会延迟更新”，那么“及时发现问题的机会可能会减少”。对此，用户 woodruffw 认为，冷却期背后的安全模型并不依赖最终用户自己遇到恶意软件包，而是依赖专门的安全扫描机构：“冷却期背后的安全假设依赖的是安全扫描方，而不是依赖无辜用户成为受害者。”他承认三天时间相对较短，但补充说，这段时间仍然应该足以让这些扫描系统识别并标记潜在威胁。

原文链接：

https://www.infoq.com/news/2026/07/github-dependabot-cooldown/