GitHub Actionsの2026年セキュリティロードマップ
2025年から2026年にかけて、tj-actions/changed-files、Nx、trivy-actionといった広く使われるActionを標的にしたサプライチェーン攻撃が相次いだ。いずれも「信頼済みActionを乗っ取ってCIパイプライン上で任意コードを実行し、シークレットを抜く」という共通パターンだった。GitHubはその反省を踏まえ、2026年のGitHub Actionsセキュリティロードマップを公開した。
攻撃が成立する根本原因として、GitHubは3点を挙げている。脆弱性を悪用して信頼済みワークフロー内で悪意あるコードが走る、実行内容が可視化されていない、そして過剰な権限を持つクレデンシャルが広範に流れる。解決の方針は「暗黙の動作を減らし、ワークフロー単位の設定を減らし、中央集権的で強制可能なポリシーを増やす」こと。
ワークフロー依存関係のロック
現状のGitHub Actionsには、依存関係のロック機構がない。uses: actions/checkout@v4 と書いてもコンポジットActionがさらに別のActionを呼ぶとき、その推移的依存まで固定する手段がなく、タグの差し替えで内容が変わってもCIは気づかない。
導入が計画されているのは、ワークフローYAMLに dependencies: セクションを追加する機能だ。GoのGo.sumやRustのCargo.lockに相当する仕組みで、以下を実現する。
- ハッシュ固定による決定論的実行（内容が変わればハッシュ不一致で即検出）
- PRのdiffで依存関係変更を可視化
- コンポジットAction内の推移的依存の完全追跡
- 審査済みコードだけが動く保証
タイムラインはパブリックプレビューが3〜6ヶ月以内、GAはその後さらに6ヶ月。長期的には不変リリース（Immutable releases）と厳格な公開要件を組み合わせ、悪意あるコードを一元的に検出・ブロックする強制ポイントを構築する計画もある。
攻撃面の削減
スコープ付きシークレット
現状の問題は、シークレットがとくにreusable workflowsでデフォルトとして広範に流れる設計にある。特定のリポジトリやブランチに関係のないシークレットがパイプライン全体に到達してしまう。
スコープ付きシークレットでは、シークレットを以下の単位に限定バインドできるようになる。
| スコープ | 説明 |
|---|---|
| リポジトリ | 指定リポジトリのワークフローにのみ公開 |
| ブランチ | 特定ブランチのワークフローに限定 |
| 環境 | productionなど指定環境のジョブにのみ渡す |
| 信頼済みワークフロー | 明示的に許可したreusable workflowのみ |
これによりコードコントリビューションとクレデンシャル管理が分離され、外部コントリビューターのfork PRでシークレットが意図せず使われるリスクが下がる。
ポリシー駆動実行
「誰がどのイベントでワークフローをトリガーできるか」の設定が現状はワークフローごとに分散しており、監査が難しく誤設定が起きやすい。
GitHubの既存ルールセットフレームワークを拡張して、組織レベルの中央ポリシーとしてワークフロー実行を制御できるようになる。
| ルール | 内容 |
|---|---|
| アクタールール（トリガー実行者） | 外部コントリビューター・ボット・Dependabotなど、誰がワークフローをトリガーできるかを組織全体で定義 |
| イベントルール | push、pull_request、workflow_dispatchなど許可するイベントを中央で制限 |
個別のワークフローファイルに散在していた if: github.actor != 'dependabot[bot]' のような条件ロジックが、組織ポリシーとして一元管理できる。
エンドポイント監視とコントロール
Actionsデータストリーム
CI/CDパイプラインの実行内容が今まで「ブラックボックス」だった問題への対応として、ほぼリアルタイムの実行テレメトリ（実行ログやメトリクス）を外部に配信する仕組みが追加される。
配信先として対応するのはAmazon S3とAzure Event Hub / Data Explorer。観測できるデータは以下のとおり。
- ワークフロー実行詳細（ステータス、所要時間、使用ランナー）
- 依存関係解決パターン（どのActionがどのバージョンで解決されたか）
- 将来的にはネットワークアクティビティも対象
SIEM（セキュリティ情報イベント管理）やSOC（セキュリティオペレーションセンター）からCI/CDの状況をリアルタイムで観測できるようになる。パブリックプレビューは3〜6ヶ月以内、GAは6〜9ヶ月。
ネイティブEgress（外向き通信）ファイアウォール
最も大きな変化はLayer 7のEgressファイアウォールだ。GitHubホストランナーのVM外で動作するため、ランナー内のコードでは回避できない設計になっている。
2つのモードを用意している。
| モード | 動作 |
|---|---|
| モニタリング | 全アウトバウンドトラフィックをログに記録し、トラフィックパターンの把握と許可リスト形成に使う |
| エンフォースメント | 許可リスト外の宛先へのリクエストをブロック |
段階的な移行を前提にした設計で、いきなりポリシーを強制してCIが壊れる事態を避けている。パブリックプレビューは6〜9ヶ月以内を予定。
機能タイムライン一覧
| 機能 | パブリックプレビュー | GA |
|---|---|---|
| ワークフロー依存関係ロック | 3〜6ヶ月 | +6ヶ月 |
| スコープ付きシークレット | 3〜6ヶ月 | +6ヶ月 |
| シークレット権限変更 | 3〜6ヶ月 | 未定 |
| Actionsデータストリーム | 3〜6ヶ月 | +6〜9ヶ月 |
| Egressファイアウォール | 6〜9ヶ月 | 未定 |
tj-actionsインシデント以降、「GitHubはサプライチェーン攻撃に対してどう応えるのか」という声が大きかったが、今回のロードマップはその直接的な回答になっている。とくに依存関係ロックとEgressファイアウォールはCI/CDセキュリティの根本的な穴を埋める機能で、パブリックプレビューが出たら早めに検証しておきたい。