The dependency graph can identify your project's dependencies using the following methods.
| Method | How it works |
|---|---|
| Static analysis | Parses manifest and lock files in your repository |
| Dependabot graph jobs | Uses a Dependabot GitHub Actions workflow to generate dependency snapshots |
| Automatic submission | Runs a built-in GitHub Actions workflow to resolve build-time dependencies |
| 依赖项提交 API | Accepts dependency data you submit programmatically |
Once dependencies are in the graph, you can receive Dependabot alerts and Dependabot security updates for any known vulnerabilities.
Static analysis
When you enable the dependency graph, GitHub scans your repository for supported manifest files and parses each package's name and version. The graph updates when you change a supported manifest or lock file on your default branch, or when a dependency changes in its own repository.
Static analysis can identify:
- Direct dependencies explicitly defined in a manifest or lock file
- Indirect dependencies—dependencies of these direct dependencies, also called "transitive dependencies"—but only if they are defined in a manifest or lock file, not if they are resolved at build time
For the most reliable graph, you should use lock files (or their equivalent), because they define exactly which versions of the direct and indirect dependencies you currently use. Lock files also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code. In addition, indirect dependencies inferred from manifest files (rather than lock files) are excluded from vulnerability checks.
Automatic dependency submission
Some ecosystems resolve indirect dependencies at build time, so static analysis can't see the full dependency tree. When you enable automatic dependency submission for a repository, GitHub automatically identifies the transitive dependencies in the repository for supported ecosystems. See 依赖项关系图支持的包生态系统.
In the background, automatic dependency submission runs a GitHub Actions workflow that generates the complete tree and uploads it using the 依赖项提交 API. Automatic dependency submission runs on GitHub-hosted runners by default and counts toward your GitHub Actions minutes. Optionally, you can choose to run it on self-hosted runners or 大型运行器.
To enable automatic dependency submission, see 为存储库配置自动依赖项提交.
Dependabot graph jobs
This method uses a special type of Dependabot job that builds a dependency snapshot and uploads it to the dependency submission API. This is currently only supported for Go dependencies.
This approach is similar to automatic dependency submission, but does not incur charges for GitHub Actions minutes. It can also access organization-wide configurations for private registries you've set up for Dependabot.
The 依赖项提交 API
You can call the 依赖项提交 API in your own script or workflow. This is useful if:
- You need to submit transitive dependencies that cannot be detected from lock files.
- You need to create custom logic or are using an external CI/CD system.
Dependencies are submitted to the 依赖项提交 API in the form of a snapshot. This is a list of dependencies associated with a commit SHA and other metadata, reflecting the current state of your repository.
If you are calling the API in a GitHub Actions workflow, you can use a pre-made action for your ecosystem that automatically gathers the dependencies and submits them to the API. Otherwise, you can write your own action or call the API from an external system.
可以使用 REST API 提交项目的依赖项。 这使你可以将依赖项（如编译或生成软件时解析的依赖项）添加到 GitHub 的依赖项关系图功能，从而更全面地了解项目的所有依赖项。
依赖项关系图显示你使用 API 提交的任何依赖项，以及从存储库中的清单或锁定文件（例如 package-lock.json JavaScript 项目中的文件）标识的任何依赖项。 有关查看依赖项关系图的详细信息，请参阅 探索仓库的依赖项。
提交的依赖项将收到 Dependabot alerts 和 Dependabot security updates 以处理任何已知的漏洞。 你只会收到来自 GitHub Advisory Database 支持的生态系统之一的依赖关系的 Dependabot alerts。 有关这些生态系统的详细信息，请参阅 关于 GitHub 公告数据库。 对于通过 依赖项提交 API 提交的可传递依赖项，如果更新可用，Dependabot 将自动打开拉取请求以更新父依赖项。
提交的依赖项会显示在依赖项评审中，但在组织的依赖项见解中_不_可用。
注意
依赖关系审查 API 和 依赖项提交 API 协同工作。 这意味着依赖关系审查 API 将包括通过 依赖项提交 API 提交的依赖关系。
For more information, see 使用依赖项提交 API.
Prioritization
依赖项关系图可以通过三种不同的方式来了解依赖项：静态分析、自动提交和手动提交。 一个仓库可以配置多种方法，这会导致同一个包清单被扫描多次，而且每次扫描可能会产生不同的结果。 依赖项关系图使用去重逻辑来分析输出，为每个清单文件优先选取最准确的信息。
依赖项关系图会依据以下优先级规则，仅显示每个清单文件的一个实例。
- 用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。****
- 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
- 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。 有关关联器和检测器的详细信息，请参阅 适用于依赖项提交的 REST API 终结点。
- 自动提交具有第二高的优先级，因为它们同样是在项目构建期间创建的，但并非由用户提交。****
- 静态分析结果会在没有其他可用数据的情况下被采用。****