セキュリティで保護された使用に関するリファレンス

ワークフローを作成し、GitHub Actions のセキュリティ機能を使う場合のセキュリティのベスト プラクティスについて説明します。

ワークフローの書き込み

機密情報にはシークレットを使用する

シークレットの値を変換する方法は複数あるため、この自動リダクトは保証されません。 シークレットに関連するリスクを最小限に抑えるために、次のベスト プラクティスに従ってください。

•         **最小限の特権の原則**
  

  • リポジトリへの書き込みアクセス権限を持つすべてのユーザーは、リポジトリに構成されているすべてのシークレットへの読み取りアクセス権を持っています。 そのため、ワークフロー内で使われる認証情報が持つ特権は必要最小限のものにする必要があります。
  • Actions は、GITHUB_TOKEN コンテキストからアクセスすることで github.token を使用できます。 詳しくは、「コンテキスト リファレンス」をご覧ください。 したがって、GITHUB_TOKEN に最低限必要な権限が付与されていることを確認する必要があります。 リポジトリの内容の読み取りアクセスのみを行うように GITHUB_TOKEN の既定のアクセス許可を設定することを、セキュリティの点からお勧めします。 その後、必要に応じて、ワークフローファイル内の個々のジョブの権限を増やすことができます。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

•         **機密データをマスクする**
  

  • 機密データは、ワークフロー ファイルにプレーンテキストとして格納しないでください。 ::add-mask::VALUE を使って、GitHub シークレットではないすべての機密情報をマスクします。 これにより、値がシークレットとして扱われ、ログから編集されます。 データのマスキングの詳細については、「GitHub Actions のワークフロー コマンド」を参照してください。

•         **外部から参照可能な状態になっているシークレットを削除してローテーションする**
  

  • シークレットの編集は、ワークフロー ランナーによって実行されます。 つまり、シークレットはジョブ内で使用され、実行者によりアクセス可能である場合のみ編集されます。 未変換のシークレットがワークフロー実行ログに送信される場合は、ログを削除してシークレットをローテーションする必要があります。 ログの削除の詳細については、「ワークフロー実行ログの使用」を参照してください。

•         **構造化データをシークレットとして使わない**
  

  • 構造化データは、ログ内のシークレットの編集失敗の原因となる可能性があります。これは、編集が特定のシークレット値の完全一致を見つけることに大きく依存しているためです。 たとえば、JSON、XML、または YAML（または同様）の Blob を使用してシークレット値をカプセル化しないでください。シークレットが適切に編集される可能性が大幅に低下するためです。 代わりに、機密値ごとに個別のシークレットを作成します。

•         **ワークフロー内で使われるすべてのシークレットを登録する**
  

  • シークレットを使ってワークフロー内で別の機密値を生成する場合は、その生成された値を正式にシークレットとして登録して、ログに表示されることがある場合は編集された状態になるようにする必要があります。 たとえば、秘密鍵を使用して署名済み JWT を生成し、Web API にアクセスする場合は、その JWT をシークレットとして登録してください。そうしない場合、ログ出力に入力されても編集されません。
  • シークレットの登録は、あらゆる種類の変換/エンコーディングにも適用されます。 シークレットが何らかの方法で変換された場合（Base64 や URL エンコードなど）、新しい値もシークレットとして登録してください。

•         **シークレットの処理方法を監査する**
  

  • シークレットの使用方法を監査し、シークレットが想定どおりに処理されていることを確認します。 これを行うには、ワークフローを実行しているリポジトリのソースコードを確認し、ワークフローで使用されているアクションを確認します。 たとえば、意図しないホストに送信されていないか、またはログ出力に明示的に出力されていないかを確認します。
  • 有効/無効な入力をテストした後、ワークフローの実行ログを表示し、シークレットが正しく編集されているか、表示されていないかを確認します。 呼び出しているコマンドまたはツールがどのようにしてエラーを STDOUT や STDERR に送信するかは必ずしも明らかではなく、シークレットが後でエラー ログに記録される可能性があります。 そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。 機密データが意図せず含まれている可能性があるワークフロー ログをクリーンアップする方法については、「ワークフロー実行ログの使用」を参照してください。

