Dependabot别一发布就升级：冷却期先挡住恶意版本窗口

要配置 Dependabot 冷却期，在默认分支的 .github/dependabot.yml 中，为每个 updates 条目设置 package-ecosystem、directory、schedule.interval 和 cooldown.default-days。GitHub 的版本更新指南以 npm、Docker 和 GitHub Actions 为例，说明三个生态可以在同一文件中分别配置，并针对默认分支提出更新 PR。

依照GitHub 的参数说明，普通版本更新即使未显式配置也默认等待三天；把 default-days 设为七天可延长这段等待，而安全更新不受冷却期影响。冷却期按新版本的发布时间计算，schedule.interval 决定 Dependabot 何时再次检查；版本达到设定天数，并不意味着当天一定出现 PR。

一份配置覆盖三个生态

下面是假设 package.json 和 Dockerfile 位于仓库根目录、GitHub Actions 工作流位于 .github/workflows 的配置示例。将以下内容按行写入 .github/dependabot.yml；这里采用 YAML 的行内映射写法，让每个生态的检查频率、冷却天数和普通版本更新 PR 上限集中在一行。

version: 2

updates:

- {package-ecosystem: "npm", directory: "/", schedule: {interval: "daily"}, cooldown: {default-days: 7}, open-pull-requests-limit: 3}

- {package-ecosystem: "docker", directory: "/", schedule: {interval: "weekly"}, cooldown: {default-days: 7}, open-pull-requests-limit: 2}

- {package-ecosystem: "github-actions", directory: "/", schedule: {interval: "weekly"}, cooldown: {default-days: 7}, open-pull-requests-limit: 2}

npm 条目的 daily 表示在工作日检查；Docker 和 GitHub Actions 条目的 weekly 表示每周检查。三个条目都要求新版本先经过七天冷却，但各自按自己的日程运行。假设某个版本刚过冷却期时，该生态本周的检查已经结束，Dependabot 会等到下一次检查才考虑它。

directory 指向依赖定义文件所在位置。npm 项目的 package.json 若放在子目录，就要把 npm 条目的“/”改成该目录；根目录的 Dockerfile 对应 Docker 条目的“/”。GitHub Actions 使用 directory: "/" 时，Dependabot 会查找 .github/workflows 中的工作流，因此不必把工作流目录直接写进这个字段。每个生态单独设定冷却期，也便于以后只调整其中一类更新。

七天为什么常被选中，代价又是什么

2026 年 9 月的早期采用研究发现，在持续使用冷却期的 251 个生态配置中，97.2% 设置了通用延迟，其中 64.3% 选择七天；在能够判断动机的 92 次采用中，83 次与安全顾虑有关。研究关注的是受关注开源仓库的配置和采用动机，并没有测出恶意版本通常需要几天才会被发现。

七天因而是有采用数据可参照的起点，不是经过验证的安全阈值。自动更新可能在维护者或社区察觉异常前传播恶意发布；冷却期让刚发布的普通版本暂时无法进入 Dependabot 的版本更新流程，为发现问题留出时间。若恶意版本在等待结束后仍未被识别，冷却期本身不会判断代码是否安全。

天数越短，正常修复和新功能越早进入审查，留给外部发现异常发布的时间也越少；天数越长，普通更新越慢。配置选择还要连同检查周期看：工作日检查的 npm 条目通常比每周检查的条目更快遇到已经过期的候选版本。如果维护者希望对某类更新留出更长的兼容性评审时间，npm 还可在通用天数之外设置 semver-major-days 等规则；这属于维护策略，不能把较长等待直接等同于更强的恶意包检测能力。

间接依赖与紧急安全修复分开处理

普通版本更新默认维护清单中明确声明的直接依赖。不要在 npm 条目里加入 allow.dependency-type: indirect，期待它为所有间接依赖的新版本逐个开 PR：该取值支持的生态列表不包含 npm。npm 项目中的间接依赖通常记录在 package-lock.json 等锁文件里；锁文件含有已知漏洞依赖时，它可以进入已启用的 Dependabot 安全更新流程。这与为每个间接依赖提供普通版本更新是两回事。

若仓库已启用 Dependabot 安全更新，相应的安全 PR 无须等待示例中的七天。出现已知漏洞时，应先看仓库的安全警报和安全更新 PR，再决定是否需要人工升级。冷却期控制普通版本更新的候选资格，不能代替漏洞识别，也不会自动合并一个已经生成的安全 PR。

还有一种情况：维护者急需采用某个新版本，但它没有触发安全更新 PR。可以人工升级，或者只在对应生态的 cooldown 中排除该依赖，例如把原来的设置改为 cooldown: {default-days: 7, exclude: ["具体包名"]}；“具体包名”须替换为真实依赖名。排除意味着这个包不再受该条目的冷却期约束，普通版本更新仍须等下一次计划检查。把整个生态的冷却期取消，会同时缩短其他普通依赖的观察时间。

用 PR 上限和分组减少通知

示例中的 open-pull-requests-limit 限制各生态同时打开的普通版本更新 PR 数量，并非每日通知次数。达到上限后，Dependabot 要等已有 PR 合并或关闭，才能继续提出普通版本更新；安全更新 PR 使用独立上限。npm 的三个、Docker 与 GitHub Actions 各两个只是条件示例，应按维护者实际能审查的积压量调整。

如果 npm 的小版本和补丁版本仍产生太多独立 PR，可在 npm 条目中加入 groups: {routine: {patterns: ["*"], update-types: ["minor", "patch"]}}。这会把符合规则的普通版本更新合并处理，大版本更新继续单独出现；该组规则默认用于版本更新，不会把安全更新 PR 混入例行更新。分组减少 PR 数量，冷却期延后新版本的候选资格，检查频率决定何时查找更新，上限则控制同时打开的 PR 数量。

配置提交后，可在仓库 Dependency graph 的 Dependabot 页面查看受监控的生态及最近检查时间。如果预期的普通更新尚未出现，依次核对依赖文件目录、新版本发布时间、下次检查时间和已打开的 PR 数量。处于冷却期中的版本暂时没有 PR，正是这份延迟配置预期产生的行为。

相关阅读：

• 虚拟补丁不是修复：什么时候先挡攻击，什么时候必须升级
• 发布npm包别再存长期Token：OIDC仍有三道配置门槛
• Elementor Pro漏洞已遭利用：升级后还要排查PHP文件