実行保護をワークフローファイル単位で指定でき、REST API でも操作可能に。public 向け既定ルールは evaluate で導入され、GA 前から既定 policy を使う対象だけ11月2日に強制へ移る。
2026年11月2日 GA 前から既定 policy を使う対象で強制が始まる日 GA 前から既定の pull_request_target ポリシーだった対象リポジトリで、既定ルールが自動的に強制へ切り替わる日付として changelog に記載
GitHub Actions の実行保護（workflow execution protections）が public preview から GA になった。GitHub Enterprise、organization、リポジトリのいずれの階層でも設定できる。
期限がついているのは public リポジトリを抱える組織だけだ。適用される event policy をまだ持たない public リポジトリには、pull_request_target を無効化する既定ルールが導入される。そして GA 前から既定の pull_request_target ポリシーだった対象リポジトリでは、2026年11月2日に自動で強制へ切り替わる。
実行保護は allowlist として書く。誰がワークフローを起動できるかを actor rules で、どのイベントが起動できるかを event rules で定義し、実行の前に両方が評価される。二つは独立した軸で、片方だけを絞る書き方もできる。
この二軸自体は public preview から変わっていない。GA で加わったのは、適用の粒度と、評価結果の可視化と、設定の操作手段である。
workflow file targeting は、ルールの適用先をリポジトリ全体ではなく個々のワークフローファイルに絞る。changelog が挙げる例は、deploy.yml を指定したチームだけに制限し、CI のワークフローは全コントリビューターに開けたままにする構成だ。同じリポジトリの中で、ワークフローごとに違うポリシーを持てる。
デプロイ権限を分けるためにリポジトリそのものを割っていたチームには、ここが実務上の変化になる。
Insights は、ルールが enterprise・organization・リポジトリでどう評価され、どう強制されているかを見せる。changelog はこれを、ポリシーの影響を監査し、強制の前と後の両方でルールを調整するためのものと書いている。事後の確認だけでなく、強制前のドライランの読み先でもある。
そのドライランを作るのが evaluate モードで、preview から引き継がれた。ルールを shadow mode で走らせると、強制したらどの workflow run が遮断されるかが先に分かる。
REST API は enterprise・organization・リポジトリの各階層で実行保護を扱う。ルールの作成・取得・更新・削除に加えて、workflow path の条件も API から操作できる。設定画面を数百リポジトリ分クリックする代わりに、Actions のポリシーをコードとして持ち、既存のガバナンス基盤に繋げられる。ただしエンドポイントの具体的なパスは changelog に載っておらず、Actions policies REST API reference に送られている。
pull_request_target は base リポジトリの文脈で、secret にアクセスできる状態で動く。fork のコードがそこで実行されれば、信頼できないコードがパイプラインを汚染し、secret を持ち出しうる。changelog はこの Pwn Requests を、Actions のワークフローで最も多く悪用される脆弱性の一つだとしている。
| 条件 | 既定ルールの扱い |
|---|---|
| 適用される event policy を持たない public リポジトリ | pull_request_target を無効化する既定ルールを導入。当初は evaluate モードで動く |
| private・internal リポジトリ | 適用されない |
| GA 前から既定の pull_request_target ポリシーだった対象リポジトリ | 2026年11月2日に自動で強制へ |
出典：GitHub Changelog「Workflow execution protections in GitHub Actions generally available」（2026年9月17日公開）
強制が始まったあとの選択肢は二つだと changelog は書いている。ルールをそのまま残して pull_request_target を遮断するか、まだこのトリガーに依存しているなら、適用される Actions の event policy で pull_request_target を明示的に許可するか。後者を選ぶときも全面的に開ける必要はない。workflow file targeting で、必要なワークフローだけを allowlist に載せられる。
private と internal のリポジトリがこの既定から外れることは明記されている。将来そこへ広げるかどうかは書かれていない。
GA 前から既定の pull_request_target policy を使っていた対象リポジトリでは、まず Insights で evaluate 中の既定ルールの結果を開き、強制後に失敗する workflow run を見る。そこに pull_request_target を使うワークフローが出てこなければ、11月2日は何も起きない日になる。出てきたなら、そのワークフローを event policy で許可するか、遮断されたままにするかを決めるだけの時間が残っている。
自前のルールを書く側も入り口は同じだ。actor rules と event rules をいきなり強制せず、evaluate で走らせて Insights を読む。GA で増えた3つのうち、最初に効くのは制御の粒度ではなく、制御をかける前に影響を数えられることのほうだと言える。
