GitHub Dependabot 改规则 安全更新和版本更新终于分开了

用过 Dependabot 的团队应该都有印象：每天早上打开 GitHub，几到十几个 Dependabot PR 等着合并。如果是大项目，这个数字可能更高。PR 多了维护者会疲劳，容易漏掉真正需要关注的安全补丁。

GitHub 最近调整了 Dependabot 的策略，核心是两个变化：按生态系统分组更新，以及默认等待三天后才提版本更新 PR。

分组机制解决了什么问题

过去 Dependabot 的更新频率默认每天一次，所有依赖更新混在一起触发。不管是一个小工具的补丁版本还是一个主流框架的次版本更新，都是同一条流水线。维护者要么全合，要么每个单独看，工作量大且难以区分优先级。

新机制允许按生态系统独立设置更新策略。比如 GitHub Actions 的更新每周一次，Maven 依赖每月一次，各自独立调度。同时安全更新独立于版本更新调度触发——有安全修复的漏洞一披露，Dependabot 就会提 PR，不受分组节奏影响。

配置方式也简单：在 .github/dependabot.yml 里加 groups 字段，指定生态系统和更新频率。官方博客给了示例，GitHub Actions 和 Maven 各一个组，更新频率分别设为 weekly 和 monthly。

三天等待背后的工程考量

另一个值得关注的变化：Dependabot 现在默认等待新版本发布三天后才提版本更新 PR。

原因是供应链攻击。过去出现过攻击者向包管理器发布恶意版本，Dependabot 自动提 PR，维护者合入后项目被感染。三天窗口期让社区有足够时间发现并报告恶意包，降低供应链攻击风险。

安全更新不受这个规则影响——有已知漏洞的修复版本发布后，Dependabot 会立即提 PR。这里的关键前提是依赖图（Dependency graph）和安全警报（Security alerts）必须启用。如果这两个功能没开，安全更新不会触发。

容易被忽略的配置陷阱

真正需要确认的不是"要不要用分组"，而是依赖图和警报是否已启用。

Dependabot 的安全更新依赖 GitHub 的依赖图和漏洞数据库。如果项目在私有仓库且未启用依赖图，安全更新不会自动触达。很多团队配置了 Dependabot 但没开依赖图，结果安全补丁延迟了几天甚至几周才发现。

另一个容易被忽略的点：不同生态系统的分组更新是否支持自定义安全策略。官方文档目前的表述是安全更新独立触发，但如果某个生态系统没有对应的漏洞数据库覆盖（比如一些小众的包管理器），安全更新可能无法正确识别。维护者需要检查自己项目的依赖是否在 GitHub Advisory Database 覆盖范围内。

对于 Java 项目来说，Maven 依赖首次被纳入 Dependabot 的自动更新支持范围是一个实质变化。过去 Maven 项目的依赖更新大多需要手动配置或依赖第三方工具，现在可以直接用 Dependabot 管理了。

一个仍需观察的问题

分组机制和三天等待期降低了日常维护的噪音，但能否真正隔离安全更新与版本更新，取决于项目的基础配置是否完整。对于尚未启用依赖图的仓库，这些新功能的效果会打折扣。

从工程实践来看，这个变化的方向是对的——减少不必要的 PR 噪音，让维护者集中精力处理真正重要的更新。但实际效果还取决于团队是否完成了前置配置，以及 GitHub 的漏洞数据库对所用生态系统的覆盖程度。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）