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

ワークフローを作成し、 GitHub Actions セキュリティ機能を使用する場合のセキュリティのベストプラクティスに関する情報を確認します。

ワークフローの書き込み

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

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

最小限の特権の原則
- リポジトリへの書き込みアクセス権限を持つすべてのユーザーは、リポジトリに構成されているすべてのシークレットへの読み取りアクセス権を持っています。そのため、ワークフロー内で使われる認証情報が持つ特権は必要最小限のものにする必要があります。
- Actions は、GITHUB_TOKEN コンテキストからアクセスすることで github.token を使用できます。詳しくは、「コンテキストリファレンス」をご覧ください。したがって、GITHUB_TOKEN に最低限必要な権限が付与されていることを確認する必要があります。リポジトリの内容の読み取りアクセスのみを行うように GITHUB_TOKEN の既定のアクセス許可を設定することを、セキュリティの点からお勧めします。その後、必要に応じて、ワークフローファイル内の個々のジョブの権限を増やすことができます。詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。
機密データをマスクする
- 機密データは、ワークフローファイルにプレーンテキストとして格納しないでください。 GitHubを使用して、::add-mask::VALUEシークレットではないすべての機密情報をマスクします。これにより、値がシークレットとして扱われ、ログから編集されます。データのマスキングの詳細については、「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に固有ではありません。

code scanning のワークフローテンプレートを使用する

Code scanning では、運用環境に到達する前にセキュリティの脆弱性を見つけることができます。 GitHub には、 code scanningのワークフローテンプレートが用意されています。これらの推奨ワークフローを使用して、ゼロから始めるのではなく、 code scanning ワークフローを構築できます。 GitHubのワークフローである CodeQL 分析ワークフローは、 CodeQLを利用します。また、サードパーティ製のワークフローテンプレートも利用できます。

詳細については、「コードスキャンについて」および「コードスキャンの詳細設定を構成する」を参照してください。

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

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

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

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

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

信頼されていないコードチェックアウトのリスクに関するその他の例とガイダンスについては、からの GitHub Security Labと OpenSSF スコアカードからの危険なワークフローに関するドキュメントを参照してください。

推奨されるプラクティス

必要がない場合は、pull_request_target ワークフロートリガーを使わないでください。ワークフロー間の特権の分離には、workflow_run の方が適切なトリガーです。ワークフローで実際に特権コンテキストが必要な場合にのみ、これらのワークフロートリガーを使ってください。
信頼されていない pull request またはコードコンテンツで pull_request_target および workflow_run ワークフロートリガーを使うことは避けてください。これらのトリガーを使うワークフローでは、(pull request のフォークや自分の管理下にないリポジトリなどの) 信頼されていないコードを明示的にチェックアウトしてはなりません。 workflow_run 上でトリガーされるワークフローでは、他のワークフローからアップロードされた成果物を慎重に扱う必要があります。
CodeQL は、潜在的に脆弱な GitHub Actions ワークフローをスキャンして検出できます。リポジトリの既定のセットアップを構成し、 GitHub Actions スキャンが有効になっていることを確認できます。詳しくは、「コードスキャンの既定セットアップの構成」をご覧ください。
OpenSSF スコアカードは、潜在的に脆弱なワークフローと、 GitHub Actionsを使用する場合の他のセキュリティリスクを特定するのに役立ちます。この記事で後述する「OpenSSF Scorecards を使ってワークフローの依存関係をセキュリティで保護する」を参照してください。

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

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

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

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

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

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

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

GitHub では、リポジトリ、組織、エンタープライズレベルで、アクションを完全長のコミット SHA に固定することを必須にするポリシーが用意されています。 * リポジトリレベルでポリシーを構成するには、「リポジトリのGitHub Actions設定の管理」を参照してください。 * Organization レベルでポリシーを構成するには、「組織のGitHub Actionsの無効化または制限」を参照してください。 * Enterprise レベルでポリシーを構成するには、「企業でGitHub Actionsのポリシーを適用する」を参照してください。

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

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

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

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

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

GitHubのセキュリティ機能

GitHub には、コードのセキュリティを強化するための多くの機能が用意されています。 GitHubの組み込み機能を使用して、ワークフローが依存するアクションを理解したり、使用するアクションの脆弱性に関する通知を受けたり、ワークフロー内のアクションを最新の状態に保つプロセスを自動化したりできます。アクションを公開して管理する場合は、 GitHub を使用して、脆弱性とその修正方法についてコミュニティと通信できます。 GitHubオファーのセキュリティ機能の詳細については、「GitHubセキュリティ機能」を参照してください。

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

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

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

組織内の GitHub Actions 設定のアクセス許可の管理

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

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

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

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

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

