依赖项图可以使用以下方法标识项目的依赖项。
| 方法 | 工作原理 |
|---|
**静态分析** | 解析存储库中的清单和锁定文件 |
| | | Dependabot 图表作业 | 使用 Dependabot GitHub Actions 工作流生成依赖项快照 | | | | | | 自动提交 | 运行内置 GitHub Actions 工作流以解析构建时依赖项 | | | 依赖项提交 API | 接受以编程方式提交的依赖项数据 |
依赖项进入图表后，你可以接收任何已知漏洞的 Dependabot alerts 和 Dependabot security updates。
静态分析
启用依赖项图时，GitHub 会扫描存储库中支持的清单文件，并分析每个包的名称和版本。 在默认分支上更改受支持的清单或锁定文件时，图形会更新，或者当依赖项在其自己的存储库中发生更改时。
静态分析可以识别：
- 在清单或锁定文件中显式定义的直接依赖项
-
**间接依赖项**——这些直接依赖项的依赖项，也称为“可传递依赖项”——前提是它们在清单或锁定文件中定义，而不是在构建时进行解析。
对于最可靠的图形，应使用锁文件（或其等效文件），因为它们确切地定义了当前使用的直接和间接依赖项的版本。 锁定文件还确保存储库的所有参与者都使用相同的版本，这样就可以更轻松地测试和调试代码。此外，从清单文件（而不是锁定文件）推断的间接依赖项将从漏洞检查中排除。
自动依赖项提交
某些生态系统在生成时解析间接依赖项，因此静态分析看不到完整的依赖项树。 为存储库启用自动依赖项提交后，GitHub 会自动识别存储库中受支持生态系统的传递依赖项。 请参阅“依赖项关系图支持的包生态系统”。
在后台，自动依赖项提交运行 GitHub Actions 工作流，生成完整树并使用 依赖项提交 API 上传。 自动依赖项提交默认在 GitHub 托管的运行器上运行，并计入你的 GitHub Actions 分钟数。 （可选）你可以选择在自托管运行器或 大型运行器 上运行。
若要启用自动依赖项提交，请参阅 为存储库配置自动依赖项提交。
Dependabot 图表作业
此方法使用特殊类型的 Dependabot 作业，构建依赖项快照并上传到依赖项提交 API。 目前仅支持 Go 依赖项。
此方法类似于自动依赖项提交，但不会产生 GitHub Actions 分钟数费用。 它还可以访问你为 Dependabot 设置的专用注册表的组织范围配置。
依赖项提交 API
可以在自己的脚本或工作流中调用 依赖项提交 API。 这在以下情况下非常有用：
- 需要提交无法通过锁定文件检测到的传递性依赖项。
- 需要创建自定义逻辑或使用外部 CI/CD 系统。
依赖项以快照的形式提交到 依赖项提交 API。 这是与提交 SHA 和其他元数据关联的依赖项列表，反映存储库的当前状态。
如果你在 GitHub Actions 工作流中调用 API，可以为你的生态系统使用预制操作，自动收集依赖项并提交到 API。 否则，您可以编写自己的操作，或者从外部系统调用 API。
提交的依赖项会显示在依赖项评审中，但在组织的依赖项见解中_不_可用。
注意
依赖关系审查 API 和 依赖项提交 API 协同工作。 这意味着依赖关系审查 API 将包括通过 依赖项提交 API 提交的依赖关系。
有关详细信息，请参阅“使用依赖项提交 API”。
优先级
存储库可以使用多个方法提交依赖项，这可能导致多次扫描同一包清单，这可能会导致每次扫描的输出不同。 依赖项关系图使用去重逻辑来分析输出，为每个清单文件优先选取最准确的信息。
依赖项关系图会依据以下优先级规则，仅显示每个清单文件的一个实例。
- 用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。****
- 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
- 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。 有关关联器和检测器的详细信息，请参阅 适用于依赖项提交的 REST API 终结点。
- 自动提交具有第二高的优先级，因为它们同样是在项目构建期间创建的，但并非由用户提交。****
- 静态分析结果会在没有其他可用数据的情况下被采用。****