GitHub将暂停不活跃仓库Dependabot告警：12月8日规则与恢复方法

GitHub将从2026年12月8日起，关闭多数过去一年没有活动的仓库的Dependabot告警。已有告警会归档而非删除，仓库收到推送或在设置中重新启用后可以恢复。长期维护但提交不频繁的项目，应先核对仓库活动与组织、企业策略，再决定是否需要调整告警管理方式。

这次调整会影响什么

Dependabot告警用于识别仓库依赖中的已知漏洞，帮助维护者定位受影响文件、查看漏洞严重程度及可用的修复版本。GitHub文档说明，相关扫描针对默认分支，并会在Advisory Database新增漏洞或依赖图变化时生成告警。因此，代码长期不变不等于依赖风险也不变，新披露漏洞仍可能与旧项目有关。

此次公告改变的是长期无活动仓库的告警启用状态及旧告警的保存方式。对于仍在生产使用、作为内部依赖或作为版本参考保留的仓库，建议维护者确认它是否确实属于可停止告警的对象，而不是仅凭近期没有提交就认为无需关注。

哪些操作会被计入一年活动周期

官方明确列出三种活动：向任意分支或标签推送、创建仓库、启用Dependabot告警。规则并不限于默认分支上的提交，向其他分支或标签推送也在公告列明的范围内。对已经暂停告警的仓库，任意一次推送会自动重新打开告警。

另一种恢复方式是在仓库设置中手动启用Dependabot告警。无论采用推送还是手动启用，GitHub都会恢复已经归档的告警，并重新开始一年的计时。这里的恢复是告警重新可见，不代表相关漏洞已经修复；维护者还需要继续评估依赖升级或其他处置。

仓库管理员如何检查与重新启用

按当前GitHub文档，可以先进入仓库主页，打开Settings；如果看不到该标签，可从仓库菜单中查找。随后在侧栏的Security and quality区域进入Advanced Security，在Dependabot alerts项目旁选择Enable。若告警已经开启，则核对当前状态即可，不需要为了刷新计时反复切换设置。

配置文档同时提供个人账户的批量入口：在个人安全设置的Advanced Security区域，对现有仓库使用Enable all；也可以为以后新建的仓库选择默认启用。批量设置前应核对影响范围，避免把仅需处理一个仓库的问题扩展为所有仓库的配置变更。本文提供核对方法，不代表已替用户修改任何仓库。

哪些组织与企业仓库不受自动暂停影响

如果仓库使用了强制执行的安全配置，且该配置启用Dependabot告警，GitHub不会因缺少活动而关闭告警。企业的Dependabot告警策略若不允许仓库管理员自行启用或禁用，相关仓库同样会跳过这次自动关闭规则。关键是实际生效的强制配置或企业策略，不是仓库仅仅属于某个组织。

自定义安全配置可以统一管理一组安全功能。组织管理文档说明，Enforce configuration会阻止仓库所有者更改配置中明确启用或禁用的功能；没有设定的功能不会因此被强制执行。因此，组织管理员应检查Dependabot alerts项目本身及强制状态，不能只看配置是否已创建，也不要为了维持告警随意开启其他付费安全功能。

适用平台与数据保留范围

新规则适用于github.com所有计划，也适用于带数据驻留的GitHub Enterprise Cloud。对数据驻留客户，已归档告警仍保存在企业其他数据所在的同一区域。GitHub Enterprise Server不在此次变更范围内，自建Server用户不应据此推断自己的告警会在12月8日被暂停。

建议团队在生效前整理仍需持续观察的低活动仓库，确认维护负责人、当前告警状态、最近一次符合定义的活动及策略豁免情况。对需要恢复的仓库，恢复后检查旧告警是否重新出现，再继续分配与处理；对仍在使用的依赖，保持清单和锁文件准确，避免把告警列表为空直接当作没有风险。

常见问题

关闭邮件通知是否等于关闭Dependabot告警？

两者不同。GitHub允许保留Dependabot告警的同时调整通知类型、使用每周摘要或关闭通知。此次不活跃规则关注告警功能本身，维护者应分别检查仓库的启用状态和个人通知偏好，不能仅靠是否收到邮件判断告警有没有运行。

恢复告警后，能否代替依赖安全检查？

不能。官方文档说明，Dependabot告警不能捕获所有安全问题，漏洞进入数据库并触发告警可能需要时间，且只有GitHub审核的公告会触发告警。告警恢复是重新获得这项观察能力，仍应结合实际依赖、项目使用方式和修复版本进行评估。