GitHub Actions ワークフローが OpenID Connect (OIDC) をサポートするクラウドプロバイダーのリソースにアクセスする必要がある場合、そのクラウドプロバイダーで直接認証されるようにワークフローを構成できます。これにより、有効期間の長いシークレットとしてこれらの資格情報の格納を停止し、その他のセキュリティ上の利点を提供できます。詳しくは、「OpenID Connect」をご覧ください。

メモ

OIDC のカスタム要求のサポートは、AWS では使用できません。

Dependabot version updatesを使用してアクションを最新の状態に保つ

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

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

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

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

GitHub Actionsがプル要求を作成または承認できないようにする

GitHub Actions ワークフローでの pull request の作成または承認を許可するか禁止するかを選択できます。適切な監視なしでプル要求がマージされた場合、ワークフローまたはその他の自動化によるプル要求の作成または承認を許可することは、セキュリティ上のリスクになる可能性があります。

この設定を構成する方法の詳細については、「企業でGitHub Actionsのポリシーを適用する、組織の GitHub Actions の表示または制限、および AUTOTITLE」を参照してください。

code scanningを使用してワークフローをセキュリティで保護する

Code scanning は、 GitHub Actions ワークフローで使用される一般的な脆弱なパターンの改善を自動的に検出して提案できます。

code scanningを有効にする方法の詳細については、コードスキャンの既定セットアップの構成を参照してください。

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

Scorecards は、リスクの高いサプライチェーンプラクティスにフラグを設定する自動セキュリティツールです。 Scorecards アクションとワークフローテンプレートを使って、セキュリティのベストプラクティスに従うことができます。構成が完了すると、Scorecards アクションはリポジトリの変更に対して自動的に実行され、組み込みの code scanning エクスペリエンスを使用してリスクの高いサプライチェーンプラクティスについて開発者に警告します。 Scorecards プロジェクトでは、スクリプトインジェクション攻撃、トークンのアクセス許可、ピン留めされたアクションなど、さまざまなチェックが実行されます。

GitHub でホストされるランナーのセキュリティ強化

GitHubホステッドランナーは、セキュリティリスクを軽減できるようにするための対策を講じています。

GitHubホストランナーのサプライチェーンのレビュー

GitHubによって管理されるイメージから作成されたGitHubホストランナーの場合、ソフトウェア部品表 (SBOM) を表示して、ランナーにプレインストールされたソフトウェアを確認できます。脆弱性スキャナーを介して実行できる SBOM をユーザーに提供して、製品に脆弱性があるかどうかを検証できます。あなたが成果物をビルドする際には、このSBOMを部品表に含めることができれば、ソフトウェアの作成過程に必要なすべてを網羅した包括的なリストになります。

SBOM は、GitHub によって維持されている Ubuntu、Windows、macOS のランナーイメージ（ARM ベースのランナーを含む）で利用できます。ビルドの SBOM は、 https://github.com/actions/runner-images/releases に記載されているリリース資産で見つけることができます。 sbom.IMAGE-NAME.json.zip の形式のファイル名を持つ SBOM は、各リリースの添付ファイルにあります。

ホストへのアクセスを拒否する

GitHub ホストランナーは、さまざまな暗号化マイニングプールや悪意のあるサイトへのネットワークアクセスをブロックする etc/hosts ファイルでプロビジョニングされます。 MiningMadness.com や cpu-pool.com などのホストは、重大なセキュリティリスクが存在しないように localhost に再ルーティングされます。詳細については、 AUTOTITLE を参照してください。

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

** GitHubホストランナー** は、一時的でクリーンな分離された仮想マシン内でコードを実行します。つまり、この環境を永続的に侵害したり、ブートストラッププロセス中にこの環境に配置された情報よりも多くの情報にアクセスしたりする方法はありません。

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

その結果、どのユーザーでもリポジトリに対してプルリクエストを開き、環境を危険にさらす可能性があるため、セルフホステッドランナーは GitHub 上のパブリックリポジトリではほとんど使用しないでください。同様に、注意が必要です。というのも、リポジトリをフォークしてプルリクエストを作成できる人はだれでも（通常はそのリポジトリへの読み取りアクセス権を持つ人）、シークレットやGITHUB_TOKENへのアクセスを取得することを含め、セルフホステッドランナー環境を侵害できてしまうためです。これらは、その設定によっては、リポジトリへの書き込みアクセスを許可する可能性があります。ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

Enterprise の所有者と Organization の所有者は、リポジトリレベルのセルフホステッドランナーの作成を許可するリポジトリを選択できます。 "Manage organization runners and runner groups" アクセス許可を持つユーザーは、organization 内のリポジトリのリポジトリレベルの自己ホストランナーの作成を許可するリポジトリのみを選択できます。

カスタム organization の役割の詳細については、「カスタム組織ロールの権限」を参照してください。

詳細については、「企業でGitHub Actionsのポリシーを適用する」と「組織のGitHub Actionsの無効化または制限」を参照してください。

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

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

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

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

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

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

