GitHubアカウント侵害が顧客情報事故に発展したときの実践対応

国内でも、GitHubアカウント侵害を起点に個人情報漏えいへ波及する事故が目立ち始めています。重要なのは、これを「開発者のアカウント問題」と矮小化しないことです。実態は、ID管理、CI/CD、顧客データ保護、対外説明まで連鎖する事業継続インシデントです。

典型的な事故連鎖

アカウント乗っ取り（フィッシング、セッション窃取、トークン悪用）
リポジトリ・CI権限の横展開
シークレット探索やworkflow改ざん
接続先システム経由のデータ取得
所有境界の分断による検知遅延

この連鎖は、初動6時間でどこを止めるかで被害規模が大きく変わります。

初動6時間で優先すべきこと

1) 高リスク資格情報の即時凍結

広権限のユーザー/ボットトークン失効
CI経由で払い出した下流資格情報の無効化
workflowログやartifactに露出した秘密情報のローテーション

2) 自動化面の緊急制御

self-hosted runner群の一時停止
デプロイ系workflowを手動承認モードへ
不要な定期実行ジョブを停止

3) 司令系統の明確化

Incident Commander（意思決定）
Communication Owner（社外説明）
Evidence Owner（証跡保全）

担当が曖昧だと、修復作業は進んでも説明責任が崩れます。

法務と技術を両立する証跡モデル

最低限、次の証跡を時系列で確保します。

認証イベント履歴
リポジトリアクセス権の変更履歴
侵害前後のworkflow定義差分
秘密管理基盤のアクセスログ
異常な外向き転送ログ

証跡は追記専用ストアで保持し、取得経路と担当者を記録します。

影響評価の実務フレーム

データを4階層で整理すると、通知判断が速くなります。

A: 認証・金融識別子
B: 個人プロフィール/連絡先
C: 業務メタデータ
D: 内部技術情報

各階層で、

確認済み件数
想定上限件数
推定信頼度
法域ごとの通知要否

を分けて管理します。

対外説明で失敗しないために

良い説明には3要素があります。

確定した事実
未確定事項と次回更新時刻
利用者が今すぐ取るべき行動（パスワード変更、監視、鍵再発行）

「調査中です」だけの更新は、信頼を削ります。

収束後に必ず実装する構造改善

ID基盤

耐フィッシングMFAの必須化
管理権限セッション寿命の短縮
端末健全性連動の条件付きアクセス

リポジトリ統制

重要リポジトリは署名付きコミット必須
workflow変更はセキュリティ承認必須
GitHub App/ボットは最小権限デフォルト

秘密管理と実行制御

長寿命トークンの段階的廃止
環境別CIアイデンティティ分離
runner/agentの外向き通信をポリシー制御

検知

権限昇格の異常検知
clone/export量の急増検知
管理操作の不可能移動検知

30/60/90日計画

30日: 露出経路を閉じ、利用者向け改善状況を公開
60日: IDとworkflow統制の設計変更を本番反映
90日: 外部含む演習で実効性を検証

報道が落ち着いても、統制が検証されるまで“完了”ではありません。

まとめ

GitHub起点インシデントは、開発事故ではなく信頼事故です。初動封じ込め、証跡の厳密性、透明な説明、この3点を同時に回せる運用設計が、次の事故の被害を最小化します。