GitHub Actionsの組織OIDC移行実践: Dependabot/Code Scanningを止めずに強化する

GitHubでDependabotとCode Scanningに対する組織レベルOIDCが使えるようになったことで、CI基盤の弱点だった「リポジトリごとの長期シークレット管理」をまとめて解消しやすくなりました。機能だけ見ると小さな更新に見えますが、運用面では大きな転換点です。

本稿では、導入時に実際に詰まりやすい論点, 失敗しない移行順序, 組織に説明できる効果測定までを実務視点で整理します。

何が変わるのか

これまで多くの組織では次の課題が残っていました。

• Dependabotが私設レジストリへ接続するために静的資格情報を保持
• Code Scanningジョブごとに認証設計がばらつく
• ローテーションが属人的な手順書運用になる

組織OIDCで重要なのは、「認証を短命化する」だけでなく「認証ルールを中央集約できる」点です。

推奨アーキテクチャ

1. Identity層: GitHub OIDCとクラウドIdPの信頼関係
2. Access層: レジストリ権限を用途単位で分離
3. Governance層: ポリシー監査と例外期限管理

この3層を分けると、セキュリティ強化と開発速度維持を両立しやすくなります。

クレーム設計の要点

組織名だけで広い権限を与える設計は避けます。最低限、次の文脈を含めます。

• リポジトリまたは許可パターン
• ジョブ種別（dependency-update / code-scan）
• 実行環境（prod / non-prod）
• セッション有効期限

これにより、更新ジョブに必要な読み取り権限だけを短時間付与し、権限の横展開を防げます。

止めない移行手順

1週目: 棚卸し

• 私設レジストリ利用リポジトリの一覧化
• 既存シークレット依存の見える化
• 互換性リスクの高いケース抽出

2週目: 併用期間

• パイロットでOIDC認証を有効化
• 一時的に旧方式をフォールバックとして残す
• 失敗理由を分類して計測

3〜4週目: レーン強制

• 重要系はOIDCのみ
• 一般系は期限付きフォールバック
• 検証系は任意だがテレメトリ必須

監査と現場を両立するコントロール

• 新規設定で長期資格情報を検知したらブロック
• 再利用可能なワークフローテンプレートを提供
• クレーム不一致時のエラーを人が読める形で返す
• 例外チケットの期限超過をダッシュボード化

「守るために遅くなる」を減らすには、開発者の初回成功率を上げる設計が必須です。

効果測定

活動量ではなく結果で評価します。

• 静的資格情報の件数推移
• 依存更新ジョブ成功率
• 認証障害の復旧中央値
• 30日超の例外件数
• ポリシー拒否理由の内訳

セキュリティ指標と開発指標が同時に改善しているかを確認します。

60日運用プラン

• Day 1-15: 棚卸し, テンプレート整備, パイロット開始
• Day 16-35: レーン移行, 中央監視運用開始
• Day 36-60: 重要系完全移行, 旧シークレット廃止

まとめ

組織OIDCは単なる設定変更ではなく、CIの認証統制を設計し直す機会です。レーン設計と計測を先に決めて進めることで、スピードと安全性を同時に底上げできます。