•         **登録されたシークレットの監査とローテーションを行う**
  

  • 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。 不要になったものは削除してください。
  • シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。

•         **シークレットへのアクセスのレビューを必須にすることを検討する**
  

  • 必須のレビュー担当者を使って環境のシークレットを保護できます。 レビュー担当者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。 環境へのシークレットの格納や環境のレビューの要求の詳細については、「GitHub Actions でのシークレットの使用」と「デプロイメント用の環境管理」を参照してください。

スクリプト インジェクション攻撃を軽減するための優れたプラクティス

ワークフローにおけるスクリプト インジェクションのリスクを軽減するための推奨されるアプローチ:

インライン スクリプトの代わりにアクションを使う

推奨されるアプローチは、コンテキストの値を引数として処理するアクションを作成することです。 このアプローチは、コンテキストの値はシェル スクリプトの生成には使われず、代わりに引数としてアクションに渡されるため、インジェクション攻撃に対して脆弱ではありません。

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

中間環境変数を使用する

インライン スクリプトの場合、信頼されない入力を処理するための推奨される方法は、式の値を中間環境変数に設定することです。 次の例では、Bash を使って github.event.pull_request.title の値を環境変数として処理しています。

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

この例では、スクリプトの挿入の試行が失敗し、ログの行で次のように示されています。

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

この方法では、${{ github.event.pull_request.title }} 式の値はメモリに格納されて変数として使われ、スクリプト生成プロセスとはやり取りされません。 さらに、二重引用符シェル変数を使って単語分割を回避することを検討します。ただし、これはシェル スクリプトの記述に関する多くの一般的な推奨事項の 1 つであり、GitHub Actions に固有ではありません。

トークンのアクセス許可を制限する

公開されたトークンのリスクを軽減するには、割り当てられるアクセス許可を制限することを検討します。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

信頼されていないコードのチェックアウトに伴うリスクを軽減する

スクリプト インジェクション攻撃と同様に、アクション処理を自動的にトリガーする信頼されていない pull request コンテンツもセキュリティ リスクの原因となる可能性があります。 信頼されていない pull request のチェックアウトと共に pull_request_target および workflow_run ワークフロー トリガーを使うと、リポジトリがセキュリティ侵害の危険にさらされることになります。 これらのワークフローは特権を持っています。つまり、他の特権ワークフロー トリガーと同様にメイン ブランチのキャッシュを共有し、リポジトリの書き込みアクセス権限や、参照対象のシークレットへのアクセス権を持っている可能性があります。 これらの脆弱性が悪用されると、リポジトリが乗っ取られる可能性があります。

これらのトリガー、その使用方法、関連するリスクの詳細については、「ワークフローをトリガーするイベント」と「ワークフローをトリガーするイベント」を参照してください。

信頼されていないコードのチェックアウトに伴うリスクに関するその他の例とガイダンスについては、GitHub Security Lab の「pwn 要求を防ぐ」と、OpenSSF Scorecard の Dangerous-Workflow のドキュメントを参照してください。

推奨されるプラクティス

• 必要がない場合は、pull_request_target ワークフロー トリガーを使わないでください。 ワークフロー間の特権の分離には、workflow_run の方が適切なトリガーです。 ワークフローで実際に特権コンテキストが必要な場合にのみ、これらのワークフロー トリガーを使ってください。

• 信頼されていない pull request またはコード コンテンツで pull_request_target および workflow_run ワークフロー トリガーを使うことは避けてください。 これらのトリガーを使うワークフローでは、(pull request のフォークや自分の管理下にないリポジトリなどの) 信頼されていないコードを明示的にチェックアウトしてはなりません。 workflow_run 上でトリガーされるワークフローでは、他のワークフローからアップロードされた成果物を慎重に扱う必要があります。

