Skip to main content

About the dependency graph

You can use the dependency graph to identify all your project's dependencies. The dependency graph supports a range of popular package ecosystems.

About the dependency graph

依赖项关系图是存储在存储库 中的清单和锁定文件的摘要,以及所有提交给使用依赖项提交 API(beta 版) 的存储库的依赖关系。 对于每个存储库,它显示:

  • 依赖项、它依赖的生态系统和包
  • 依赖项、依赖于它的仓库和包

When you push a commit to GitHub Enterprise Cloud that changes or adds a supported manifest or lock file to the default branch, the dependency graph is automatically updated. In addition, the graph is updated when anyone pushes a change to the repository of one of your dependencies. For information on the supported ecosystems and manifest files, see "Supported package ecosystems" below.

此外,可以使用依赖项提交 API(beta 版本)从所选择的包管理器或生态系统提交依赖项,即使该生态系统不受清单或锁定文件分析的依赖关系图支持。 依赖项关系图将显示按生态系统分组的提交依赖项,但与从清单或锁定文件解析的依赖项是分开的。 有关依赖项提交 API 的详细信息,请参阅“使用依赖项提交 API”。

When you create a pull request containing changes to dependencies that targets the default branch, GitHub uses the dependency graph to add dependency reviews to the pull request. These indicate whether the dependencies contain vulnerabilities and, if so, the version of the dependency in which the vulnerability was fixed. For more information, see "About dependency review."

Dependency graph availability

The dependency graph is available for every public repository that defines dependencies in a supported package ecosystem using a supported file format. Repository administrators can also set up the dependency graph for private repositories. For more information , see "Configuring the dependency graph."

如果企业所有者在企业级别设置了策略,则可能无法启用或禁用依赖项关系图。 有关详细信息,请参阅“为企业实现代码安全性和分析策略”。

Dependencies included

The dependency graph includes all the dependencies of a repository that are detailed in the manifest and lock files, or their equivalent, for supported ecosystems, as well as any dependencies that are submitted using the Dependency submission API (beta). This includes:

  • Direct dependencies, that are explicitly defined in a manifest or lock file or have been submitted using the Dependency submission API (beta)
  • Indirect dependencies of these direct dependencies, also known as transitive dependencies or sub-dependencies

The dependency graph identifies indirect dependencies either explicitly from a lock file or by checking the dependencies of your direct dependencies. 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. If you use lock files, you 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.

For more information on how GitHub Enterprise Cloud helps you understand the dependencies in your environment, see "About supply chain security."

Dependents included

For public repositories, only public repositories that depend on it or on packages that it publishes are reported. This information is not reported for private repositories.

Using the dependency graph

You can use the dependency graph to:

Supported package ecosystems

The recommended formats explicitly define which versions are used for all direct and all indirect dependencies. If you use these formats, your dependency graph is more accurate. It also reflects the current build set up and enables the dependency graph to report vulnerabilities in both direct and indirect dependencies. Indirect dependencies that are inferred from a manifest file (or equivalent) are excluded from the checks for insecure dependencies.

Package managerLanguagesRecommended formatsAll supported formats
CargoRustCargo.lockCargo.toml, Cargo.lock
ComposerPHPcomposer.lockcomposer.json, composer.lock
NuGet.NET languages (C#, F#, VB), C++.csproj, .vbproj, .nuspec, .vcxproj, .fsproj.csproj, .vbproj, .nuspec, .vcxproj, .fsproj, packages.config
GitHub Actions workflows[†]YAML.yml, .yaml.yml, .yaml
Go modulesGogo.sumgo.mod, go.sum
MavenJava, Scalapom.xmlpom.xml
npmJavaScriptpackage-lock.jsonpackage-lock.json, package.json
pipPythonrequirements.txt, pipfile.lockrequirements.txt, pipfile, pipfile.lock, setup.py[‡]
pubDartpubspec.lockpubspec.yaml, pubspec.lock
Python PoetryPythonpoetry.lockpoetry.lock, pyproject.toml
RubyGemsRubyGemfile.lockGemfile.lock, Gemfile, *.gemspec
YarnJavaScriptyarn.lockpackage.json, yarn.lock

[†] GitHub Actions workflows must be located in the .github/workflows/ directory of a repository to be recognized as manifests. Any actions or workflows referenced using the syntax jobs[*].steps[*].uses or jobs.<job_id>.uses will be parsed as dependencies. For more information, see "Workflow syntax for GitHub Actions."

[‡] If you list your Python dependencies within a setup.py file, we may not be able to parse and list every dependency in your project.

Note: GitHub Actions workflow dependencies are displayed in the dependency graph for informational purposes. Dependabot alerts are not currently supported for GitHub Actions workflows.

You can use the Dependency submission API (beta) to add dependencies from the package manager or ecosystem of your choice to the dependency graph, even if the ecosystem is not in the supported ecosystem list above. The dependency graph will display the submitted dependencies grouped by ecosystem, but separately from the dependencies parsed from manifest or lock files. You will only get Dependabot alerts for dependencies that are from one of the supported ecosystems of the GitHub Advisory Database. For more information on the Dependency submission API, see "Using the Dependency submission API."

Further reading