GitHub OIDC対応でCI秘密情報を削減する, Dependabot/Code Scanningの安全運用移行ガイド

GitHub Changelogの2026年4月更新で、DependabotとCode Scanningが組織レベルのプライベートレジストリに対してOIDC認証を使えるようになりました。これは単なる新機能ではなく、CIに残り続けてきた「長期シークレット依存」を減らす転換点です。

参考: https://github.blog/changelog/month/04-2026/

なぜ長期シークレットは事故を生むのか

多くの漏えい事故は暗号方式の破綻ではなく、運用の破綻です。

リポジトリ間で資格情報が使い回される
ローテーションが後回しになる
ログや成果物に混入しやすい
侵害時に「どのジョブが使ったか」を追いにくい

OIDCは万能ではありませんが、短命トークンとクレーム制御により、リスク面積を確実に縮小できます。

目指すべき状態

「必要な時だけ、必要なジョブにだけ」権限を与える構成です。認可条件は最低でも次を含めます。

組織 / リポジトリ情報
ブランチやref条件
ワークフロー種別（Dependabot更新、スキャン実行など）
実行イベント種別

これらをIdP側ロールにマッピングし、最小権限を徹底します。

実務向け移行ステップ

1. 棚卸し

どのレジストリにアクセスしているか一覧化
静的シークレット利用中のリポジトリ抽出
重要度と影響範囲で優先順位付け

2. 信頼ポリシー定義

org/repoの許可範囲
高権限操作時のref制約
本番系は保護ブランチ必須

3. 併走検証

OIDCと旧認証を短期間並行
成功率、認証遅延、拒否理由を比較
偽陽性（必要ジョブが拒否）を潰す

4. 静的シークレット廃止

リポジトリ秘密情報を段階削除
静的資格情報の使用をCIで禁止
監査ルールで再流入を検出

運用で効く監視指標

OIDCトークン発行成功率
レジストリアクセスp95
クレーム不一致の拒否件数
ブレークグラス利用回数

特に拒否理由を構造化して残すと、調整が圧倒的に速くなります。

ポリシー設計例

Dependabotは依存取得のみ許可（公開は禁止）
Code Scanningは解析依存取得のみ
リリース公開は保護ref + 署名コミット条件
プレビュー環境は低権限ロールを分離

インシデント対応の改善点

OIDCに切り替えると、調査単位が「共有シークレット」から「特定ジョブの信頼関係」に変わります。

どのワークフローが発行要求したか追跡可能
どのコミット・実行者と紐づくか明確
必要箇所のみ無効化でき、全体ローテーションを避けやすい

結果として復旧時間と誤影響を抑えられます。

失敗しやすい設計

便利さ優先でワイルドカード許可を多用
全リポジトリで同一ロールを使う
旧シークレットを無期限で残す
拒否理由の監視を実装しない

まとめ

Dependabot/Code ScanningのOIDC対応は、サプライチェーン防御を現実的に強化できる機会です。クレーム厳格化、短命権限、運用監視をセットで実装すれば、開発速度を落とさずにCIの攻撃面を大きく削減できます。