• CodeQL を使うと、潜在的に脆弱な GitHub Actions ワークフローをスキャンして検出できます。 リポジトリの既定の設定を構成し、GitHub Actions スキャンが有効になっていることを確認できます。 詳しくは、「コード スキャンの既定セットアップの構成」をご覧ください。

• GitHub Actions を使っている場合、OpenSSF Scorecard は潜在的に脆弱なワークフローやその他のセキュリティ リスクを特定するのに役立ちます。 この記事で後述する「OpenSSF Scorecards を使ってワークフローの依存関係をセキュリティで保護する」を参照してください。

サードパーティアクションを使用する

ワークフロー内の個々のジョブは、他のジョブと相互作用（および侵害）する場合があります。 たとえば、後のジョブで使用される環境変数をクエリするジョブ、後のジョブが処理する共有ディレクトリにファイルを書き込むジョブ、あるいはもっと直接的にDocker ソケットとやり取りして他の実行中のコンテナを検査してコマンドを実行するジョブなどです。

つまり、ワークフロー内の 1 つのアクションが侵害されると、その侵害されたアクションがリポジトリで構成されているすべてのシークレットにアクセスでき、GITHUB_TOKEN を使ってリポジトリに書き込むことができる場合があるため、非常に大きな問題になる可能性があります。 したがって、GitHub のサードパーティリポジトリからアクションを調達することには大きなリスクがあります。 攻撃者が行う可能性があるステップの一部については、「セキュリティで保護された使用に関するリファレンス」を参照してください。

次のような適切な方法に従うことで、このリスクを軽減することができます。

•         **アクションを完全な長さのコミット SHA にピン止めする**
  

  現在、アクションを不変のリリースとして使う唯一の方法は、アクションを完全なコミット SHA にピン留めすることです。 特定の SHA にピン止めすると、有効な Git オブジェクトペイロードに対して SHA-1 衝突を生成する必要があるため、悪意のある人がアクションのリポジトリにバックドアを追加するリスクを軽減できます。 SHA を選択するときは、アクションのリポジトリからであり、リポジトリ フォークではないことを確認してください。

  ワークフローで完全なコミット SHA を使う例については、「ワークフローで事前に作成されたビルディング ブロックを使用する」を参照してください。

•         **アクションのソース コードを監査する**
  

  アクションが想定どおりにリポジトリとシークレットのコンテンツを処理していることを確認します。 たとえば、シークレットが意図しないホストに送信されていないか、または誤ってログに記録されていないかを確認します。

•         **作成者を信頼できる場合に限り、アクションをタグにピン止めする**
  

  コミット SHA に対するピン止めが最も安全なオプションですが、タグを指定する方が便利で広く使用されています。 タグを指定する場合は、アクションの作成者が信頼できることを確認してください。 GitHub Marketplace の「Verified creator」バッジは便利な判断材料で、 GitHub で身元が確認されたチームによって作成されたアクションであることを示しています。 作者が信頼できる場合でも、このアプローチにはリスクがあることに注意してください。悪意のある人がアクションを保存しているリポジトリにアクセスすると、タグが移動または削除される可能性があります。

サード パーティのワークフローを再利用する

サード パーティのアクションの使用に関して上で説明したものと同じ原則が、サード パーティのワークフローの使用にも適用されます。 上と同じ適切なプラクティスに従うことで、ワークフローの再利用に関連するリスクを軽減できます。 詳しくは、「ワークフローを再利用する」をご覧ください。

GitHub のセキュリティ機能

