别被 Dependabot 的自动化给坑了，版本更新其实需要一定的“冷却期”
最典型的风险点在于，很多供应链攻击利用的就是自动化工具的“勤快”。当一个流行包被劫持，恶意代码发布到 npm 或 PyPI 仓库后，通常会有几个小时的真空期。在这个时间窗口内，安全专家可能还没来得及发出警报，但 Dependabot 已经检测到了版本更新并为你提交了 PR。如果你习惯于快速合并，就相当于在没有任何人工审核的情况下，直接把潜在的“毒药”喂进了构建流水线。
很多被撤回的恶意版本，从发布到被社区揪出来通常只需要几小时。但对于自动化工具来说，这两小时足以完成一次完整的扫描并推送更新。为了解决这个痛点，Dependabot 现在对【版本更新（Version Updates）】引入了默认 3 天的冷却期。
这里必须区分两种完全不同的更新逻辑，很多开发者容易把它们混淆：
第一种是“安全更新（Security Updates）”。这类更新针对的是已经记录在案的已知漏洞（CVE）。由于补丁的目的是修复漏洞，其优先级最高，因此依然维持秒级响应。只要安全数据库更新，Dependabot 会立即提醒你升级，因为在这种情况下，不更新的风险远大于更新的风险。
第二种是“版本更新（Version Updates）”。这类更新仅仅是为了追新（例如从 1.2.0 升级到 1.3.0），并不一定涉及安全修复。现在 Dependabot 默认会对这类更新执行 3 天的等待期，也就是说，一个新版本发布后，它会观察 72 小时，确认没有大规模的撤回或安全警告后，才会发起 PR。
这种设计本质上是在用时间换取安全性。在开源生态中，一个包发布后的前 72 小时是风险最高、但也是被审视最激烈的阶段。通过这三天的缓冲，可以过滤掉绝大多数由于劫持而产生的“短命”恶意版本。
当然，如果你觉得默认的 3 天太慢，或者你的项目处于极其保守的阶段，需要更长的观察期，可以通过修改 .github/dependabot.yml 配置文件来手动控制 cooldown-period 参数。
例如，如果你希望将冷却时间缩短至 24 小时，可以这样配置：
version-updates:
dependencies:
- group: "all"
allow: ["*"]
# 将冷却时间自定义为 24 小时
cooldown-period: 24h在实际操作中，建议大多数项目维持默认的 3 天设置。除非你是在维护一个对版本依赖极其敏感的底层库，否则没必要在版本发布的第一时间就冲在最前面。对于大多数业务项目来说，稳定性和安全性永远优先于“版本号的领先”。
