セルフホストランナーは高速で柔軟です。特定ツールチェーンや社内ネットワーク接続が必要な環境では、ほぼ必須といえます。一方で、設定を誤ると CI/CD が攻撃経路になります。

近年のインシデントでは、依存パッケージ汚染だけでなく「Actions workflow の権限過多」「fork 由来PRでの秘密情報流出」「ランナー残存データ」が問題化しています。

本記事では、セルフホストランナーを安全に運用するための防衛策を、設計レイヤごとに整理します。

脅威モデルを先に定義する

まず守る対象を明確にします。

• リポジトリのソースコード
• Secrets（クラウド鍵、署名鍵、トークン）
• 配布物の完全性（改ざん防止）
• 社内ネットワーク接続経路

攻撃経路は主に次です。

1. 悪意ある PR が workflow を悪用
2. Marketplace Action の supply chain 汚染
3. ランナー上に残る credential / build artifact
4. 過剰な 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 連携に必要ですが、不要ジョブで許可しないこと。権限漏れがクラウド侵害に直結します。

3. fork PR の実行ポリシーを分離する

外部 fork からの PR で secrets を使うジョブを実行しない設計が必須です。

推奨:

• pull_request イベント: テストのみ、secrets 無し
• pull_request_target: 原則禁止、必要なら厳格レビュー
• デプロイ系は push（保護ブランチ）だけ

また、workflow_run を使って「検証済み成果物だけを次段へ渡す」2段構成にすると安全性が上がります。

4. Action の固定と検証

uses: actions/checkout@v4 のようなタグ指定だけでは、将来更新の影響を受けます。高リスク工程では commit SHA 固定を検討します。

1

- uses: actions/checkout@8ade135a... # SHA pin

加えて、許可済み Action の allowlist を組織ポリシー化します。無制限に Marketplace Action を使わせると監査不能になります。

5. Secrets 管理は OIDC 中心へ

長期固定鍵を GitHub Secrets に置く運用は、漏洩時の被害が大きいです。クラウド連携は OIDC フェデレーションに移行し、短命トークンを発行します。

利点:

• 鍵配布不要
• 期限短い
• リポジトリ/ブランチ条件で絞れる

AWS なら role trust policy に sub 条件を入れ、「main ブランチの release workflow だけ許可」といった制御が可能です。

6. ネットワーク分離と出口制御

セルフホストランナーが社内フラットネットワークに直結している構成は危険です。ランナー専用サブネットを作り、次を実施します。

• egress allowlist（必要ドメインのみ）
• 社内DBへの直接接続禁止
• 管理プレーンと実行プレーン分離

「CIだから社内に近いほど便利」は短期的発想です。侵害前提で最小到達範囲に設計します。

7. 監査ログと改ざん検知

必要なログ:

• workflow 実行者
• 使用ランナーID
• 取得したクラウド権限
• 成果物ハッシュ

さらに、リリース成果物に SBOM と署名（cosign / sigstore）を付与し、配布前検証を自動化します。これで supply chain の追跡性が大きく向上します。

8. 実装チェックリスト（そのまま使える）

• セルフホストランナーは ephemeral 運用
• workflow permissions を最小権限化
• fork PR と deploy workflow を分離
• 高リスク Action は SHA pin
• OIDC による短命認証へ移行
• ネットワーク egress 制限
• artifact 署名と SBOM 生成
• 監査ログを90日以上保持

9. 段階導入プラン（4週間）

• Week1: 権限棚卸し、write-all 排除
• Week2: fork PR ポリシー分離、allowlist導入
• Week3: OIDC移行、固定鍵削減
• Week4: ephemeral runner 化、署名/SBOM実装

一気に変えると運用停止リスクがあるため、週単位で区切るのが現実的です。

まとめ

セルフホストランナーは強力ですが、セキュリティ設計を誤ると CI/CD が最も危険な入口になります。ポイントは「最小権限」「使い捨て」「短命認証」「監査可能性」の4つです。

まずは permissions の最小化と fork PR 分離から始めてください。ここを押さえるだけでも、供給網リスクは大幅に下げられます。

実運用での検知ルール例（SIEM連携）

防御策を実装しても、検知が弱いと侵害を見逃します。次のイベントを SIEM 側で高優先度アラート化してください。

• 深夜帯の workflow 権限変更
• 普段使わないランナーラベルでのジョブ実行
• release workflow で未知の Action 呼び出し
• OIDC 経由で想定外クラウドロールを取得

検知時には自動で repository dispatch を使い、該当リポジトリのデプロイを一時停止する仕組みを入れると被害拡大を防げます。

インシデント対応Runbookの最小構成

供給網インシデントは初動が遅れると致命傷になります。Runbook には最低限次を含めます。

1. 影響範囲特定（対象リポジトリ、workflow、artifact）
2. 該当 Secrets/Role の無効化
3. ランナー群の全廃棄と再構築
4. 直近リリース成果物のハッシュ再検証
5. 監査ログ保全と関係者通知

この手順を平時に演習しておくことで、実際の障害時に迷いを減らせます。

組織導入で効くポリシー

• 新規 workflow はセキュリティレビュー必須
• Action 追加時はリスク評価テンプレート提出
• 重要リポジトリは branch protection + required review を強制
• セルフホストランナーの管理責任者を明確化

技術対策だけでは継続しません。責任分界とレビュー手順を運用ルール化することが、防御の持続性を高めます。

まとめ（運用視点）

最終的に重要なのは「侵害されないこと」ではなく「侵害されても被害を限定し、速く復旧できること」です。セルフホストランナーを使うなら、最初からゼロトラスト前提で設計し、検知・対応まで含めた体制を整えてください。

最後に

現場では「便利だから後で固める」が最も危険です。セルフホストランナーは導入初日から最小権限と隔離を前提に設計し、定期監査で逸脱を戻す運用を続けてください。

追加の運用Tip

新しいリポジトリを作るたびに同じ議論をしないため、テンプレートリポジトリへ安全な workflow 雛形を同梱しておくと効果的です。初期状態を安全側に固定するだけで、運用負荷と事故率の両方を下げられます。

継続的な棚卸しを習慣化してください。