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