GitHub Introduces Default "Cooldown" Policy for Dependabot Version Updates

GitHub 为 Dependabot 版本更新引入默认“冷却期”策略 - InfoQ

InfoQ 首页 News GitHub 为 Dependabot 版本更新引入默认“冷却期”策略

DevOps

为高风险事件响应构建 AI Agent 评估（8月6日网络研讨会）

GitHub 为 Dependabot 版本更新引入默认“冷却期”策略

2026年7月28日 2分钟阅读

作者：

• Sergio De Simone

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

当新版本依赖项发布时，Dependabot 不再立即创建拉取请求，而是等待三天后才建议升级，从而提高在恶意版本被集成前被识别和移除的可能性。

GitHub 产品经理 Carlin Cherry 通过引用几年前的真实依赖项投毒事件解释了新冷却期策略。当时，多个广受欢迎的软件包（每周下载量总计超过20亿次）被替换为被入侵的版本。尽管这些版本很快被检测并从 npm 移除，但它们在公开期间的约两小时已“足够让自动化更新工具发现新版本、创建拉取请求并提交给您的团队”。

根据 Cherry 的说法：

这种模式正在越来越多的供应链攻击中出现。恶意代码通过全新发布的版本进入，被上传到公共注册表，并在人类或扫描工具查看之前几分钟内就被拉入构建流水线。

为防止此类情况，Dependabot 现在在非安全更新发布后，至少等待三天才会为依赖项更新创建拉取请求。该行为可通过 dependabot.yml 中的冷却期选项进行配置，允许团队根据自身需求进行调整。此冷却期不适用于安全更新，以确保已知漏洞的修复不会被延迟。

Cherry 指出，三天的延迟已成为社区共识，“因此这一默认行为能让 Dependabot 在开发者切换工具时保持一致性”。但需要强调的是，冷却期并不能替代其他供应链攻击防御措施：

因为冷却期仅针对快速传播的情况，它应作为多层防御中的一环。其他建议措施包括：使用锁文件固定依赖项、在 CI 中禁用安装脚本（如可行）、限制构建流水线中的令牌范围，以及在合并前审查更新。

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

三天的延迟似乎刚好能及时发现最严重的问题，避免影响到您的 CI。大多数可疑版本通常在一天或两天内就会在 GitHub 或 Reddit 上被标记，因此等待的时间能让您观察事态发展后再决定是否合并。

在 Hacker News 上，评论者 zihotki 质疑冷却期最终可能变得不再有效，指出“如果每个人都延迟更新”，可能会“减少及时发现漏洞的机会”。对此，用户 woodruffw 认为冷却期背后的安全模型并不依赖终端用户遭遇恶意软件包，而是依赖专门的安全扫描工作：“冷却期的安全假设基于安全扫描方，而非无辜用户成为受害者”。虽然承认三天的延迟相对较短，但他们补充说，这仍然能为这些扫描系统提供足够的预警时间来识别和标记威胁。

作者信息

关于作者

#### 作者信息容器

#### Sergio De Simone

显示更多

显示更少

#### 本文属于 DevOps 主题

##### 相关主题：

• 开发
• DevOps
• 软件供应链
• GitHub
• 安全漏洞
• 依赖管理
• 相关编辑
• 赞助商：使用智能代理 AI 构建最佳应用——结合架构防护措施实现可预测结果
• 赞助商：协作者让单个开发者效率倍增。WaveMaker 让 10 个团队保持一致性。通过架构治理和可预测的结果，实现不同技能水平的开发人员一致性。立即体验 WaveMaker AI。

InfoQ 新闻通讯

每周内容精选，每周二发送。加入超过 25 万名高级开发者的社区。查看示例

我们保护您的隐私。