GitHub Actions防御設計 2026：Allowlist・OIDC・インシデント対応の実務

2026年のCI/CDセキュリティは、「侵害されない設計」ではなく「侵害されても被害を限定できる設計」に移行しています。GitHub側の機能拡張（Action allowlisting、セキュリティアドバイザリ運用強化など）は追い風ですが、実務で効くのは組織標準への落とし込みです。

全リポジトリに適用すべき基準

最低限、次の5点を組織ルールとして固定化します。

• 外部ActionはSHA固定（タグ参照を禁止）
• 実行可能なAction発行元をallowlist化
• クラウド連携はOIDC短命認証へ統一
• jobごとにpermissionsを明示
• セルフホストランナーを信頼境界別に分離

この基準を例外運用にすると、レビュー工数だけ増えて実効性が落ちます。

OIDC移行を安全に進める手順

1. 既存シークレット利用箇所の棚卸し
2. リポジトリ/環境単位で信頼ポリシー設計
3. dev→staging→prodの順で段階移行
4. 検証期間終了後に固定キーを無効化

失敗要因は実装難易度より、命名ルール不統一と責任所在の曖昧さです。移行前に「誰が最終承認するか」を決めておくべきです。

再利用ワークフローでポリシーを強制する

セキュリティ品質は“善意”では揃いません。共通ワークフローで以下を必須化します。

• 依存関係と成果物の真正性チェック
• secret scanningのブロッキング設定
• ブランチ/環境保護の強制
• ビルド成果物の証跡（attestation）付与

バイパスは例外チケット必須にし、監査ログに残します。

侵害時の初動テンプレート

異常なworkflow実行を検知したら、次を即時実施します。

• 対象リポジトリの書き込み凍結
• 組織トークンとクラウド信頼設定の失効
• 漏洩不明でも高リスクシークレットを先行ローテーション
• ランナーログ、workflowメタ情報、lockfile差分の保全
• 24時間以内に時系列サマリを社内共有

この手順は、事故時に初めて作るのではなく四半期ごとに訓練しておくことが重要です。

継続監視すべき指標

• SHA固定率
• OIDC利用率
• 認証失効の中央値時間
• ポリシーバイパス件数
• 標準ワークフローからの逸脱率

これらを可視化すると、セキュリティ議論が抽象論から運用品質の改善に変わります。

まとめ

GitHub Actions防御の要点は、ツール追加よりも「ID・真正性・ポリシーの一貫運用」です。安全な経路をデフォルト化し、危険な経路を高コスト化する設計に変えることで、開発速度を落とさずに防御強度を上げられます。