软件通常依赖于来自各种源的包，从而创建一个依赖项关系，这些依赖关系可能无意中引入安全漏洞。 当代码依赖于具有已知安全漏洞的包时，你将成为攻击者试图利用系统的目标，从而可能获取对代码、数据、客户或参与者的访问权限。 Dependabot alerts 通知你易受攻击的依赖项，以便你可以升级到安全版本并保护项目。
当Dependabot发送警报时
Dependabot 扫描您的存储库默认分支，当出现以下情况时发送警报：
- 新漏洞已添加到 GitHub Advisory Database
- 当你推送提交以更新包或版本时，你的依赖项图将发生更改。
有关支持的生态系统，请参阅 依赖项关系图支持的包生态系统。
了解警报
检测到易受攻击的依赖项时GitHub，存储库的Dependabot选项卡和依赖项关系图上会显示警报 Security and quality。 每个警报包括：
- 指向受影响文件的链接
- 有关漏洞及其严重性的详细信息
- 有关固定版本的信息（如果可用）
有关查看和管理警报的信息，请参阅 查看和更新 Dependabot 警报。
谁可以启用警报？
存储库管理员和组织所有者可以为其存储库Dependabot alerts和组织启用。 启用后， GitHub 立即生成依赖项关系图，并为它标识的任何易受攻击的依赖项创建警报。 存储库管理员可以向其他用户或团队授予访问权限。
请参阅“配置 Dependabot 警报”。
警报所有权和分配
具有写入或更高级别访问权限的用户可以将 Dependabot alerts 分配给存储库协作者、团队或 AI 代理，从而明确漏洞修复的责任归属。 分配有助于跟踪负责每个警报的人员，并防止漏洞被忽略。
可以将警报分配给以下类型的代理：
Copilot
**， GitHub内置 AI 代理。
- 可以在存储库设置中启用第三方代理，例如 Codex 或 Claude。
将警报分配给人员或团队时，被分配者会收到通知，警报会在警报列表中显示其名称。 按负责人筛选警报以跟踪进度。
将警报分配给代理时，代理会自动创建一个会话，并打开一个包含建议修补程序的草稿拉取请求。 如果代理无法生成修补程序，它将保留为被分配者，并且可以单击警报时间线上的 “查看会话 ”以查看代理的日志。
注意
分配可见性当前限定为存储库级警报视图。 组织范围内的安全概述不显示警报分配。
当警报的分配者发生更改时，GitHub 会发送 assignees_changed Webhook 事件。 可以使用此事件触发工作流或将分配数据与外部系统同步。 有关详细信息，请参阅“Webhook 事件和有效负载”。
自动化和集成
可以使用 REST API 以编程方式管理警报分配。 有关详细信息，请参阅“适用于 Dependabot alerts 的 REST API 终结点”。
有关分配警报的信息，请参阅 查看和更新 Dependabot 警报。
警报通知的工作原理
默认情况下， GitHub 向两者发送有关新警报的电子邮件通知：
- 对存储库具有写入、维护或管理员权限
- 正在监视存储库，并为安全警报或存储库上的所有活动启用通知
可以通过选择要接收的通知类型或在用户通知的设置页中完全关闭通知 https://github.com/settings/notifications来替代默认行为。
无论通知首选项如何，首次启用时 Dependabot ， GitHub 都不会为存储库中找到的所有易受攻击的依赖项发送通知。 如果通知首选项允许的话，启用 Dependabot 后，您会收到有关新识别的易受攻击依赖项的通知。
如果担心收到过多通知，建议利用 Dependabot 自动分类规则 自动消除低风险警报。 规则在发送警报通知之前应用，因此在创建时自动消除的警报不会发送通知。 请参阅“关于 Dependabot 自动分类规则”。
您还可以选择订阅每周电子邮件摘要，或者完全关闭通知，保持 Dependabot alerts 启用状态。
局限性
Dependabot alerts 存在一些限制：
-
警报无法检测每个安全问题。 始终查看依赖项，并保持清单和锁定文件的最新状态，以便进行准确的检测。
-
新的漏洞可能需要一段时间才会出现在 GitHub Advisory Database 中，并触发警报。
-
只有经过GitHub审查的公告会触发警报。
-
Dependabot 不会扫描存档的存储库。
-
对于 GitHub Actions，系统仅针对使用语义版本控制（而不是 SHA 版本控制）的操作生成警报。
GitHub 从不公开披露任何存储库的漏洞。