关于依赖项审查

关于依赖项审查

依赖项审查可帮助您了解依赖项更改以及这些更改对每个拉取请求的安全影响。它提供了易于理解的依赖项更改可视化效果，并在拉取请求的“已更改文件”选项卡中提供了丰富的差异。依赖项审查会告知您

• 添加、删除或更新了哪些依赖项，以及发布日期。
• 有多少项目使用这些组件。
• 这些依赖项的漏洞数据。

对于包含对包清单或锁定文件更改的拉取请求，您可以显示依赖项审查以查看发生了哪些更改。依赖项审查包括对锁定文件中间接依赖项更改的详细信息，并告诉您任何添加或更新的依赖项是否包含已知的漏洞。

有时您可能只想更新清单中一个依赖项的版本并生成拉取请求。但是，如果此直接依赖项的更新版本也具有更新的依赖项，则您的拉取请求可能包含超出预期的更多更改。每个清单和锁定文件的依赖项审查提供了一种简单的方法来查看发生了哪些更改，以及任何新的依赖项版本是否包含已知的漏洞。

通过检查拉取请求中的依赖项审查，并更改标记为存在漏洞的任何依赖项，您可以避免将漏洞添加到您的项目中。有关依赖项审查工作原理的更多信息，请参阅“在拉取请求中审查依赖项更改”。

有关配置依赖项审查的更多信息，请参阅“配置依赖项审查”。

Dependabot 警报将查找已存在于您的依赖项中的漏洞，但避免引入潜在问题比在以后修复问题要好得多。有关 Dependabot 警报的更多信息，请参阅“关于 Dependabot 警报”。

依赖项审查支持与依赖关系图相同的语言和包管理生态系统。有关更多信息，请参阅“依赖关系图支持的包生态系统”。

有关 GitHub 上提供的供应链功能的更多信息，请参阅“关于供应链安全”。

依赖项审查强制执行

此操作适用于所有公共存储库，以及启用了 GitHub 高级安全性的私有存储库。

组织所有者可以通过在整个组织的存储库中强制使用依赖项审查操作来大规模推出依赖项审查。这涉及使用存储库规则集，您将在其中将依赖项审查操作设置为必需的工作流，这意味着只有在工作流通过所有必需的检查后才能合并拉取请求。有关更多信息，请参阅“在整个组织中强制执行依赖项审查”。

您可以在您的存储库中使用 dependency-review-action 以在您的拉取请求上强制执行依赖项审查。该操作会扫描拉取请求中由包版本更改引入的依赖项的漏洞版本，并警告您相关的安全漏洞。这使您可以更好地了解拉取请求中发生了哪些更改，并有助于防止将漏洞添加到您的存储库中。

默认情况下，如果依赖项审查操作检查发现任何存在漏洞的包，则该检查将失败。当存储库所有者要求依赖项审查检查通过时，失败的检查会阻止拉取请求合并。有关更多信息，请参阅“关于受保护的分支”。

此操作使用依赖项审查 REST API 获取基本提交和头部提交之间依赖项更改的差异。您可以使用依赖项审查 API 获取依赖项更改的差异，包括任何两个存储库提交之间的漏洞数据。有关更多信息，请参阅“依赖项审查的 REST API 端点”。此操作还会考虑通过依赖项提交 API 提交的依赖项。有关依赖项提交 API 的更多信息，请参阅“使用依赖项提交 API”。

您可以配置依赖项审查操作以更好地满足您的需求。例如，您可以指定导致操作失败的严重性级别，或为要扫描的许可证设置允许或拒绝列表。有关更多信息，请参阅“配置依赖项审查”。

一起使用依赖项审查 API 和依赖项提交 API 的最佳实践

依赖项审查 API 和依赖项审查操作都通过将拉取请求中的依赖项更改与目标分支的头部提交中依赖项的状态进行比较来工作。

如果您的存储库仅依赖于 GitHub 支持的某个生态系统中静态定义的依赖项，则依赖项审查 API 和依赖项审查操作将一致地工作。

但是，您可能希望在构建过程中扫描依赖项，然后将其上传到依赖项提交 API。在这种情况下，您应该遵循一些最佳实践，以确保在运行依赖项审查 API 和依赖项提交 API 的流程时不会引入竞争条件，因为这可能导致数据丢失。

您应采取的最佳实践将取决于您是否使用 GitHub Actions 访问依赖项提交 API 和依赖项审查 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 编码的字符串）中看到对此的说明。因此，如果标头非空，则应考虑重试。
  • 实现具有指数退避重试的重试逻辑。
  • 实现合理的重试次数，以考虑依赖项提交代码的典型运行时间。

进一步阅读

• "自定义您的依赖项审查操作配置"