dependabot的一年无活动规则怎样计算，恢复告警后又会怎样？从2026年12月8日起，多数过去一年没有活动的仓库将被关闭dependabot告警；活动包括向任意分支或标签推送、创建仓库和启用告警。旧告警会归档而非删除，推送或手动重新启用后可恢复，并重新开始一年的计时。恢复只改变观察状态，不代表依赖漏洞已解决。

“不活跃”不等于默认分支没有新提交

公告列出的活动范围是向任意分支或标签推送，因此默认分支长期未变，并不足以单独证明仓库已符合一年无活动条件。仓库创建和开启Dependabot告警也计入活动。这里关注的是仓库活动与告警功能状态，而不是只看首页最近一次默认分支提交。

这项规则面向多数一年无活动仓库，不是将所有低频维护项目一律认定为没有安全价值。仍被部署、作为内部库使用或保留历史版本的代码，可能继续暴露于后来披露的依赖漏洞；代码不更新不会使外部漏洞信息停止变化。

关闭、归档、恢复和修复各指什么

自动关闭针对Dependabot告警功能，已有告警转为归档保存，没有因此删除。任何一次推送可自动重新打开告警，仓库设置中的手动启用也能恢复；两种方式都会恢复归档告警并重启一年计时。

恢复告警与关闭漏洞是两个不同过程。归档记录重新出现，只说明维护者重新获得对应告警信息；受影响依赖是否已升级、修复版本是否适合项目，仍由实际依赖与后续处置决定。因而“列表曾经为空”不能自动解释成“仓库没有依赖风险”。

同样，个人邮件通知是否开启也不是仓库告警状态。维护者可以保留告警、改变通知类型、采用每周摘要或关闭通知；没有收到邮件，不能单凭这一点认定仓库已被自动暂停。

哪些策略会阻止自动关闭

使用强制安全配置且其中明确启用Dependabot告警的仓库，不会因为缺少活动而关闭这项告警。企业Dependabot告警策略若不允许仓库管理员自行启用或禁用，相关仓库也会跳过自动关闭规则。

“属于组织”本身不是豁免条件。自定义配置只有实际启用相应功能且处于强制执行状态，才能与这项规则对应。Enforce configuration约束配置中明确启用或禁用的功能，没有设定的功能不因此被强制。配置存在、已应用以及不可由仓库管理员更改，也不能混为一个状态。

这一点对大量低活动但仍在使用的内部库尤其重要：持续告警可以由有效策略管理，而不是依靠为了刷新计时制造无意义提交。也不能因为需要Dependabot告警，就推定其他付费安全功能必须一起启用。

单仓库、个人批量和企业管理的作用范围

仓库设置提供单独启用Dependabot alerts的能力；官方配置文档中的Settings、Security and quality下的Advanced Security属于仓库级入口。个人安全设置的Advanced Security还可对现有仓库Enable all，并为以后新仓库配置默认启用。它们针对不同范围，不能把只涉及一个仓库的状态判断等同于应改变整个账号全部仓库。

仓库管理员的可操作范围还受组织和企业策略约束。单独功能状态、个人默认值和强制配置应分别解释，不能用个人通知偏好替代企业策略，也不能仅靠一个按钮是否可见判断所有仓库的豁免情况。

哪些平台受影响，归档数据放在哪里

新规则适用于github.com所有计划，以及带数据驻留的GitHub Enterprise Cloud。数据驻留客户的归档告警仍保存在企业其他数据所在的同一区域，不会因为归档就改变数据驻留地域。

GitHub Enterprise Server不在这次变更范围。自建Server用户不能据此推断自己的仓库会在12月8日自动暂停；Cloud与Server虽共享许多功能概念，具体规则的适用平台仍需区分。

持续告警为什么也不能覆盖所有风险

Dependabot根据默认分支依赖识别已知漏洞，依赖图变化或Advisory Database新增漏洞都可能触发新告警。告警可以提供受影响文件、严重程度与可用修复版本，但并不等于扫描到了项目全部安全问题。

只有GitHub审核的公告会触发相应告警，漏洞入库和告警产生也可能存在时间差。保持告警、恢复归档信息和处理实际依赖，各自解决不同问题；对仍在使用的低活动仓库，维护负责人、依赖清单和处置流程仍然重要，不能把自动暂停规则当作风险已经消失的证明。