Skip to main content

此版本的 GitHub Enterprise Server 已于以下日期停止服务 2024-09-24. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

Customizing your dependency review action configuration

Learn how to add a basic customization to your dependency review configuration.

谁可以使用此功能?

The 依赖项审查操作 is available for organization-owned repositories in GitHub Enterprise Server. This feature requires a license for GitHub Advanced Security. 有关详细信息,请参阅“关于 GitHub 高级安全性”。

Introduction

The 依赖项审查操作 scans your pull requests for dependency changes and raises an error if any new dependencies have known vulnerabilities. Once installed, if the workflow run is marked as required, pull requests introducing known vulnerable packages will be blocked from merging.

This guide shows you how to add three very common customizations: failing builds based on vulnerability severity level, dependency license, and scope.

Prerequisites

This guide assumes that:

Step 1: Adding the dependency review action

In this step, we'll add the dependency review workflow to your repository.

  1. 在 你的 GitHub Enterprise Server 实例 上,导航到存储库的主页。

  2. 在存储库名称下,单击 “操作”。

    “github/docs”存储库的选项卡的屏幕截图。 “操作”选项卡以橙色边框突出显示。

  3. Under "Get started with GitHub Actions", find the "Security" category, then click View all.

  4. Find "Dependency review", then click Configure. Alternatively, search for "Dependency review" using the search bar.

  5. This will open dependency review’s GitHub Actions workflow file, dependency-review.yml. It should contain the following:

    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
    

Step 2: Changing the severity

You can block code containing vulnerable dependencies from ever being merged by setting the 依赖项审查操作 to required. However, it's worth noting that blocking low-risk vulnerabilities may be too restrictive in some circumstances. In this step, we will change the severity of vulnerability that will cause a build to fail with the fail-on-severity option.

  1. Add the fail-on-severity option to the end of the dependency-review.yml file:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
    

Step 3: Adding licenses to block

Vulnerabilities aren’t the only reason you might want to block a dependency. If your organization has restrictions on what sorts of licenses you can use, you can use dependency review to enforce those policies with the deny-licenses option. In this step, we will add a customization that will break the build if the pull request introduces a dependency that contains the LGPL-2.0 or BSD-2-Clause license.

  1. Add the deny-licenses option to the end of the dependency-review.yml file:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
              deny-licenses: LGPL-2.0, BSD-2-Clause
    

Step 4: Adding scopes

Finally, we'll use the fail-on-scopes option to prevent merging vulnerable dependencies to specific deployment environments, in this case the development environment.

  1. Add the fail-on-scopes option to the end of the dependency-review.yml file:

    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
    

Step 5: Check the configuration

The dependency-review.yml file should now look like this:

YAML

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

You can use this configuration as a template for your own custom configurations.

For more information on all the possible customization options, see the README in the dependency review action documentation.

Best practices

When customizing your dependency review configuration, there are some best practices you can follow:

  • Choose block lists over allow lists. It is more practical to compile a list of the "really bad" dependencies you want to block than to create an inclusive list of all the libraries you want to allow.

  • Choose to block licenses instead of specifying which licenses to allow. There are a wide variety of licenses out there, so it's usually more practical to exclude those you know are incompatible with current licenses than it is to compile a complete list of compatible licenses.

  • Choose fail-on-severity. Failing based on the severity of a vulnerability is a good way to balance the need for security with the need to create low-friction experiences for developers.

Further reading