Skip to main content

关于 Dependabot 安全更新

Dependabot 可通过提出安全更新拉取请求为您修复有漏洞依赖项。

谁可以使用此功能?

Dependabot security updates 可免费用于 GitHub.com 上的所有存储库。

关于 Dependabot security updates

Dependabot security updates 使您更容易修复仓库中的有漏洞依赖项。 如果启用此功能,当针对存储库依赖项关系图中有漏洞的依赖项发出 Dependabot 警报时,Dependabot 将自动尝试对其进行修复。 有关详细信息,请参阅“关于 Dependabot 警报”和“配置 Dependabot 安全更新”。

注意:为存储库启用 Dependabot security updates 时,Dependabot 将自动尝试打开拉取请求,以解决每个具有可用修补程序的打开的 Dependabot 警报。******** 如果希望自定义 Dependabot 为其打开拉取请求的警报,则应禁用 Dependabot security updates 并创建自动会审规则。**** 有关详细信息,请参阅“自定义自动分类规则以确定 Dependabot 警报的优先级”。

GitHub 可能会向受最近发布的 GitHub 安全通告披露的漏洞影响的仓库发送 Dependabot alerts。 有关详细信息,请参阅“在 GitHub Advisory Database 中浏览安全公告”。

Dependabot 将检查是否可以在不破坏仓库依赖关系图的情况下将有漏洞依赖项升级到已修复版本。 然后 Dependabot 提出拉取请求以将依赖项更新到包含补丁的最低版本,并将拉取请求链接到 Dependabot 警报,或者在警报中报告错误。 有关详细信息,请参阅“排查 Dependabot 错误”。

Dependabot security updates 功能适用于已启用依赖关系图和 Dependabot alerts 的仓库。 你将在完整依赖项关系图中看到针对已识别的每个有漏洞依赖项的 Dependabot 警报。 但是,安全更新仅针对清单或锁定文件中指定的依赖项而触发。 有关详细信息,请参阅“关于依赖关系图”。

注意:对于 npm,Dependabot 会引发拉取请求,以将显式定义的依赖项更新到安全版本,即使这意味着要更新一个或多个父依赖项甚或是删除父级不再需要的子依赖项。 对于其他生态系统,如果 Dependabot 还需要更新父依赖项,则无法更新间接依赖项或可传递依赖项。 有关详细信息,请参阅“排查 Dependabot 错误”。

您可以启用相关功能 Dependabot version updates,这样无论 Dependabot 是否检测到过期的依赖项,都可以提出拉取请求,以将清单更新到依赖项的最新版本。 有关详细信息,请参阅“关于 Dependabot 版本更新”。

当 Dependabot 提出拉取请求时,这些拉取请求可以是安全更新或版本更新:

  • Dependabot security updates 是自动拉取请求,可帮助你更新已知漏洞的信赖项。
  • Dependabot version updates 是自动拉取请求,即使它们没有任何漏洞,也会保持更新依赖项。 要检查版本更新的状态,请依次导航到仓库的 Insights(见解)选项卡、Dependency Graph(依赖关系图)、Dependabot。

GitHub Actions 为 ,而不是 ,Dependabot version updates 和 Dependabot security updates 在 GitHub 上运行。但是,Dependabot 打开的拉取请求可以触发运行操作的工作流。 有关详细信息,请参阅“通过 GitHub Actions 自动化 Dependabot”。

Dependabot security updates 可以修复 GitHub Actions 中有漏洞的依赖项。 启用安全更新后,Dependabot 将自动提出拉取请求,以将工作流中使用的存在漏洞的 GitHub Actions 更新到最低的已修补版本。

关于安全更新的拉取请求

每个拉取请求都包含快速、安全地查看提议的修复程序并将其合并到项目中所需的全部内容。 这包括漏洞的相关信息,如发行说明、变更日志条目和提交详细信息。 无法访问仓库的 Dependabot alerts 的任何人都看不到拉取请求所解决的漏洞详细信息。

合并包含安全更新程序的拉取请求时,存储库相应的 Dependabot 警报会标记为已解决。 有关 Dependabot 拉取请求的详细信息,请参阅“管理依赖项更新的所有拉取请求”。

