インシデント対応

# 1. 検出とトリアージ

次のセキュリティシグナルを監視します。

• GitHub Security Advisories (GHSA) と非公開の脆弱性レポート。
• レポートが機密でない場合の公開 GitHub issues/discussions。
• 自動シグナル（たとえば Dependabot、CodeQL、npm アドバイザリ、シークレットスキャン）。

初期トリアージ:

1. 影響を受けるコンポーネント、バージョン、信頼境界への影響を確認します。
2. リポジトリの SECURITY.md のスコープと対象外ルールを使用して、セキュリティ問題か、堅牢化/対応不要かを分類します。
3. インシデントオーナーが状況に応じて対応します。

# 2. 評価

深刻度ガイド:

• 重大: パッケージ/リリース/リポジトリの侵害、実際の悪用、または影響の大きい制御やデータ露出を伴う未認証の信頼境界バイパス。
• 高: 限定的な前提条件を必要とする検証済みの信頼境界バイパス（たとえば認証済みだが未認可の影響の大きいアクション）、または OpenClaw が所有する機密認証情報の露出。
• 中: 実用的な影響があるものの、悪用可能性が制約されているか、相当な前提条件を必要とする重大なセキュリティ上の弱点。
• 低: 多層防御の指摘、範囲の狭いサービス拒否、または実証された信頼境界バイパスを伴わない堅牢化/同等性のギャップ。

# 3. 対応

1. 報告者に受領を確認します（機密の場合は非公開で行います）。
2. サポート対象リリースと最新の main で再現し、リグレッションカバレッジを含むパッチを実装して検証します。
3. 重大/高のインシデントでは、実務上可能な限り速やかにパッチ済みリリースを準備します。
4. 中/低のインシデントでは、通常のリリースフローでパッチを適用し、緩和策のガイダンスを文書化します。

# 4. コミュニケーション

次の方法で連絡します。

• 影響を受けるリポジトリの GitHub Security Advisories。
• 修正済みバージョンのリリースノート/変更履歴エントリ。
• 状況と解決に関する報告者への直接フォローアップ。

公開ポリシー:

• 重大/高のインシデントでは、適切な場合に CVE 発行を伴う協調的な公開を行う必要があります。
• 低リスクの堅牢化に関する指摘は、影響とユーザー露出に応じて、CVE なしでリリースノートまたはアドバイザリに文書化される場合があります。

# 5. 復旧とフォローアップ

修正を出荷した後:

1. CI とリリース成果物で修復を検証します。
2. 短いインシデント後レビュー（タイムライン、根本原因、検出ギャップ、予防計画）を実施します。
3. フォローアップの堅牢化/テスト/ドキュメントタスクを追加し、完了まで追跡します。