2.2Secret Protection アラートの管理・ポリシー・カスタムパターン

検出された秘密は アラート として管理します。GH-500 では、アラートの ライフサイクル（作成→トリアージ→対応→状態更新）と、それを支える ポリシー・通知・カスタマイズ が問われます。中心は「検出して終わり」ではなく 適切に修復し、組織で統制する ことです。

2.2.1アラートのライフサイクルと修復

シークレットアラートは 作成（検出） され、オープン 状態になります。担当者はトリアージし、対応後に状態を更新します——正しく対処すれば 解決、誤検知や許容済みなら理由を付けて 却下（dismiss）（「誤検知」「テストで使用」「リスク受容」などの理由）します。最重要の修復は 漏洩したトークンの無効化（ローテーション） です。ファイルから消すだけでは履歴に残るため、まず 無効化 してから、必要に応じて履歴の対応を検討します。安易な dismiss は危険なので、理由の記録と方針が要ります。

2.2.2ポリシー・受信者・除外

組織は、誰がアラートを閲覧/対応/バイパスできるかを 役割ベース で制御します（委譲バイパス の承認者設定を含む）。アラート受信者 を設定して、新規検出時に適切なチームへ通知します。誤検知や対象外のパス（例：テストデータやドキュメント）は 除外 を設定してノイズを減らします。これらの構成は、検出の精度と運用負荷のバランスを取り、本当に重要なアラートに集中するためのものです。

2.2.3カスタムシークレットパターン

GitHub は多数の 既定パターン（主要プロバイダーのトークン形式）を検出しますが、組織独自のトークンや社内システムの鍵は既定では拾えません。そこで カスタムシークレットパターン を 正規表現 で定義して、組織固有の秘密も検出対象にします。作成時はテストでマッチを確認し、誤検知が多くならないようパターンを調整します。これにより、自社のセキュリティ要件に合わせて検出範囲を広げられます。

2.2.4この節のまとめ

• アラートは作成→オープン→解決/却下。最重要修復は漏洩トークンの無効化（ローテーション）
• 役割ベース/委譲バイパスで制御、受信者で通知、除外でノイズ低減
• 組織固有の秘密はカスタムパターン（正規表現）で検出、誤検知を抑えるよう調整
• dismiss しても無効化はされない＝必ずローテーション、理由は記録