GitHubは2026年9月17日、パブリックプレビューとして提供していたGitHub Actionsの「ワークフロー実行保護」を一般提供しました。GitHub Enterprise、Organization、リポジトリで利用でき、ワークフローを起動できる主体や、実行の起点となるイベントを許可リストで制御できます。
- GitHub Actionsのワークフロー実行保護が一般提供に移行
- ワークフローを起動できる主体と実行開始イベントを許可リストで制御
- 特定のワークフローファイルを対象に異なるポリシーを設定可能
- Insightsによる影響確認とREST APIによるルール管理に対応
- 対象となるパブリックリポジトリにはpullrequesttargetを無効化するデフォルトルールを導入
GitHub Actionsのワークフロー実行保護が一般提供
GitHub Actionsのワークフロー実行保護が、パブリックプレビューを経て一般提供されました。対象はGitHub Enterprise、Organization、リポジトリです。
実行保護では、Actionsワークフローを誰が起動できるか、どのイベントを起点として開始できるかを許可リストで制御します。
- Actorルール：ワークフローを起動できる主体を制御
- Eventルール：ワークフローを開始できるイベントを制御
Actionsは、ワークフローを実行する前にActorルールとEventルールの両方を評価します。
そもそもワークフローとは
今回の発表では、GitHub Actionsのワークフローは、ActorルールとEventルールによって起動条件を制御する対象として扱われています。また、一般提供では、実行保護ルールの対象をリポジトリ全体ではなく、deploy.ymlなどの特定のワークフローファイルに限定できるようになりました。
発表では、同じリポジトリにあるデプロイ用とCI用のワークフローへ異なるポリシーを適用する例が示されています。これにより、リポジトリ全体を一律に制限するのではなく、ワークフローファイルごとに実行ポリシーを変えられます。
実行保護でできることの具体例
1. デプロイ用ワークフローを指定チームに限定する
deploy.ymlを対象に実行保護ルールを設定し、そのワークフローを起動できる主体を指定チームに限定できます。
リポジトリ全体を制限するのではなく、デプロイ用のワークフローファイルに対象を絞れる点が特徴です。
2. CIワークフローはすべてのコントリビューターに開放する
同じリポジトリ内でも、CIワークフローはすべてのコントリビューターが起動できる状態にできます。
たとえば、deploy.ymlは指定チームだけに制限しながら、CIワークフローはすべてのコントリビューターに開放するなど、ワークフローごとに異なるポリシーを設定できます。
3. pullrequesttargetをブロックし、特定のワークフローだけを許可する
Eventポリシーによって、pullrequesttargetイベントによる実行をブロックできます。ワークフローが引き続きこのイベントに依存する場合は、適用可能なActions Eventポリシーでpullrequesttargetを明示的に許可できます。
さらに、ワークフローファイル単位の設定を利用すれば、特定のワークフローを許可リストに追加できます。
一般提供で追加された3つの機能
一般提供に伴い、パブリックプレビューで利用できたActorルールとEventルールに加え、3つの機能が追加されました。
ワークフローファイル単位のルール設定
実行保護ルールの対象を、リポジトリ全体ではなく特定のワークフローファイルに限定できます。これにより、1つのリポジトリ内でもワークフローごとに異なるポリシーを適用できます。
発表では、deploy.ymlの実行を指定チームだけに制限しながら、CIワークフローはすべてのコントリビューターに開放する例が示されています。
Insightsによる評価・適用状況の確認
Insightsでは、Enterprise、Organization、リポジトリで、Actionsがルールをどのように評価し、適用しているかを確認できます。
ポリシーの影響を監査し、ルールを適用する前と適用した後の両方で設定を調整できます。
REST APIによるプログラム管理
REST APIを使い、Enterprise、Organization、リポジトリの各レベルで実行保護を管理できます。ワークフローパスの条件を含むルールの作成、読み取り、更新、削除に対応します。
これにより、Actionsのポリシーをコードとして管理し、多数のリポジトリでルールの一貫性を保てます。設定画面を個別に操作する代わりに、既存のガバナンス用ツールへ適用処理を組み込むことも可能です。
Evaluateモードも継続
パブリックプレビューで提供されていたEvaluateモードも引き続き利用できます。
Evaluateモードでは、ルールを実際に適用する前にシャドーモードで動作させ、どのワークフロー実行がブロック対象になるかを確認できます。
pullrequesttargetに新しいデフォルト保護
GitHubは新しい安全なデフォルトとして、pullrequesttargetイベントの実行を制限する保護ルールを導入します。
pullrequesttargetワークフローに関する脆弱性は、Actionsワークフローで最も一般的に悪用される脆弱性の一つです。pullrequesttargetはベースリポジトリのコンテキストでシークレットへアクセスするため、フォーク由来のコードが実行されると、信頼できないコードによってパイプラインが汚染され、シークレットが持ち出される可能性があります。
適用可能なEventポリシーがないパブリックリポジトリには、pullrequesttargetを無効化するデフォルトルールが導入されます。このデフォルトは、プライベートリポジトリと内部リポジトリには適用されません。
まとめ
GitHub Actionsのワークフロー実行保護の一般提供により、ワークフローを起動できる主体と実行開始イベントに加え、特定のワークフローファイルを対象とした制御が可能になりました。Insightsによる影響確認や、REST APIによる管理にも対応しています。
具体的には、デプロイ用ワークフローを指定チームに限定しながらCIワークフローをすべてのコントリビューターに開放したり、pullrequesttargetをブロックしつつ特定のワークフローを許可したりできます。
適用可能なEventポリシーがないパブリックリポジトリでは、pullrequesttargetを無効化するデフォルトルールが導入されます。対象となる場合はInsightsで影響を確認し、ブロックを維持するか、必要に応じてpullrequesttargetを明示的に許可するかを選択できます。