GitHubには、コードのセキュリティを強化する多くの機能が用意されています。 GitHubのビルトイン機能を使用し、ワークフローが依存するアクションの理解、実行するアクションの脆弱性に関する通知を受け取れるようにし、ワークフロー内のアクションを最新の状態に保つプロセスを自動化できます。 アクションを公開して維持した場合、GitHubを使用して脆弱性とその修正方法についてコミュニティとコミュニケーションが取れます。 GitHubが提供するセキュリティ機能の詳細については、「GitHub セキュリティ機能」を参照してください。

          `CODEOWNERS` を使用して変更を監視する

          `CODEOWNERS` 機能を使って、ワークフロー ファイルの変更方法を制御できます。 たとえば、すべてのワークフロー ファイルが `.github/workflows` に格納されている場合、このディレクトリをコード所有者リストに追加すると、これらのファイルへの変更案には、まず指定されたレビュー担当者による承認が必要になります。

詳しくは、「コードオーナーについて」をご覧ください。

組織のGitHub Actions設定のアクセス許可を管理する

カスタム Organization ロールを管理することにより、GitHub Actions で Organization の CI/CD パイプラインにおける最小特権の原則を実践できます。 カスタム組織の役割は、組織とそのリポジトリの完全な権限を持った管理を許可することなく、組織の個人またはチームに対して設定の特定サブセットを管理する権限を許可する方法です。

GitHub Actions、Organization 内の個人またはチームに対して以下のいずれかのアクセス許可を有効にすることができます。

• Organization のアクション ポリシーを管理: セルフホステッド ランナーの設定を除き、[アクション全般] 設定ページのすべての設定を管理するためのアクセス。
• Organization ランナーとランナー グループを管理: GitHub でホストされるランナー、セルフホステッド ランナー、ランナー グループを作成および管理し、セルフホステッド ランナーを作成できる場所を制御するためのアクセス。
• Organization のアクション シークレットを管理: アクションの Organization シークレットを作成および管理するためのアクセス。
• Organization のアクション変数を管理: アクションの Organization 変数を作成および管理するためのアクセス。

詳しくは、「カスタム組織ロールの権限」をご覧ください。

OpenID Connect を使用してクラウド リソースにアクセスする

{データ再利用可能な.actions.about-oidc-short-overview }

Dependabot version updates を使用してアクションを最新の状態に維持する

リポジトリで使用されるアクションおよび再利用可能なワークフローのリファレンスを常に最新の状態に保つため、Dependabotを使用できます。 多くの場合、アクションはバグ修正および新しい機能で更新され、自動化プロセスの速度、安全性、信頼性が向上しています。 Dependabotは、依存関係の保守を自動的に実行するため、作業量が軽減されます。 詳細については、「Dependabot でアクションを最新に保つ」および「Dependabot のセキュリティ アップデート」を参照してください。

ワークフローが内部リポジトリとプライベート リポジトリにアクセスできるようにする

プライベート リポジトリを他のリポジトリの GitHub Actions ワークフローからアクセスできるようにする場合、プライベート リポジトリに直接アクセスできない他のリポジトリの外部コラボレーターは、プライベート リポジトリに間接的にアクセスできます。 外部コラボレーターは、プライベート リポジトリのアクションまたはワークフローが使用されている場合に、ワークフローの実行をログで確認できます。 詳細については、「アクションとワークフローを企業と共有する」を参照してください。

ランナーがこれらのアクションをダウンロードできるように、GitHub はスコープ付きのインストール トークンをランナーに渡します。 このトークンはリポジトリへの読み取りアクセス権を持ち、1 時間後に自動的に期限切れになります。

GitHub Actions による pull request の作成または承認を回避する

GitHub Actions ワークフローでの pull request の作成または承認を許可するか禁止するかを選択できます。 ワークフローまたは他のオートメーションが pull request を作成または承認できるようにすると、pull request のマージが適切な監視なしで行われる場合、セキュリティ リスクが発生する可能性があります。

この設定を構成する方法の詳細については、「企業でGitHub Actionsのポリシーを適用する」、「Organization の GitHub Actions の無効化または制限」、「リポジトリのGitHub Actions設定の管理」を参照してください。

