关于依赖项关系图
有关依赖项关系图的简介，请参阅“关于依赖关系图”。
构建依赖项关系图
如果启用了依赖项关系图，它将扫描你的仓库，查找常用编程语言包生态系统所使用的清单文件。 当它找到其中一个受支持的清单文件时，它将分析该文件，并构建该文件内容的呈现形式，包括每个包的名称和版本。 这称为“静态分析”。
一些文件明确定义哪些版本用于所有直接和所有间接依赖项。 它们将包版本锁定为构建中所包含的那些版本，并使 Dependabot 能够在直接和间接依赖项中找到存在漏洞的版本。 如果使用这些格式，依赖项关系图会更准确，因此它们会被列在“支持的包生态系统”表的“推荐的文件”一列中。 请参阅支持的包生态系统。 从清单文件（或类似文件）中推断出的间接依赖项将不会被 Dependabot 纳入不安全依赖项的检查范围。
对于在构建时解析传递依赖项的包生态系统，静态分析无法全面展示依赖项树。 对于这些生态系统，有两种使用 GitHub Actions 的方法：自动和手动依赖项提交。 两种方法都会通过外部操作生成完整的依赖项树并将其上传到依赖项提交 API。 你可以在仓库的设置页面中为支持的生态系统启用自动提交功能。 有关详细信息，请参阅“为存储库配置自动依赖项提交”。
通过依赖项提交操作支持的包生态系统
除了依赖项关系图的静态分析和自动提交外，还可以使用 依赖项提交 API 将生成时依赖项添加到依赖项关系图，或者将选择的包管理器和生态系统的依赖项添加到依赖项关系图，即使该生态系统不在“支持的包生态系统”表中。 这些提交的依赖项中的依赖项信息会依次流入 Dependabot updates 和 Dependabot alerts。
使用 依赖项提交 API 提交到项目的依赖项将显示用于提交的检测器以及提交时间。有关 依赖项提交 API 的详细信息，请参阅 使用依赖项提交 API。
支持的包生态系统
| 程序包管理器 | 语言 | 静态可传递依赖项 | 自动依赖项提交 | 建议的文件 | 其他文件 |
|---|---|---|---|---|---|
| Cargo | Rust | Cargo.lock | Cargo.toml | ||
| 编辑器 | PHP | composer.lock | composer.json | ||
| NuGet | .NET 语言（C#、F#、VB）、C++ | .csproj、.vbproj、.nuspec、.vcxproj、.fsproj | packages.config | ||
| GitHub Actions 工作流程 | YAML | .yml、.yaml | |||
| Go 模块 | Go | go.mod | |||
| Gradle | Java | ||||
| Maven | Java、Scala | pom.xml | |||
| npm | JavaScript | package-lock.json | package.json | ||
| pip | Python | requirements.txt, pipfile.lock | pipfile, setup.py | ||
| pnpm | JavaScript | pnpm-lock.yaml | package.json | ||
| 酒馆 | Dart | pubspec.lock | pubspec.yaml | ||
| 诗歌 | Python | poetry.lock | pyproject.toml | ||
| RubyGems | Ruby | Gemfile.lock | Gemfile、*.gemspec | ||
| Swift 包管理器 | Swift | Package.resolved | |||
| Yarn | JavaScript | yarn.lock | package.json |
注意
- “Static transitive dependencies”列指示静态分析是否会为该生态系统中的依赖包添加
direct和transitive标签。**** 依赖项提交操作（自动或手动配置）可以为无法进行静态分析的生态系统添加可传递信息。 - 如果你在
setup.py文件中列出你的 Python 依赖项，我们可能无法分析和列出你项目中的每个依赖项。 - GitHub Actions 工作流必须位于要识别为清单的存储库的
.github/workflows/目录中。 使用jobs[*].steps[*].uses或jobs.<job_id>.uses语法引用的任何操作或工作流都将被分析为依赖项。 有关详细信息，请参阅“GitHub Actions 的工作流语法”。 - Dependabot 只会为使用语义版本控制的易受攻击的 GitHub Actions 创建 Dependabot alerts。 你将不会收到有关使用 SHA 版本控制的易受攻击操作的警报。 如果将 GitHub Actions 与 SHA 版本控制配合使用，建议为存储库或组织启用 Dependabot version updates 以保留更新到最新版本的操作。 有关详细信息，请参阅“关于 Dependabot 警报”和“关于 Dependabot 版本更新”。
清单去重
依赖项关系图可以通过三种不同的方式来了解依赖项：静态分析、自动提交和用户提交。 一个仓库可以配置多种方法，这会导致同一个包清单被扫描多次，而且每次扫描可能会产生不同的结果。 依赖项关系图使用去重逻辑来分析输出，为每个清单文件优先选取最准确的信息。
依赖项关系图会依据以下优先级规则，仅显示每个清单文件的一个实例。
- 用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。****
- 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
- 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。 有关关联器和检测器的详细信息，请参阅 适用于依赖项提交的 REST API 终结点。
- 自动提交具有第二高的优先级，因为它们同样是在项目构建期间创建的，但并非由用户提交。****
- 静态分析结果会在没有其他可用数据的情况下被采用。****