注意:最好制定自动测试和验收流程,以便在合并拉取请求之前执行检查。 如果建议的升级版本包含额外的功能,或者更改会中断您的项目代码,这种做法尤其重要。 有关持续集成的详细信息,请参阅“关于持续集成”。

关于分组的安全更新

**注意:**Dependabot security updates 的分组拉取请求目前处于 beta 版本,可能会随时更改。

若要进一步减少可能看到的拉取请求数,你可以启用分组的安全更新将依赖项集分组在一起(每个包生态系统)。 然后,Dependabot 提出单个拉取请求,以将组中尽可能多的脆弱性依赖项同时更新到安全版本。

对于安全更新,Dependabot 仅在特定条件和配置下将每个生态系统不同目录的依赖项分组。 Dependabot 不会将来自不同包生态系统的依赖项分组到一起,且不会使用版本更新对安全更新进行分组。

可以通过以下一种或两种方式为 Dependabot security updates 启用分组拉取请求。

  • 若要跨目录和在每个生态系统中将尽可能多的可用安全更新组合在一起,请在组织或存储库的“代码安全和分析”设置中启用分组。
  • 若要更精细地控制分组,例如按包名称、开发/生产依赖项或 SemVer 级别进行分组,请将配置选项添加到存储库中的 dependabot.yml 配置文件。

注意:**** 如果已在 dependabot.yml 文件中为 Dependabot security updates 配置了组规则,则所有可用更新都将根据指定的规则进行分组。 如果还启用了组织或存储库级别的分组安全更新设置,则 Dependabot 只会跨那些未在 dependabot.yml 中配置的目录进行分组。

有关详细信息,请参阅“配置 Dependabot 安全更新”。

关于兼容性分数

Dependabot security updates 可能包括兼容性分数,以便您了解更新依赖项是否可能导致对项目的重大更改。 这些分数是根据已生成相同安全更新的其他公共仓库中的 CI 测试计算的。 更新的兼容性分数是在依赖项的特定版本之间进行更新时,CI 运行被视为通过的百分比。

关于 Dependabot updates

的自动停用

当存储库的维护者停止与 Dependabot 拉取请求交互时,Dependabot 会暂时暂停其更新并发出通知。 这种自动选择退出行为可减少干扰,因为 Dependabot 不会对版本更新和安全更新创建拉取请求,也不会对非活动存储库的 Dependabot 拉取请求进行变基。

Dependabot 更新的自动停用仅适用于符合以下条件的存储库:Dependabot 已打开拉取请求但拉取请求保持不变。 如果 Dependabot 尚未打开任何拉取请求,Dependabot 将永远不会暂停。

活动存储库是指用户(非 Dependabot)在过去 90 天内执行了以下任一操作的存储库:

  • 在存储库上合并或关闭 Dependabot 拉取请求。
  • 对存储库的 dependabot.yml 文件进行更改。
  • 手动触发安全更新或版本更新。
  • 为存储库启用 Dependabot security updates。
  • 对拉取请求使用 @dependabot 命令。

非活动存储库是指以下存储库:至少有一个 Dependabot 拉取请求打开时间超过 90 天,在整个期间处于启用状态,并且用户未执行上面列出的任何操作。

当 Dependabot 暂停时,GitHub 将向以下位置添加横幅通知:

  • 所有打开的 Dependabot 拉取请求。
  • 存储库“设置”选项卡的 UI(在“代码安全性和分析”下,然后选择 Dependabot)。
  • Dependabot alerts 的列表(如果 Dependabot security updates 受影响)。

维护人员再次与 Dependabot 拉取请求交互后,Dependabot 将自行取消暂停:

  • Dependabot alerts 的安全更新将会自动恢复。
  • 版本更新将按照 dependabot.yml 文件中指定的计划自动恢复。

关于 Dependabot 安全更新通知

您可以在 GitHub 上过滤通知以显示 Dependabot 安全更新。 有关详细信息,请参阅“从收件箱管理通知”。