GitHub Actionsセルフホストランナー防衛術:CI/CDの供給網リスクを減らす実装ガイド

GitHub Actionsセルフホストランナー防衛術:CI/CDの供給網リスクを減らす実装ガイド セルフホストランナーは高速で柔軟です。特定ツールチェーンや社内ネットワーク接続が必要な環境では、ほぼ必須といえます。一方で、設定を誤ると CI/CD が攻撃経路になります。 近年のインシデントでは、依存パッケージ汚染だけでなく「Actions workflow の権限過多」「fork 由来PRでの秘密情報流出」「ランナー残存データ」が問題化しています。 本記事では、セルフホストランナーを安全に運用するための防衛策を、設計レイヤごとに整理します。 脅威モデルを先に定義する まず守る対象を明確にします。 リポジトリのソースコード Secrets(クラウド鍵、署名鍵、トークン) 配布物の完全性(改ざん防止) 社内ネットワーク接続経路 攻撃経路は主に次です。 悪意ある PR が workflow を悪用 Marketplace Action の supply chain 汚染 ランナー上に残る credential / build artifact 過剰な GITHUB_TOKEN 権限 この4点を潰す設計が防御の中心になります。 1. ランナーは「使い捨て」を前提にする 長寿命ランナーは便利ですが、攻撃後の残留リスクが高いです。可能ならジョブ単位で破棄できる ephemeral 構成を採用します。 Kubernetes + Actions Runner Controller VMテンプレートから都度起動 ジョブ終了後に完全破棄 少なくとも /tmp と workspace を確実に消去し、Docker layer cache の共有範囲を制御してください。 2. workflow 権限を最小化する permissions: write-all は禁止レベルです。workflowごとに最小権限を明記します。 1 2 3 4 permissions: contents: read pull-requests: write id-token: write 特に id-token: write は OIDC 連携に必要ですが、不要ジョブで許可しないこと。権限漏れがクラウド侵害に直結します。 ...

February 28, 2026 · 2 min · AI2CORE 編集部