# 依赖项图如何识别依赖项

依赖项图会自动分析清单文件。 可以提交无法自动检测到的依赖项的数据。

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

| 方法                  | 工作原理                                 |
| ------------------- | ------------------------------------ |
| **静态分析**            | 解析存储库中的清单和锁定文件                       |
|                     |                                      |
| **Dependabot 图形作业** | DependabotGitHub Actions使用工作流生成依赖项快照 |
|                     |                                      |
|                     |                                      |
| **自动提交**            | 运行内置 GitHub Actions 工作流以解析生成时依赖项     |
|                     |                                      |
| **依赖项提交 API**       | 接受以编程方式提交的依赖项数据                      |

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

## 静态分析

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

静态分析可以识别：

* 在清单或锁定文件中显式定义的**直接依赖项**
* **间接依赖项**——这些直接依赖项的依赖项，也称为“可传递依赖项”——前提是它们在清单或锁定文件中定义，而不是在构建时进行解析。

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

## 自动依赖项提交

某些生态系统在生成时解析间接依赖项，因此静态分析看不到完整的依赖项树。 为存储库启用自动依赖项提交时， GitHub 会自动标识受支持生态系统的存储库中的可传递依赖项。 请参阅“[依赖项关系图支持的包生态系统](/zh/code-security/reference/supply-chain-security/dependency-graph-supported-package-ecosystems)”。

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

若要启用自动依赖项提交，请参阅 [为存储库配置自动依赖项提交](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/submit-dependencies-automatically)。

## Dependabot 图形作业

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

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

* 完全可传递的依赖项覆盖率，这意味着 Dependabot 可以提醒你间接依赖项中的漏洞，静态分析可能错过。
* 通过 Dependabot 组织或存储库级别配置的机密进行专用注册表访问。 有关详细信息，请参阅“[为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries)”。
* 无法通过配置的 Dependabot 机密访问的专用包从依赖项关系图中正常省略，而不会导致失败。

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

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

## 依赖项提交 API

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

* 需要提交无法通过锁定文件检测到的传递性依赖项。
* 需要创建自定义逻辑或使用外部 CI/CD 系统。

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

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

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

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

有关详细信息，请参阅“[使用依赖项提交 API](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/use-dependency-submission-api)”。

## 优先级

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

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

1. 用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。\*\*\*\*
   * 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
   * 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。 有关关联器和检测器的详细信息，请参阅 [适用于依赖项提交的 REST API 终结点](/zh/rest/dependency-graph/dependency-submission)。
2. \*\*
   Dependabot 图形作业\*\* 具有第二高优先级。 对于当前支持图形作业（如 Go 和 Python）的生态系统Dependabot，它们的优先级高于自动依赖项提交。
3. **自动提交** 具有下一个优先级，因为它们也是在项目生成期间创建的，但不会由用户提交。
4. 静态分析结果会在没有其他可用数据的情况下被采用。\*\*\*\*