依赖更新越快越好吗？GitHub 正在给自动升级加上“冷静期”

发表于
GitHub 最近连续为 Dependabot、恶意包告警和 Actions 增加安全闸门。自动升级为什么开始主动变慢，团队又该如何重做依赖更新流程？

过去几年，依赖管理的目标一直很明确：发现新版本、自动开 Pull Request、测试通过，然后尽快合并。

更新越及时，暴露在旧漏洞中的时间越短。这个逻辑没有错，但它默认新版本是更安全的一端。如果刚发布的版本本身被植入恶意代码，“第一时间升级”反而会让自动化成为攻击者最快的分发渠道。

GitHub 最近做了一个看起来有些反自动化的改动：从 2026 年 7 月 14 日起，Dependabot 的普通版本更新默认等待三天再开 PR。两周后，GitHub 又扩展了恶意包告警，并开始拦住部分可疑的 Actions 工作流，等待人工批准。

我的判断是：依赖更新不应该只追求更快，还需要在发布、发现和执行之间设置时间差与权限边界。 三天冷却期不是安全证明，但它意味着供应链防护开始从“出事后升级”前移到“先不要立刻把未知版本送进生产”。

自动升级解决旧漏洞，也可能引入新攻击

依赖更新面对的是两类方向相反的风险。

第一类是已知漏洞。某个版本已经被确认存在安全问题，修复版也已发布。这时越早升级，风险窗口通常越短。

第二类是新版本风险。维护者账号可能被盗，发布流程可能泄露凭据，一个原本正常的包也可能突然发布恶意版本。此时漏洞数据库、社区分析和下架流程都需要时间。如果机器人在版本发布后几分钟就更新、测试并自动合并，防守方甚至还没有来得及产生告警。

GitHub 的默认策略因此刻意区分了两者：

  • Dependabot version updates，也就是追踪新功能和普通版本的更新，默认冷却三天；
  • Dependabot security updates，也就是修复已知漏洞的安全更新，不受默认冷却期影响，仍然立即创建。

这一区分很重要。冷却期不是“所有更新都等一等”，而是让尚未被充分观察的新版本稍微慢下来，同时不延误已经明确的安全修复。

三天不是魔法数字，而是给风险信号留时间

三天以后，一个包不会自动变得可信。恶意行为可能几个月后才被发现，正常项目也可能在发布后第四天才暴露严重回归。

冷却期真正购买的是一个观察窗口。

在这段时间里，包注册表可以处理举报，安全研究者可以分析异常行为，维护者可以撤回错误版本，GitHub Advisory Database 也可能收到新的恶意包记录。团队并不需要自己完成全部调查，只要不抢在这些信号之前自动合并，就减少了成为第一批受害者的概率。

这个机制很像机场安检后的“静置区”：停留一段时间不能证明行李绝对安全，但如果某件物品已经冒烟，至少不会直接被送上飞机。

GitHub 也允许在 .github/dependabot.yml 中按项目调整窗口。例如，可以让 Major 版本多观察一段时间，Patch 版本保持较短等待，并让某些必须快速跟进的依赖绕过冷却：

1
2
3
4
5
6
7
8
9
10
11
12
13
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 14
      semver-minor-days: 7
      semver-patch-days: 3
      exclude:
        - "your-emergency-dependency"

这里的 14、7、3 只是配置示例，不是适合所有团队的标准答案。真正应该参与决策的是依赖的权限、运行位置、可回滚性和更新收益，而不是只看 SemVer 的版本号。

GitHub 新增的三道闸门，分别挡在不同位置

如果只加冷却期，仍然无法处理已经进入依赖树的恶意版本，也挡不住通过 CI/CD 窃取凭据的攻击。GitHub 在 7 月的三项更新，刚好覆盖了三个不同阶段。

防护 所在阶段 它解决的问题 它不能证明什么
Dependabot 默认三天冷却 新版本进入 PR 之前 避免普通版本更新抢在风险信号之前 三天后的版本一定安全
恶意包告警扩展 依赖已经被识别之后 用 GitHub Advisory Database 与 OpenSSF 数据匹配已知恶意包 发现尚未被收录的攻击
可疑 Actions 工作流审批 工作流真正执行之前 阻止部分可疑工作流直接运行并接触 CI 环境 所有获批工作流都可信

7 月 28 日，GitHub 宣布 Advisory Database 开始吸收 OpenSSF malicious-packages 的数据，为 npm、PyPI 等更多生态提供恶意包记录。如果仓库已经打开 malware alerting，匹配到的新记录会自动产生 Dependabot 告警。

