シークレットスキャンのパターン更新を“運用イベント”に変える実践モデル
GitHubのSecret Scanningパターン更新は、見た目は小さな変更でも、実際には本番リスクを毎月動かします。新しいトークン形式が検知対象になり、誤検知の分布が変わり、アラートの責任範囲がチーム間で移動します。これを「通知が来たら見る」レベルで運用していると、影響を理解するのはインシデント後になりがちです。
重要なのは、パターン更新をフィードの出来事ではなく統制変更の出来事として扱うことです。つまり「検知ルールが増えた」ではなく「検知面が変わったので、SLA・責任・証跡を更新する」が正しい反応です。
なぜ“月次イベント”として扱うべきか
更新が発生すると、最低でも次の3点が変わります。
- カバレッジ拡張: 以前は見えなかった鍵が見える
- 精度変化: ノイズが減る/増えるパターンが出る
- 責任移動: どのリポジトリで誰が対応するかが変わる
ここで再ベースラインを取らないと、ダッシュボード解釈を誤ります。アラート急増は悪化ではなく“真陽性増加”かもしれないし、急減は改善ではなく“盲点化”かもしれません。
月次の「Detection Change Window」を作る
実務では、更新ごとに軽量な変更窓口を持つと安定します。記録すべきは以下です。
- 更新日と影響範囲
- 対象リポジトリ（重要系・公開系・規制対象）
- 一次対応オーナー
- 新規アラート分類ごとのSLA
- 誤検知急増時のエスカレーション
この記録は監査にも効きます。「いつ、誰が、どの統制変更を評価したか」を示せるためです。
トリアージ分類を固定する
新規アラートは4分類に寄せると、判断が速くなります。
- A1: 有効な認証情報（即時失効・ローテーション・インシデント起票）
- A2: 過去鍵だが有効（期限付きで失効、影響範囲記録）
- B1: テスト用途/無効鍵（証跡付きクローズ、再発防止タスク化）
- B2: 誤検知（限定スコープで抑制、必ず有効期限を設定）
特にB2は期限がないと危険です。永久抑制は、将来の真陽性を見逃す温床になります。
失効速度を上げる設計
多くの組織で失効が遅い理由は、鍵の発行元が分散していることです。クラウドIAM、CI、SaaS管理画面など、回収経路が統一されていません。実践的には「トークン接頭辞→管理システム→失効手順→当番責任者」の対応表を作るだけで改善します。
- 例:
ghp_→ GitHub PAT管理 → API失効 → 開発基盤当番 - 例:
sk_live_→ 決済基盤管理 → 手動失効Runbook → FinTech運用当番
このマッピングを整えると、MTTR（失効までの時間）は劇的に短縮できます。
事後検知だけで終わらせない
Secret Scanningは事後検知として強力ですが、予防層を重ねるべきです。
- 保護ブランチへのPush Protection
- PRでの失敗条件（有効鍵検知でブロック）
- 開発端末のpre-commitフック
三層化すると、「ローカルで止める」「CIで止める」「過去漏えいを追跡する」が分担でき、運用負荷を平準化できます。
見るべきKPI
件数だけでは運用品質はわかりません。最低限、次を追います。
- 鍵種別ごとのMTTR-Revocation
- パターン群ごとの真陽性率
- 抑制ルールの平均寿命（長すぎる抑制は危険）
- チーム別の再漏えい率
- 公開リポジトリでの露出時間
件数が増えても、失効速度が改善し再漏えいが下がっていれば、実質的には前進です。
30日で導入するなら
- Week 1: 分類・責任マップ・SLA定義
- Week 2: 現行アラートを上位200件分類
- Week 3: 重要リポジトリへPush/PR制御導入
- Week 4: 有効鍵漏えいを想定した演習と振り返り
パターン更新は「検知精度の話」では終わりません。これは開発組織のセキュリティ運用を毎月更新する“制御面の変化”です。運用イベントとして扱ったチームほど、漏えい発生率も、インシデント時の損失も確実に下げられます。