メモ

ハードウェアを再利用して JIT ランナーをホストすると、環境から情報が公開されるリスクがあります。自動化を利用して、JIT ランナーが確実にクリーンな環境を使用するようにしてください。詳しくは、「セルフホステッドランナーリファレンス」をご覧ください。

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

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

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

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

一元管理:

一元化されたチームでセルフホステッドランナーを所有する場合は、最も高い相互 Organization または Enterprise レベルにランナーを追加することをお勧めします。これにより、チームは 1 つの場所でランナーを表示および管理できます。
Organization が 1 つだけの場合、Organization レベルでランナーを追加するのは実質的に同じ方法ですが、将来別の Organization を追加したときに問題が発生する可能性があります。

分散管理:

各チームが自分のセルフホステッドランナーを管理する場合は、チームの所有権の最上位レベルでランナーを追加することをお勧めします。たとえば、各チームが自分の Organization を所有している場合は、ランナーも Organization レベルで追加すると最も簡単になります。
リポジトリレベルでランナーを追加することもできますが、リポジトリ間ではランナーを共有できないため、管理オーバーヘッドが増加し、必要なランナーの数も増えます。

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

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

GitHub Actionsイベントの監査

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

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

組織の監査ログからの "action:org.update_actions_secret" の検索を示すスクリーンショット。 2 つの結果が表示されます。

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

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

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

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

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

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

依存関係グラフはパブリックリポジトリに対して有効になっており、プライベートリポジトリで有効にすることもできます。依存関係グラフの使用の詳細については、「リポジトリの依存関係を調べる.

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

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

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

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

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

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

メモ

Dependabot は、セマンティックバージョン管理を使用する脆弱なアクションに対するアラートのみを作成し、SHA 値にピン留めされたアクションのアラートを作成しません。

個人アカウント、リポジトリ、または組織の Dependabot alerts を有効にすることができます。詳細については、「Dependabot アラートの構成.

リポジトリの [Dependabot alerts] タブで、開いているDependabot security updatesと閉じているすべてのDependabotを表示できます。詳細については、 AUTOTITLE を参照してください。

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

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

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

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

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

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

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

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

Dependabot version updates 新しいバージョンがリリースされたときにアクションを最新バージョンに更新する pull requests を開きます。
Dependabot security updates プル要求を開いて、報告された脆弱性を持つアクションを修正プログラムが適用された最小バージョンに更新します。

メモ

Dependabot では、GitHub Actions リポジトリ構文 (GitHub や actions/checkout@<commit> など) を使用した actions/checkout@v6 の更新のみがサポートされます。 Dependabot は、ローカルで参照されているアクションまたは再利用可能なワークフロー (たとえば、./.github/actions/foo.yml) を無視します。
Dependabot は、コメントが同じ行 ( actions/checkout@<commit> #<tag or link> や actions/checkout@<tag> #<tag or link>など) にある場合に、GitHub Actions のバージョンドキュメントを更新します。
使用するコミットがどのタグにも関連付けられていない場合、Dependabot は GitHub Actions を最新のコミットに更新します（これが最新のリリースとは異なる場合があります）。
Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。たとえば、docker:// 構文を使用した Docker コンテナーアクションへの参照はサポートされていません。
Dependabot では、GitHub Actions のパブリックリポジトリとプライベートリポジトリの両方がサポートされます。プライベートレジストリ構成オプションについては、「git」の「」を参照してください。

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

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

作成したアクションの保護

GitHub は、セキュリティで保護されたコーディングを促進するために、アクションと脆弱性レポーターを公開および維持するユーザー間のコラボレーションを可能にします。リポジトリセキュリティアドバイザリを使用すると、パブリックリポジトリのメンテナーは、プロジェクト内のセキュリティの脆弱性について非公開で話し合い、修正することができます。共同で修正を行った後、リポジトリ保守担当者はセキュリティアドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。セキュリティアドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。

他のプロジェクトで使用されるアクションを保持しているユーザーの場合は、次の GitHub 機能を使用して、公開したアクションのセキュリティを強化できます。

依存関係グラフの依存ビューを使用し、どのプロジェクトがコードに依存するか確認します。脆弱性レポートを受信した場合、脆弱性とその修正方法について誰に連絡する必要があるかについて検討ができます。詳しくは、「リポジトリの依存関係を調べる」をご覧ください。
リポジトリのセキュリティアドバイザリを使用してセキュリティアドバイザリを作成し、プライベートで共同作業をして一時的な個人用フォークの脆弱性を修正し、セキュリティアドバイザリを公開してパッチがリリースされた後にコミュニティに対して脆弱性を警告します。詳細については、「リポジトリのプライベート脆弱性レポートの構成」および「リポジトリセキュリティアドバイザリの作成」を参照してください。

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

この記事で