GitHub 7 月 23 日给 Dependabot 改了一个默认值：非安全版本更新不再第一时间开 PR，而是至少等三天。这个变更看上去像“慢一点”，实际是在承认开源依赖攻击的时间结构已经变了。
过去依赖机器人最大的卖点是快。新版本一发布，机器人就能开 PR，让团队跟上生态。但供应链投毒也吃这套速度。攻击者只需要把恶意版本放进公共 registry，自动更新工具、CI 和镜像构建就可能在人工审查前把它带进项目。GitHub 这次的冷却期不是替代安全审查，而是先把最危险的刚发布窗口错开。
三天不是随手取的数字
GitHub 给出的例子是 2025 年 9 月的 npm 事件：攻击者钓鱼拿到一名维护者凭据，发布了带恶意代码的 chalk、debug 等十几个包版本，这些包合计每周下载量超过 20 亿次。恶意版本大约存活两小时后被社区发现并由 npm 下架。两小时已经算响应很快，但足够自动更新工具发现新版本、打开 PR，甚至进入某些构建流水线。
GitHub Advisory Database 的统计也支持这个判断。截至 2026 年 5 月的一年里，数据库发布了 6500 多条 npm malware advisory，前一年约为 6200 条，折算下来每天大约新增 18 个被记录的恶意 npm 包。GitHub 回顾了 2018 到 2026 年间 21 起被广泛报道的供应链事件，认为 axios、Solana web3.js、ua-parser-js、Ledger Connect Kit 等恶意版本都在发布后数小时内被拉下。三天默认值就是为了让依赖版本先经过这一段社区和扫描器最密集的发现期。
冷却只挡短命投毒
新的默认策略只作用于非安全版本 bump。Dependabot 至少等待三天后再开 PR，项目仍然可以在 dependabot.yml 里设置更短或更长的 cooldown。这个可配置性很重要，因为内部可信包、公网上游依赖和高风险生态不该共用同一个等待窗口。
GitHub 也没有把它包装成万能防御。冷却期针对的是一种快进快出的攻击：恶意版本发布、传播、很快被抓到并下架。它对长期潜伏后门、维护者蓄意破坏、构建系统被攻陷帮助有限。依赖安全仍然要靠 lockfile、CI 中限制 install script、缩小构建令牌权限、合并前审查更新等多层措施。冷却期的价值，是先把最容易被机器人速度放大的路径砍掉。
AI 驱动攻击让默认阻尼更有价值
Hugging Face 7 月披露的安全事件给这个判断提供了另一种背景。它发现一起进入部分生产基础设施的入侵，入口是数据处理管线：恶意 dataset 利用了 remote-code dataset loader 和 dataset 配置里的模板注入路径，在处理 worker 上执行代码，随后升级到节点级访问，获取云和集群凭据，并在多个内部集群之间横向移动。
Hugging Face 说这次活动由 autonomous agent framework 端到端驱动，攻击侧在短命沙箱集群里执行了大量动作；他们用 AI 辅助检测和分析，从超过 17000 条攻击事件记录里重建时间线、提取 IoC、梳理被触碰的凭据。平台披露没有发现公开用户可见模型、数据集或 Spaces 被篡改，容器镜像和已发布包也验证为干净。但这个事件说明，自动化攻击会压缩防守者的观察时间，数据处理、依赖安装和模型运行环境都可能成为入口。
要调的是窗口，不是安全感
Dependabot 的三天冷却期不会让依赖安全突然变简单。它更像一个默认阻尼器：承认自动化更新太快时会替攻击者放大影响，于是在机器人开 PR 前留出一小段外部发现时间。对多数团队来说，这比要求每个仓库都手写复杂策略现实得多。
真正需要调整的是不同依赖的窗口。公开 registry 上高下载量包可以接受更长等待，内部包或紧急兼容修复可以单独缩短；安全补丁则不能和普通版本更新混在一起处理。依赖机器人仍然应该开 PR，但不必总是抢第一秒。现在的工程问题是，哪些更新值得快，哪些更新需要先等一等。