OpenSSF Scorecards を使ってワークフローの依存関係をセキュリティで保護する

          [Scorecards](https://github.com/ossf/scorecard) は、リスクの高いサプライ チェーン プラクティスにフラグを設定する自動セキュリティ ツールです。 
          [Scorecards アクション](https://github.com/marketplace/actions/ossf-scorecard-action)と[ワークフロー テンプレート](https://github.com/actions/starter-workflows)を使って、セキュリティのベスト プラクティスに従うことができます。 構成された Scorecards アクションは、リポジトリが変更されると自動的に実行され、ビルトイン code scanning 環境を使用してリスクの高いサプライ チェーン プラクティスについて開発者に警告します。 Scorecards プロジェクトでは、スクリプト インジェクション攻撃、トークンのアクセス許可、ピン留めされたアクションなど、さまざまなチェックが実行されます。

GitHub を扱うホストランナー

セルフホストランナーを強化する

GitHub のセルフホステッド ランナーは、一時的でクリーンな仮想マシンでの実行に関する保証がなく、ワークフロー内の信頼されていないコードによって永続的に侵害される可能性があります。

プライベートまたは内部リポジトリでセルフホステッド ランナーを使うときは注意が必要です。リポジトリをフォークして pull request (プル リクエスト) を開くことができるユーザー (通常は、リポジトリへの読み取りアクセス権を持つユーザー) は、セルフホステッド ランナー環境を侵害できます。それには、シークレットへのアクセスや、リポジトリへの書き込みアクセス権を設定に応じて付与できる GITHUB_TOKEN の取得が含まれます。 ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

データの使い回し アクション.disabled-selfhosted-runners-crossrefs %}

セルフホステッド ランナーが organization または Enterprise のレベルで定義されている場合、GitHub は同じランナーに対して複数のリポジトリからのワークフローをスケジュールできます。 したがって、これらの環境へのセキュリティ侵害は、大きな影響をもたらす可能性があります。 侵害の範囲を狭めるために、セルフホストランナーを個別のグループにまとめることで、境界を作ることができます。 ランナー グループにアクセスできるワークフロー、組織、リポジトリを制限できます。 詳しくは、「グループを使用してセルフホストランナーへのアクセスを管理する」をご覧ください。

次のように、セルフホストランナーマシンの環境も考慮する必要があります。

• セルフホストランナーとして設定されたマシンにはどのような機密情報が存在するか。 たとえば、SSH 秘密鍵、API アクセストークンなどです。
• マシンが機密性の高いサービスにネットワークアクセス可能か。 たとえば、Azureや AWS メタデータ サービスなどです。 この環境での機密情報量は最小限に抑える必要があります。ワークフローを呼び出すことができるすべてのユーザがこの環境にアクセスできることを常に意識しておいてください。

中には、それぞれのジョブの実行後にセルフホストランナーを自動的に破棄するようなシステムを実装することで、このリスクを部分的に軽減しようとするお客様もいます。 しかし、このアプローチは意図したほどには効果的ではないかもしれません。これは、セルフホストランナーが1つのジョブだけを実行するという保証がないためです。 一部のジョブでは、コマンド ライン引数としてシークレットが使われ、同じランナーで実行している別のジョブで見ることができます (ps x -w など)。 これにより、シークレットが漏えいする可能性があります。

ジャストインタイムランナーの使用

ランナー登録のセキュリティを向上させるために、REST API を使ってエフェメラル Just-In-Time (JIT) ランナーを作成できます。 これらのセルフホステッド ランナーは、リポジトリ、組織、またはエンタープライズから自動的に削除される前に、最大 1 つのジョブを実行します。 JIT ランナーの構成の詳細については、「セルフホステッド ランナーの REST API エンドポイント」を参照してください。

REST API の応答から構成ファイルを作成したら、ランナーに起動時に渡すことができます。

./run.sh --jitconfig ${encoded_jit_config}

セルフホステッドランナーの管理戦略を計画する

セルフホステッド ランナーは、GitHub 階層のさまざまなレベル (Enterprise、Organization、リポジトリ レベル) に追加できます。 この配置により、ランナーを管理できるユーザーが決まります。

          **一元管理:**

• 一元化されたチームでセルフホステッド ランナーを所有する場合は、最も高い相互 Organization または Enterprise レベルにランナーを追加することをお勧めします。 これにより、チームは 1 つの場所でランナーを表示および管理できます。

• Organization が 1 つだけの場合、Organization レベルでランナーを追加するのは実質的に同じ方法ですが、将来別の Organization を追加したときに問題が発生する可能性があります。

          **分散管理:**
  

• 各チームが自分のセルフホステッド ランナーを管理する場合は、チームの所有権の最上位レベルでランナーを追加することをお勧めします。 たとえば、各チームが自分の Organization を所有している場合は、ランナーも Organization レベルで追加すると最も簡単になります。

• リポジトリ レベルでランナーを追加することもできますが、リポジトリ間ではランナーを共有できないため、管理オーバーヘッドが増加し、必要なランナーの数も増えます。

クラウド プロバイダーへの認証を行う

GitHub Actions を使ってクラウド プロバイダーにデプロイする場合、またはシークレット管理に HashiCorp Vault を使う場合は、OpenID Connect を使って、ワークフロー実行用に有効期間が短く、適切なスコープ設定のアクセス トークンの作成を検討することをお勧めします。 詳しくは、「OpenID Connect」をご覧ください。

GitHub Actionsイベントの監査

セキュリティ ログを使用してユーザー アカウントのアクティビティを監視し、監査ログを使用して組織または Enterpriseのアクティビティを監視できます。 セキュリティおよび監査ログには、アクションの種類、実行された日時、アクションを実行した個人アカウントが記録されます。

たとえば、監査ログを使って、Organization のシークレットへの変更を追跡する org.update_actions_secret イベントを追跡できます。

各アカウントの種類の監査ログに表示されるイベントの完全な一覧については、次の記事を参照してください。

•         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events)
  

