简介
依赖项审查操作 扫描拉取请求,查看是否存在依赖项更改,如果有任何新的依赖项存在已知漏洞,则会引发错误。 安装后,如果工作流运行标记为必需,则会阻止引入已知易受攻击包的拉取请求被合并。
本指南介绍了如何添加三个非常常见的自定义:基于漏洞严重性级别、依赖项许可证和作用域的失败生成。
先决条件
本指南假定:
- 为存储库启用了依赖项关系图。有关详细信息,请参阅“配置依赖项关系图”。
- 为存储库启用 GitHub Actions。 有关详细信息,请参阅“管理存储库的 GitHub Actions 设置”。
步骤 1:添加依赖项评审操作
在此步骤中,我们将向存储库添加依赖项评审工作流。
-
在 GitHub 上,导航到存储库的主页面。
-
在存储库名称下,单击 “操作”。
-
在“开始使用 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
。 基于漏洞严重性失败是平衡安全需求和为开发人员打造低摩擦体验这一需求的好方法。
其他阅读材料
- “配置依赖项审查”