#security#ci/cd#devops#automation#enterprise
GitHub Credential Revocation API拡張時代の実装指針: Bot運用での漏えい対応を“即時失効”中心に再設計する
GitHubのCredential Revocation APIが、GitHub OAuthおよびGitHub App資格情報までカバーするようになったことで、資格情報漏えい時の初動は「人手で判断してから止める」から「即時失効してから調べる」へ移行しやすくなりました。
参考: https://github.blog/changelog/
なぜ“調査先行”ではなく“失効先行”なのか
Bot主体のデリバリー環境では、調査を先にすると攻撃者の滞在時間を伸ばしやすくなります。安全側の基本順序は次です。
- 異常検知
- 即時失効
- 最小権限の代替経路で復旧
- 根本原因分析
この順序なら、被害拡大を先に止めたうえで、調査品質を落とさずに進められます。
手順書ではなくイベント駆動パイプラインとして設計する
実務では、失効対応をrunbook文章のままにせず、自動化パイプラインへ落とし込むべきです。
- Secret ScanningやSIEMのアラートをインシデントイベント化
- シークレット種別（OAuth/App/PAT）を判別
- Revocation APIを監査証跡付きで実行
- 影響ワークフローを一時停止または代替認証へ切替
- ChatOps/Ticketへ構造化ログを通知
これにより、担当者依存の初動差を小さくできます。
GitHub App中心組織で必須になる3つの準備
- インストールスコープ台帳: どの資格情報がどのrepoに到達可能かを常時把握
- 依存グラフ: 失効時に止まるworkflowとサービス影響を可視化
- 事前承認済みフォールバック: 緊急時の暫定鍵・手動承認経路を準備
失効そのものは速くても、この準備がなければ復旧が長引きます。
監査と事後分析のための証跡モデル
各失効イベントで最低限残すべき項目:
- 検知時刻 / 失効完了時刻
- 資格情報タイプと発行元
- 影響repo・workflow
- 復旧完了時刻
- 復旧中に適用した例外承認
この粒度で証跡を持つと、SOC2/ISO対応やポストモーテム作成の速度が上がります。
SLOで運用品質を固定化する
- MTTRev（失効まで平均時間）: 高リスクは5分以内
- MTTRec（復旧まで平均時間）: Tier1は60分以内
- 証跡完全性: 全インシデントで構造化ログ100%
“速く止める”と“業務を戻す”を同時に評価するのが重要です。
30日導入プラン
- 1週目: Bot/CIで使う資格情報を棚卸しし、repo重要度でリスク分類
- 2週目: Revocation APIラッパー実装、アラート連携
- 3週目: 漏えい想定ゲームデイで失効〜復旧時間を計測
- 4週目: 「失効カバレッジのない本番資格情報は利用不可」をポリシー化
まとめ
現代のGitHub運用で重要なのは、漏えいゼロを祈ることではなく、漏えい時に“確実かつ短時間で被害を止める仕組み”を持つことです。Revocation API拡張は、その実装を現実的にする転換点です。
