3つの更新の内訳
9月初旬のGitHub Actionsアップデートは、いずれも「ワークフローに何を許すか」をより細かく制御できるようにするものだ。
vulnerability-alerts権限:GITHUB_TOKENのpermissionsブロックに新設されたスコープ。readとnoneを取り、readにするとそのジョブからDependabotアラートを参照できる。- ランナー廃止情報のREST API:
GET /actions/runners/deprecations/{version}が、指定したランナーバージョンのruntime_deprecates_at(実行サポート終了日)とregistration_deprecates_at(新規登録受付終了日)を返す。リポジトリ・組織・エンタープライズの各レベルで呼べる。 - 再利用ワークフローの出所プロパティ:
job.workflow_ref、job.workflow_sha、job.workflow_repository、job.workflow_file_pathの4つがjobコンテキストに追加。実行中のジョブが直接定義されたものか、どこかの再利用ワークフロー由来かを実行時に判別できる。
なぜ専用スコープをわざわざ切るのか
これまでDependabotアラートをワークフローから読むには、security-eventsのようなより広い権限を付けるか、PAT(個人アクセストークン)を秘密情報として渡す必要があった。どちらも「アラートを読みたいだけ」という目的に対して過剰で、そのトークンが漏れたり悪用されたりしたときの被害範囲が本来必要な範囲を超える。
GitHubは2023年に新規リポジトリのGITHUB_TOKENを既定で読み取り専用にし、その後もpull_request_targetまわりの権限設計を繰り返し引き締めてきた。2025年にはtj-actions/changed-filesが改ざんされ、多数のリポジトリでシークレットがログに露出する供給網攻撃も起きている。こうした流れの中で、「用途ごとに最小のスコープを用意し、広い権限に頼らせない」という方向は一貫している。今回のvulnerability-alertsはその粒度をもう一段細かくした更新にあたる。
実務的には、依存関係の脆弱性を集計してSlackに通知する、アラート件数をしきい値にしてデプロイを止める、といった自社ワークフローを持っているチームが、付与済みの広い権限やPATを外してvulnerability-alerts: readだけに置き換えられる。監査時に「なぜこのジョブにsecurity-eventsがあるのか」を説明する手間も減る。
ランナー廃止APIは「予告なきCI停止」を避けるための備え
セルフホストランナーやコンテナ内で固定バージョンのランナーを使っていると、サポート終了に気づかず、ある日ジョブが登録できなくなって初めて事態を知ることがある。新しいAPIを定期ジョブから叩いて終了日を監視しておけば、アップグレード計画を前倒しで立てられる。地味だが、CIが動かなくなってからの対応はリリースを直接止めるため、価値のある可視化だ。
再利用ワークフローの出所特定が効く場面
job.workflow_refなどのプロパティは、OIDCで外部サービスに対して「この実行は信頼できる特定のワークフロー定義から来た」と証明したい場合や、共通ワークフローの利用状況を棚卸ししたい場合に使える。組織で共有ワークフローを配って回っているものの、どのリポジトリが古いバージョンを参照し続けているかを把握しきれていない、というときの調査材料になる。
3件とも詳細はGitHub Changelog(https://github.blog/changelog/2026-09-03-github-actions-early-september-2026-updates/)に記載がある。GitHub Enterprise Serverでは再利用ワークフロー関連のプロパティが未提供とされているため、オンプレ運用のチームは自環境での可否を先に確認しておきたい。