关于依赖审查
依赖性审查帮助您了解依赖项的变更及这些变更的安全影响。它在拉取请求的“文件更改”标签页提供了可易于理解的依赖变更可视化以及丰富的差异。依赖性审查会提醒您
- 哪些依赖被添加、移除或更新，以及它们的发布时间
- 有多少项目使用这些组件
- 这些依赖的漏洞数据
对于包含包清单或锁文件更改的拉取请求，您可以显示依赖性审查以查看具体变动。依赖性审查会包括锁文件中间接依赖的变更详情，并告知您新增或更新的依赖是否包含已知漏洞。
注意
“依赖性审查操作”指的是能够在 GitHub Actions 环境中报告拉取请求差异并向工作流添加强制执行机制的特定操作。更多信息，请参阅本文后面的 依赖性审查操作。
有时您可能只想在清单中更新单个依赖的版本并生成一个拉取请求。然而，如果此直接依赖的更新版本还带来了其自身的更新依赖，您的拉取请求可能会出现比预期更多的更改。针对每个清单和锁文件的依赖性审查提供了一种简便方式，以查看具体的变更以及新的依赖版本是否包含已知漏洞。
通过检查拉取请求中的依赖性审查并更改所有被标记为有漏洞的依赖，您可以避免将漏洞引入项目。有关依赖性审查工作原理的更多信息，请参阅 在拉取请求中审查依赖项变更。
Dependabot 警报会发现您已存在的依赖中的漏洞，但避免潜在问题的产生要比事后修复更好。有关 Dependabot 警报的更多信息，请参阅 关于 Dependabot 警报。
依赖性审查支持与依赖关系图相同的语言和包管理生态系统。更多信息，请参阅 依赖关系图支持的包生态系统。
有关 GitHub 上可用的供应链功能的更多信息，请参阅 关于供应链安全。
启用依赖性审查
当您启用依赖关系图后，依赖性审查功能即会可用。更多信息，请参阅 启用依赖关系图."
关于依赖性审查操作
“依赖性审查操作”指的是能够在 GitHub Actions 环境中报告拉取请求差异的特定操作。请参阅 dependency-review-action。您可以在仓库中使用依赖性审查操作来对拉取请求强制执行依赖性审查。该操作会扫描因拉取请求中的包版本更改而引入的易受攻击的依赖版本，并提醒您相关的安全漏洞。这让您对拉取请求中的变更拥有更好的可视性，并帮助防止漏洞被加入到仓库中。
默认情况下，如果发现任何易受攻击的包，依赖性审查操作检查将失败。当仓库所有者要求依赖性审查检查通过时，失败的检查会阻止拉取请求的合并。更多信息，请参阅 关于受保护分支。
该操作适用于所有公共仓库，以及已启用 GitHub 代码安全或 GitHub 高级安全的私有仓库。
组织所有者可以通过在组织内的所有仓库强制使用依赖性审查操作，实现规模化的依赖性审查部署。这需要使用仓库规则集，将依赖性审查操作设为必需工作流，从而只有在工作流通过所有必需检查后才能合并拉取请求。更多信息，请参阅 在组织中强制执行依赖性审查。
该操作使用依赖性审查 REST API 来获取基准提交与目标分支 HEAD 提交之间的依赖变更差异。您可以使用依赖性审查 API 获取任意两次提交之间的依赖变更差异（包括漏洞数据）。更多信息，请参阅 依赖性审查的 REST API 端点。该操作还会考虑通过依赖性提交 API 提交的依赖。有关依赖性提交 API 的更多信息，请参阅 使用依赖性提交 API。
注意
依赖审查 API 与依赖提交 API 协同工作。这意味着依赖审查 API 将包含通过依赖提交 API 提交的依赖项。
您可以对依赖性审查操作进行配置，以更好地满足需求。例如，您可以指定导致操作失败的严重性级别，或为要扫描的许可证设置允许或拒绝列表。更多信息，请参阅 配置依赖性审查操作。
同时使用依赖性审查 API 与依赖性提交 API 的最佳实践
依赖性审查 API 与依赖性审查操作都通过比较拉取请求中的依赖变更与目标分支 HEAD 提交时的依赖状态来工作。
如果您的仓库仅依赖 GitHub 支持的某一生态系统中静态声明的依赖，依赖性审查 API 与依赖性审查操作的行为是一致的。
然而，您可能希望在构建期间扫描依赖并将结果上传至依赖性提交 API。在这种情况下，您需要遵循一些最佳实践，以避免在同时运行依赖性审查 API 与依赖性提交 API 时出现竞争条件，从而导致数据缺失。
应采取的最佳实践取决于您是使用 GitHub Actions 访问这两个 API，还是直接使用 API 调用。
使用 GitHub Actions 访问依赖性提交 API 与依赖性审查 API
如果您使用 GitHub Actions 访问依赖性提交 API 或依赖性审查 API
- 请确保将所有依赖性提交操作与依赖性审查操作放在同一个 GitHub Actions 工作流中执行。这可以让您控制执行顺序，并确保依赖性审查始终能够工作。
- 如果您选择将依赖性审查操作单独运行，您应当
- 将
retry-on-snapshot-warnings设置为true。 - 将
retry-on-snapshot-warnings-timeout设置为略高于您最长的依赖性提交操作的典型运行时（单位：秒）。
- 将
使用直接 API 访问依赖性提交 API 与依赖性审查 API
如果您不使用 GitHub Actions，而是直接调用依赖性提交 API 与依赖性审查 API
- 请确保先运行调用依赖性提交 API 的代码，然后再运行调用依赖性审查 API 的代码。
- 如果您选择并行运行依赖性提交 API 与依赖性审查 API 的代码，则应实现重试逻辑，并注意以下事项
- 当任一侧的快照缺失时，您将在
x-github-dependency-graph-snapshot-warnings响应头（以 base64 编码的字符串形式）中看到相应说明。因此，只要该头部非空，就应考虑进行重试。 - 实现带指数退避的重试逻辑。
- 设置合理的重试次数，以覆盖依赖性提交代码的典型运行时。
- 当任一侧的快照缺失时，您将在