简介
依赖项审查操作会扫描您的拉取请求以查找依赖项更改,如果任何新的依赖项具有已知的漏洞,则会引发错误。安装后,如果工作流运行被标记为必需,则引入已知漏洞包的拉取请求将被阻止合并。
本指南将向您展示如何添加三种非常常见的自定义:基于漏洞严重性级别、依赖项许可证和范围的失败构建。
先决条件
本指南假设
- 已为仓库启用依赖关系图。公共仓库默认启用依赖关系图,您可以选择为私有仓库启用它。有关更多信息,请参阅“配置依赖关系图”。
- 已为仓库启用 GitHub Actions。有关更多信息,请参阅“管理仓库的 GitHub Actions 设置”。
步骤 1:添加依赖项审查操作
在此步骤中,我们将依赖项审查工作流添加到您的仓库。
-
在 GitHub 上,导航到仓库的主页。
-
在您的仓库名称下,单击 Actions.
-
在“开始使用 GitHub Actions”下,找到“安全”类别,然后单击查看全部。
-
找到“依赖项审查”,然后单击配置。或者,使用搜索栏搜索“依赖项审查”。
-
这将打开依赖项审查的 GitHub Actions 工作流文件,
dependency-review.yml
。它应包含以下内容YAML name: 'Dependency review' on: pull_request: branches: [ "main" ] permissions: contents: read jobs: dependency-review: runs-on: ubuntu-latest steps: - name: 'Checkout repository' uses: actions/checkout@v4 - name: 'Dependency Review' uses: actions/dependency-review-action@v4
name: 'Dependency review' on: pull_request: branches: [ "main" ] permissions: contents: read jobs: dependency-review: runs-on: ubuntu-latest steps: - name: 'Checkout repository' uses: actions/checkout@v4 - name: 'Dependency Review' uses: actions/dependency-review-action@v4
步骤 2:更改严重性
您可以通过将依赖项审查操作设置为必需来阻止包含漏洞依赖项的代码被合并。但是,值得注意的是,在某些情况下,阻止低风险漏洞可能过于严格。在此步骤中,我们将更改将导致构建失败的漏洞严重性,方法是使用fail-on-severity
选项。
-
将
fail-on-severity
选项添加到dependency-review.yml
文件的末尾YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate
- name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate
步骤 3:添加要阻止的许可证
漏洞并非阻止依赖项的唯一原因。如果您的组织对您可以使用的许可证类型有限制,您可以使用依赖项审查来使用deny-licenses
选项强制执行这些策略。在此步骤中,我们将添加一个自定义项,如果拉取请求引入包含 LGPL-2.0 或 BSD-2-Clause 许可证的依赖项,则会中断构建。
-
将
deny-licenses
选项添加到dependency-review.yml
文件的末尾YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate deny-licenses: LGPL-2.0, BSD-2-Clause
- name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate deny-licenses: LGPL-2.0, BSD-2-Clause
步骤 4:添加范围
最后,我们将使用fail-on-scopes
选项来防止将漏洞依赖项合并到特定的部署环境中,在本例中为开发环境。
-
将
fail-on-scopes
选项添加到dependency-review.yml
文件的末尾YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate deny-licenses: LGPL-2.0, BSD-2-Clause fail-on-scopes: development
- name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate deny-licenses: LGPL-2.0, BSD-2-Clause fail-on-scopes: development
步骤 5:检查配置
dependency-review.yml
文件现在应如下所示
name: 'Dependency Review' on: [pull_request] permissions: contents: read jobs: dependency-review: runs-on: ubuntu-latest steps: - name: 'Checkout Repository' uses: actions/checkout@v4 - name: Dependency Review uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate deny-licenses: LGPL-2.0, BSD-2-Clause fail-on-scopes: development
name: 'Dependency Review'
on: [pull_request]
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
with:
fail-on-severity: moderate
deny-licenses: LGPL-2.0, BSD-2-Clause
fail-on-scopes: development
您可以将此配置用作您自己的自定义配置的模板。
有关所有可能的自定义选项的更多信息,请参阅依赖项审查操作文档中的README。
最佳实践
自定义依赖项审查配置时,您可以遵循一些最佳实践
-
选择阻止列表而不是允许列表。编译要阻止的“非常糟糕”依赖项列表比创建要允许的所有库的包含列表更实用。
-
选择阻止许可证而不是指定允许哪些许可证。存在各种各样的许可证,因此通常排除您知道与当前许可证不兼容的许可证比编译完整的兼容许可证列表更实用。
-
选择
fail-on-severity
。基于漏洞严重性进行失败是平衡安全需求与为开发人员创建低摩擦体验需求的好方法。