依赖项图如何识别依赖项

依赖项图可以使用以下方法标识项目的依赖项。

方法	工作原理
静态分析	解析存储库中的清单和锁定文件
**

          Dependabot 图形作业** | 
          Dependabot
          GitHub Actions使用工作流生成依赖项快照 |

一旦依赖项进入关系图，您就可以接收 Dependabot alerts 和 Dependabot security updates，以获取任何已知的漏洞。

静态分析

启用依赖项关系图时， GitHub 扫描存储库中支持的清单文件，并分析每个包的名称和版本。在默认分支上更改支持的清单或锁定文件时，或者依赖项在其自己的存储库中更改时，图形会更新。

静态分析可以识别：

对于最可靠的图形，应使用锁文件（或其等效文件），因为它们确切地定义了当前使用的直接和间接依赖项的版本。锁定文件还确保存储库的所有参与者都使用相同的版本，这样就可以更轻松地测试和调试代码。此外，从清单文件（而不是锁定文件）推断的间接依赖项将从漏洞检查中排除。

某些生态系统在生成时解析间接依赖项，因此静态分析看不到完整的依赖项树。为存储库启用自动依赖项提交时， GitHub 会自动标识受支持生态系统的存储库中的可传递依赖项。请参阅“依赖项关系图支持的包生态系统”。

在后台，自动依赖项提交会运行一个 GitHub Actions 工作流，生成完整的树并通过依赖项提交 API. 上传它。默认情况下，自动依赖项提交在GitHub 托管的运行程序上运行，并计入你的GitHub Actions分钟数。（可选）您可以选择在自托管的运行器上运行它，或者大型运行器.

若要启用自动依赖项提交，请参阅为存储库配置自动依赖项提交。

          Dependabot 图形作业

          Dependabot 图形作业使用特殊类型的 Dependabot 作业来生成依赖项快照并将其上传到依赖项提交 API。 
          Dependabot图形作业目前支持**Go**和**Python**依赖项。

对于支持的生态系统， Dependabot 图形作业提供：

此方法类似于自动依赖项提交，但在 GitHub Actions 分钟内不会产生费用。它还可以访问已设置 Dependabot的专用注册表的组织范围配置。

注意

Dependabot 图形作业优先于自动依赖项提交。例如，如果您的 Python 存储库之前使用过自动依赖项提交，那么一旦图形作业 Dependabot 处于活动状态，这些依赖项提交作业将不再运行。唯一的要求是为存储库启用依赖项关系图。

          依赖项提交 API

可以在自己的脚本或工作流中调用依赖项提交 API。这在以下情况下非常有用：

依赖项以快照的形式提交到依赖项提交 API 。这是与提交 SHA 和其他元数据关联的依赖项列表，反映存储库的当前状态。

如果在工作流中 GitHub Actions 调用 API，则可以对生态系统使用预做操作，该操作会自动收集依赖项并将其提交到 API。否则，您可以编写自己的操作，或者从外部系统调用 API。

提交的依赖项会显示在依赖项评审中，但在组织的依赖项见解中_不_可用。

注意

依赖关系审查 API 和依赖项提交 API 协同工作。这意味着依赖关系审查 API 将包括通过依赖项提交 API 提交的依赖关系。

有关详细信息，请参阅“使用依赖项提交 API”。

存储库可以使用多个方法提交依赖项，这可能导致多次扫描同一包清单，这可能会导致每次扫描的输出不同。依赖项关系图使用去重逻辑来分析输出，为每个清单文件优先选取最准确的信息。

依赖项关系图会依据以下优先级规则，仅显示每个清单文件的一个实例。

用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。****
- 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
- 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。有关关联器和检测器的详细信息，请参阅适用于依赖项提交的 REST API 终结点。

       **
       Dependabot 图形作业** 具有第二高优先级。 对于当前支持图形作业（如 Go 和 Python）的生态系统Dependabot，它们的优先级高于自动依赖项提交。

       **自动提交** 具有下一个优先级，因为它们也是在项目生成期间创建的，但不会由用户提交。