• 「Organization の監査ログ イベント」
• 「企業向け監査ログイベント」

ワークフローの依存関係について理解する

依存関係グラフを使用し、リポジトリのワークフローが使用するアクションを調べることができます。 依存関係グラフは、リポジトリに保存されたマニフェストとロック ファイルの概要です。 また、./github/workflows/ 内のファイルもマニフェストとして認識されます。つまり、構文 jobs[*].steps[*].uses または jobs.<job_id>.uses を使って参照されるすべてのアクションまたはワークフローは、依存関係として解析されます。

依存関係グラフには、ワークフローで使用されるアクションに関する次の情報が表示されます。

• アクションを所有するアカウントまたは組織。
• アクションを参照するワークフロー ファイル。
• アクションの固定先であるバージョンまたはSHA。

依存関係グラフでは、依存関係は脆弱性の重大度によって自動的に並べ替えられます。 使用するいずれかのアクションにセキュリティ アドバイザリがある場合、リストの上部に表示されます。 依存関係グラフからアドバイザリに移動し、脆弱性を解決する手順にアクセスできます。

Enterprise 所有者は Enterprise に対して依存関係グラフと Dependabot alerts を構成できます。 詳細については、「企業の依存関係グラフの有効化」を参照してください。

使用するアクションのセキュリティ脆弱性を認識する

マーケットプレースで利用可能なアクションの場合、GitHubは関連するセキュリティ アドバイザリを確認し、それらのアドバイザリをGitHub Advisory Databaseに追加します。 データベースを検索して既存の脆弱性に関する情報とその修正方法の手順を見つけるため、使用するアクションを調べることができます。 検索を効率化するには、GitHub Advisory DatabaseでGitHub Actionsフィルターを使用します。

次のことができるようにリポジトリを設定できます。

