はじめに
インシデント対応
1. 検出とトリアージ
セキュリティシグナルの発生源:
- GitHub Security Advisories（GHSA）および非公開の脆弱性報告。
- 報告に機密性がない場合の公開 GitHub issue／ディスカッション。
- 自動化されたシグナル: Dependabot、CodeQL、npm アドバイザリ、シークレットスキャン。
初期トリアージ:
- 影響を受けるコンポーネント、バージョン、トラスト境界への影響を確認する。
SECURITY.mdの対象範囲と対象外の規則を使用して、セキュリティ問題か、ハードニング／対応不要かを分類する。- インシデント所有者が分類に応じて対応する。
2. 深刻度
| 深刻度 | 定義 |
|---|---|
| 重大 | パッケージ／リリース／リポジトリの侵害、進行中の悪用、または認証なしでトラスト境界を迂回し、重大な制御権の取得やデータ漏えいにつながるもの。 |
| 高 | 限定的な前提条件を必要とする、確認済みのトラスト境界の迂回（たとえば、認証済みだが許可されていない重大な操作）、または OpenClaw が所有する機密性の高い認証情報の漏えい。 |
| 中 | 実用上の影響が大きいものの、悪用可能性が限定されているか、相当な前提条件を必要とする重大なセキュリティ上の弱点。 |
| 低 | 多層防御に関する指摘、範囲が限定されたサービス拒否、またはトラスト境界の迂回が実証されていないハードニング／同等性の不足。 |
3. 対応
- 報告者に受領を通知する（機密性がある場合は非公開で）。
- サポート対象のリリースおよび最新の
mainで再現し、リグレッションカバレッジを備えたパッチを実装して検証する。 - 重大／高: 実務上可能な限り迅速に修正版リリースを準備する。
- 中／低: 通常のリリースフローでパッチを適用し、緩和策のガイダンスを文書化する。
4. コミュニケーションと開示
影響を受けるリポジトリの GitHub Security Advisories、修正版のリリースノート／変更履歴エントリ、および状況と解決について報告者への直接のフォローアップを通じて情報を伝える。
重大／高のインシデントでは、必要に応じて CVE を発行し、調整された開示を行う。リスクの低いハードニングに関する指摘は、影響とユーザーへの露出に応じて、CVE を発行せずにリリースノートまたはアドバイザリに記載する場合がある。
5. 復旧とフォローアップ
修正のリリース後:
- CI およびリリース成果物で修正措置を検証する。
- 簡潔なインシデント後レビューを実施する: タイムライン、根本原因、検出上の不足、再発防止計画。
- ハードニング／テスト／ドキュメントに関するフォローアップタスクを追加し、完了まで追跡する。
関連項目
- セキュリティポリシー — 報告対象範囲とトラストモデル。
- 脅威モデル
Was this useful?
