GitHub Secret Scanning拡張を成果につなげる: 封じ込め中心の運用設計

Secret Scanningの検知対象が増えると、改善した気になりやすい一方で、未対応アラートが積み上がるリスクも増えます。重要なのは検知件数ではなく、封じ込め速度です。

4状態で管理する

1. Detected（検知）
2. Validated（真偽判定）
3. Contained（封じ込め）
4. Verified（再発防止確認）

Containedの証跡がないCloseは運用上の未完了として扱います。

トリアージを自動化する

各アラートに次を自動付与します。

• 種別/提供元
• 初出コミット
• 影響範囲
• リポジトリ重要度

S1/S2/S3に分類し、応答SLAを固定します。

封じ込めの必須項目

• 鍵の失効またはローテーション
• ログ調査
• forkやartifactへの拡散確認
• 予防策（hook/CI/権限縮小）の適用

責任分担

• サービス側: 封じ込め完了責任
• セキュリティ基盤側: 検知品質と統制責任

指標

• MTTV
• MTTC
• 再発率
• 自動ローテーション率

結論

検知拡張はゴールではなく、運用品質を問う開始点です。封じ込め中心の設計に切り替えることで、はじめて実効的なリスク低減になります。