同一天，GitHub Actions 开始自动挂起部分被识别为可疑的工作流。它们不会执行，直到拥有写权限的协作者通过已登录的网页会话审核并批准。这个保护目前只适用于 GitHub.com 上的公开仓库，不适用于 GitHub Enterprise Server。

把三项能力放在一起看，重点不是 GitHub 又增加了几个安全开关，而是防守方式正在改变：等待未知风险暴露、识别已经知道的恶意对象、限制代码真正获得执行权限。 单个信号都不完美，叠在一起才像一套供应链防线。

自动化的危险，不在自动，而在它同时拥有判断和执行权

很多团队已经把依赖更新做成一条无人的流水线：机器人开 PR，CI 跑测试，绿色结果触发自动合并，主分支再自动部署。

我在 Kubernetes 通过 CI 部署的回滚方式 里写过，自动部署至少应该等待运行结果，并在失败时停止或回滚。但供应链风险发生得更早：如果送进部署流程的依赖本身已经被污染，回滚只是止损，不能替代进入主分支前的判断。

这套流程对常规升级非常高效。但测试主要证明新版本没有破坏已有行为，很难证明安装脚本没有窃取环境变量、依赖没有在特定条件下下载额外载荷，也无法判断维护者账号是否刚刚失陷。

如果同一条自动化链路既决定“这个版本可以进入”，又持有发布 Token、云平台凭据和生产部署权限，一次误判就可能穿过整个系统。

所以，供应链安全的重点不只是增加更多扫描器，而是拆开判断权和执行权：

  1. 更新机器人可以提出变更，但不能独自决定合并；
  2. CI 可以验证功能，但只拿到当前任务所需的最小权限；
  3. 发布流程可以部署，但优先使用短期身份而不是长期 Token；
  4. 可疑工作流被拦截时，由能够理解改动的人确认，而不是习惯性点“Approve”。

这也是为什么“CI 全绿”不应该等同于“供应链可信”。功能正确、安全告警和发布来源是三个不同问题，需要不同证据。

一个小团队可以先做这五件事

没有专门安全团队，也不必一开始就建设复杂平台。下面五步已经能明显缩小风险面。

1. 先保留默认冷却期

不要因为 PR 晚三天出现就立即关闭它。先观察更新是否真的有必须当天获得的收益，再为少数依赖单独设置 exclude。对能够执行安装脚本、接触网络或运行在服务端的高权限依赖，可以考虑更长窗口。

2. 把版本更新和安全更新分开处理

普通版本可以等待，已知漏洞修复应该快速响应。给两类 PR 使用不同标签、审查时限和合并规则，避免一套保守策略延误紧急修复，也避免“安全更新很急”成为所有版本自动合并的理由。

3. 审查锁文件里真正发生的变化

一个直接依赖的小版本更新，可能带来一串新的间接依赖。GitHub 的 Dependency Review 能展示 PR 中新增、删除和更新的依赖，也会显示发布日期与已知漏洞。至少要检查包名、版本、发布时间、维护者变化和新增的传递依赖，而不只是 package.json 的一行差异。

4. 收紧 Actions 的执行能力

将 GITHUB_TOKEN 默认设为只读，再为单个 Job 声明必要权限；第三方 Action 尽量固定到完整 Commit SHA。GitHub 的安全文档指出，完整 SHA 目前是把 Action 当作不可变版本使用的唯一方式。

如果工作流要访问云资源，优先用 OIDC 换取短期凭据。这样即使一次 Job 被利用，也不容易带走一个长期有效的部署密钥。

5. 发布自己的包时提供可验证来源

npm 的 Trusted Publishing 可以通过 OIDC 在 CI 与 npm 之间建立信任，减少长期发布 Token；满足条件时还会自动生成 provenance attestation（来源证明）。它不能证明包里没有恶意代码，但可以让使用者核验包从哪个仓库、哪条构建流程发布。

这些措施共同回答的不是“这个包绝对安全吗”，而是更现实的三个问题：它来自哪里、外界观察了多久、进入系统后能拿到多大权限。

安全更新需要快，未知更新需要可控

冷却期当然有代价。新功能和普通修复会晚几天进入项目，安全数据也可能出现漏报与误报。内部私有包如果与公开恶意包重名，Dependabot 甚至可能产生 false positive。任何一个平台开关都不能替代团队对关键依赖的理解。

但这不妨碍一个更稳健的默认值：对已知危险快速修复，对未知新版本保持短暂克制，对即将执行的代码限制权限。

自动化真正成熟的标志，不是所有 PR 都能在无人介入时最快合并，而是系统知道什么时候可以继续，什么时候应该停下来等待更多证据。

依赖更新仍然应该自动化，只是自动化的目标需要从“永远追上最新版”，变成“在可接受的时间内，安全地到达合适版本”。

资料与口径