关于 Dependabot security updates
Dependabot security updates 使您更容易修复仓库中的有漏洞依赖项。 通常会将一个 dependabot.yml 文件添加到存储库来启用 Dependabot security updates。 然后在此文件中配置选项，告知 Dependabot 如何维护存储库。
有关受支持的仓库和生态系统的详细信息，请参阅“Dependabot 支持的生态系统和存储库”。
如果启用 Dependabot security updates，则在对存储库依赖项关系图中有漏洞的依赖项发出 Dependabot 警报时，Dependabot 会自动尝试对其进行修复。 有关详细信息，请参阅 关于 Dependabot 警报 和 配置 Dependabot 安全更新。
Note
dependabot.yml 文件中指定的设置与 Dependabot 安全警报之间没有交互，只是在合并 Dependabot 为安全更新生成的相关拉取请求时关闭警报。
Dependabot 默认对自己的提交进行签名，即使提交签名不是存储库的要求。 有关已验证提交的详细信息，请参阅“关于提交签名验证”。
Note
为存储库启用 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 警报。 但是，安全更新仅针对清单或锁定文件中指定的依赖项而触发。 有关详细信息，请参阅“关于依赖关系图”。
Note
对于 npm，Dependabot 会引发拉取请求，以将显式定义的依赖项更新到安全版本，即使这意味着要更新一个或多个父依赖项甚或是删除父级不再需要的子依赖项。 对于其他生态系统，如果 Dependabot 还需要更新父依赖项，则无法更新间接依赖项或可传递依赖项。 有关详细信息，请参阅“排查 Dependabot 错误”。
您可以启用相关功能 Dependabot version updates，这样无论 Dependabot 是否检测到过期的依赖项，都可以提出拉取请求，以将清单更新到依赖项的最新版本。 有关详细信息，请参阅“关于 Dependabot 版本更新”。
当 Dependabot 提出拉取请求时，这些拉取请求可以是安全更新或版本更新：
- Dependabot security updates 是自动拉取请求，可帮助你更新已知漏洞的信赖项。
- Dependabot version updates 是自动拉取请求，即使它们没有任何漏洞，也会保持更新依赖项。 要检查版本更新的状态，请依次导航到仓库的 Insights（见解）选项卡、Dependency Graph（依赖关系图）、Dependabot。
如果启用 Dependabot security updates，则配置的各个部分也可能会影响为 Dependabot version updates 创建的拉取请求。 这是因为某些配置设置是这两种类型的更新通用的。 有关详细信息，请参阅“自定义 Dependabot 安全更新的拉取请求”。
由 Dependabot 打开的拉取请求可能会触发运行操作的工作流。 有关详细信息，请参阅 通过 GitHub Actions 自动化 Dependabot。
如果在新存储库上启用 Dependabot 并启用 GitHub Actions，则 Dependabot 将默认在 GitHub Actions 上运行。
如果在新仓库上启用 Dependabot 并禁用 GitHub Actions，Dependabot 将在 GitHub 中的旧应用程序上运行以执行 Dependabot updates。 这不会像 GitHub Actions 那样提供 Dependabot updates 作业的良好性能、可见性或控制。 如果要将 Dependabot 与 GitHub Actions 一起使用，则必须确保仓库启用 GitHub Actions，然后从仓库的“Code security”设置页中启用“Dependabot on Actions runners”。 有关详细信息，请参阅 关于 GitHub Actions 运行器上的 Dependabot。
Dependabot security updates 可以修复 GitHub Actions 中有漏洞的依赖项。 启用安全更新后，Dependabot 将自动提出拉取请求，以将工作流中使用的存在漏洞的 GitHub Actions 更新到最低的已修补版本。
关于安全更新的拉取请求
每个拉取请求都包含快速、安全地查看提议的修复程序并将其合并到项目中所需的全部内容。 这包括漏洞的相关信息，如发行说明、变更日志条目和提交详细信息。 无法访问仓库的 Dependabot alerts 的任何人都看不到拉取请求所解决的漏洞详细信息。
合并包含安全更新程序的拉取请求时，存储库相应的 Dependabot 警报会标记为已解决。 有关 Dependabot 拉取请求的详细信息，请参阅 管理依赖项更新的所有拉取请求。
Note
最好制定自动测试和验收流程，以便在合并拉取请求之前执行检查。 如果建议的升级版本包含额外的功能，或者更改会中断您的项目代码，这种做法尤其重要。 有关持续集成的详细信息，请参阅“关于使用 GitHub Actions 进行持续集成”。
关于分组的安全更新
若要进一步减少可能看到的拉取请求数，你可以启用分组的安全更新将依赖项集分组在一起（每个包生态系统）。 然后，Dependabot 提出单个拉取请求，以将组中尽可能多的脆弱性依赖项同时更新到安全版本。
对于安全更新，Dependabot 仅在特定条件和配置下将每个生态系统不同目录的依赖项分组。 Dependabot 不会将来自不同包生态系统的依赖项分组到一起，且不会使用版本更新对安全更新进行分组。
可以通过以下一种或两种方式为 Dependabot security updates 启用分组拉取请求。
- 若要跨目录和按生态系统将尽可能多的可用安全更新分组在一起，请在仓库的“Code security”设置中，或在组织的“Code security”下的“Global settings”中启用分组。
- 若要更精细地控制分组，例如按包名称、开发/生产依赖项、 SemVer 级别，或者跨每个生态系统的多个目录进行分组，请将配置选项添加到存储库中的
dependabot.yml配置文件。
Note
如果已在 dependabot.yml 文件中为 Dependabot security updates 配置了组规则，则所有可用更新都将根据指定的规则进行分组。 如果还启用了组织或存储库级别的分组安全更新设置，则 Dependabot 只会跨那些未在 dependabot.yml 中配置的目录进行分组。
有关详细信息，请参阅“配置 Dependabot 安全更新”。
关于兼容性分数
Dependabot security updates 可能包括兼容性分数，以便您了解更新依赖项是否可能导致对项目的重大更改。 这些分数是根据已生成相同安全更新的其他公共仓库中的 CI 测试计算的。 更新的兼容性分数是在依赖项的特定版本之间进行更新时，CI 运行被视为通过的百分比。
关于 Dependabot updates
的自动停用
当仓库的维护者停止与 Dependabot 拉取请求交互时，Dependabot 会暂时暂停其更新并发出通知，请参阅 不再生成 Dependabot 更新拉取请求。
关于 Dependabot 安全更新通知
您可以在 GitHub 上过滤通知以显示 Dependabot 安全更新。 有关详细信息，请参阅“从收件箱管理通知”。