• ワークフローで使用されるアクションが脆弱性レポートを受け取ったときにアラートを受信します。 詳細については、「ワークフローのアクションを監視する」を参照してください。
• ワークフローでアクションを追加または更新すると、既存のアドバイザリに関する警告が表示されます。 詳細については、「新規または更新されたワークフローで脆弱性に対するアクションのスクリーニング」を参照してください。

ワークフローでアクションを監視する

Dependabotを使用してワークフローのアクションを監視し、Dependabot alertsを有効にして使用するアクションに報告された脆弱性があるときに通知されるようにすることができます。 Dependabotは、有効にしたリポジトリの既定のブランチにスキャンを実行し、不安定な依存関係を検知します。 Dependabotは、新しいアドバイザリがGitHub Advisory Databaseに追加されるか、使用するアクションが更新された場合、Dependabot alertsを生成します。

お客様が使用中のリポジトリに対応する Dependabot alerts を管理する前に、エンタープライズ所有者はまず、お客様のエンタープライズに対して Dependabot を設定する必要があります。 詳細については、「エンタープライズ向けの Dependabot の有効化」を参照してください。

リポジトリのDependabot alertsタブの開いた・閉じたすべてのDependabot alertsおよび対応するDependabot security updatesを表示できます。詳細については、「Dependabot アラートの表示と更新」を参照してください。

新しいワークフローまたは更新されたワークフローの脆弱性のスクリーニング アクション

Pull request を開いてワークフローを更新するとき、使用するアクションに加えた変更のセキュリティ上の影響を理解するため、依存関係レビューの使用をお勧めします。 依存関係レビューを使うと、すべてのPull Reqeustにおける以下の変更による依存関係の変化とセキュリティについての影響を理解しやすくなります。pull request の [Files Changed](変更されたファイル) タブ上のリッチ diff で依存関係の変更をわかりやすく視覚化できます。 依存関係レビューは、以下のことを知らせます:

• リリース日と合わせて、追加、削除、更新された依存関係
• これらのコンポーネントを使うプロジェクトの数
• これらの依存関係に関する脆弱性のデータ

ワークフローに加えた変更に脆弱性のフラグが付けられている場合、プロジェクトに追加することを回避するか、セキュリティで保護されたバージョンに更新することができます。

依存関係レビューの詳細については、「依存関係の確認について」を参照してください。

"依存関係レビュー アクション" とは、GitHub Actions コンテキスト内の pull request の差異を報告できる特定のアクションです。 以下を参照してください。dependency-review-action リポジトリで 依存関係レビュー アクション を使って、pull request に依存関係レビューを適用できます。 このアクションは、pull request のパッケージ バージョンの変更によって発生した依存関係の脆弱なバージョンをスキャンし、関連するセキュリティの脆弱性について警告します。 これにより、pull request で何が変更されているかをより正確に把握でき、リポジトリに脆弱性が追加されるのを防ぐことができます。 詳細については、「依存関係の確認について」を参照してください。

ワークフローのアクションをセキュリティで保護して最新の状態に維持

リポジトリで使用されるアクションおよび再利用可能なワークフローのリファレンスを常に最新の状態に保つため、Dependabotを使用できます。 多くの場合、アクションはバグ修正および新しい機能で更新され、自動化プロセスの速度、安全性、信頼性が向上しています。 Dependabotは、依存関係の保守を自動的に実行するため、作業量が軽減されます。 詳細については、「Dependabot でアクションを最新に保つ」および「Dependabot のセキュリティ アップデート」を参照してください。

次の機能を使用すると、ワークフローのアクションを自動的に更新できます。

•         **Dependabot version updates** 新しいバージョンがリリースされたときに pull request を開いてアクションを最新バージョンに更新します。
  

•         **Dependabot security updates** Pull request を開き、報告された脆弱性があるアクションを最小のパッチ バージョンに更新します。
  

Dependabot version updates を構成する方法の詳細については、「Dependabot バージョンの更新の構成」を参照してください。

Dependabot security updates を構成する方法の詳細については、「Dependabot セキュリティの更新の構成」を参照してください。