はじめに
依存関係レビュー アクション では、pull request で依存関係の変更をスキャンし、新しい依存関係に既知の脆弱性がある場合にエラーを発生させます。 インストールが完了すると、ワークフロー実行が必須としてマークされている場合、既知の脆弱なパッケージを導入する pull request のマージがブロックされます。
このガイドでは、脆弱性の重大度レベル、依存関係ライセンス、スコープに基づくビルドの失敗という 3 つの非常に一般的なカスタマイズを追加する方法について説明します。
前提条件
このガイドは、以下の読者を対象としています。
- リポジトリに対して依存関係グラフが有効になっています。 依存関係グラフはパブリック リポジトリに対して既定で有効になっており、プライベート リポジトリに対して有効にすることもできます。 詳細については、「依存関係グラフを設定する」を参照してください。
- リポジトリでは 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
オプションを使用してビルドが失敗する原因となる脆弱性の重大度を変更します。
-
dependency-review.yml
ファイルの末尾にfail-on-severity
オプションを追加します。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
オプションを使用してこれらのポリシーを適用できます。 この手順では、pull request が LGPL-2.0 または BSD-2-Clause ライセンスを含む依存関係を導入した場合にビルドを中断するカスタマイズを追加します。
-
dependency-review.yml
ファイルの末尾にdeny-licenses
オプションを追加します。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
オプションを使用して、脆弱な依存関係を特定のデプロイ環境 (この場合は開発環境) にマージしないようにします。
-
dependency-review.yml
ファイルの末尾にfail-on-scopes
オプションを追加します。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
を選択します。 脆弱性の重大度に基づいて失敗することは、セキュリティの必要性と、開発者向けの低摩擦エクスペリエンスを作成する必要性とのバランスを取るには良い方法です。