Dependabot/Code ScanningのOIDC対応で実現するゼロシークレットCI

GitHub Changelogで公開された「Dependabot / code scanningのOIDC対応」は、サプライチェーン防御の運用を変える更新です。組織レベルで設定したプライベートレジストリに対して、長寿命シークレットを置かずに認証できる設計へ寄せられるからです。

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

この変更は設定1つで終わる話ではありません。CIの信頼境界を作り直すきっかけです。

なぜ静的シークレットが残り続けたか

多くの組織で静的シークレットが残った理由は共通しています。

レジストリ側がID/パスワード前提で運用されていた
依存関係更新とセキュリティスキャンが本線のID設計から外れていた
ローテーション責任が曖昧で、期限管理が形骸化した

結果として、リポジトリが消えても資格情報だけが生き残る「secret debt」が積み上がります。

OIDCで変わる信頼モデル

OIDCでは、実行時に短命のIDトークンを発行し、必要最小限のアクセス権と交換します。これにより、次の改善が得られます。

永続資格情報の削減: repo secretsに固定トークンを置かなくてよい。
Claimベースの厳密化: repo/branch/workflow条件で発行可否を制御可能。
監査性の向上: どのジョブIDが何を要求したか追跡しやすい。

推奨アーキテクチャ

実務で安定する構成は以下です。

GitHub Actions側でOIDCトークン発行
IAMまたは認証ブローカーがissuer/claimを検証
ブローカーが短命・最小権限トークンを払い出し
Dependabot/Scanningジョブが一時トークンでレジストリアクセス
監査ログと拒否イベントを集中管理

注意点は、OIDCトークンから直接「広い権限」にマップしないこと。ブローカー層を置くことで、ポリシー改修を全リポジトリ横断で安全に行えます。

Claim設計の要点

OIDC事故の多くは、claim検証が甘いことに起因します。最低限、次を必須化してください。

repository / owner の一致
保護ブランチやタグ条件
workflowファイルパスの固定
実行レーン（dev/stg/prod）との対応
aud の厳密一致

ポリシーは必ずコード化し、履歴を残します。監査で問われるのは「今の設定」だけでなく「いつ誰が何を変えたか」です。

移行ステップ

1. 棚卸し

利用中レジストリと認証経路を列挙
静的シークレット参照ジョブを特定
影響範囲でワークロードを分類

2. 併走運用

OIDC経路を有効化しつつ一時的にフォールバック維持
成功率、拒否率、発行パターンを比較
異常トークン要求の検知ルールを検証

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

org/repoスコープから不要シークレット削除
再利用workflowテンプレートへ集約
PRガバナンスで逸脱をブロック

4. 継続検証

ポリシードリフト定期スキャン
権限外トークン要求の疑似テスト
IAM/ブローカー障害の復旧訓練

SBOM非同期化との組み合わせ

同じ月の更新でSBOM exportが非同期化されました。OIDC化と組み合わせると、セキュリティ処理は次の形が取りやすくなります。

一時認証で必要データのみ取得
SBOM生成を非同期キューで処理
大規模リポジトリでも処理分離しやすい

ポイントは、巨大な単一ジョブに戻らないことです。イベント駆動で責務分離されたセキュリティパイプラインを設計します。

成功指標

導入効果は次の数値で追います。

静的レジストリシークレットゼロのリポジトリ比率
トークン寿命分布とポリシー拒否率
ワークロード別のアクセス拒否イベント
パイプラインID侵害時の封じ込め時間

数値化しないOIDC移行は、運用実態のない「準拠アピール」に終わります。

まとめ

Dependabot/Code ScanningのOIDC対応は、秘密情報依存CIからIDネイティブCIへ移る実装機会です。厳密なclaim検証、最小権限の払い出し、テンプレート化されたworkflow統制をセットで進めることで、開発速度を落とさずサプライチェーンリスクを下げられます。