Get started
インシデント対応
1. 検出とトリアージ
セキュリティシグナルの発生元:
- GitHub Security Advisories (GHSA) と非公開の脆弱性報告。
- 報告が機微でない場合の公開 GitHub issue/discussion。
- 自動シグナル: Dependabot、CodeQL、npm advisories、secret scanning。
初期トリアージ:
- 影響を受けるコンポーネント、バージョン、信頼境界への影響を確認する。
SECURITY.mdの対象範囲および対象外ルールを使用して、セキュリティ issue か、強化/対応不要かを分類する。- インシデントオーナーがそれに応じて対応する。
2. 重大度
| 重大度 | 定義 |
|---|---|
| Critical | パッケージ/リリース/リポジトリの侵害、実際の悪用、または高影響の制御やデータ露出を伴う、未認証での信頼境界バイパス。 |
| High | 限定的な前提条件を必要とする検証済みの信頼境界バイパス (たとえば、認証済みだが権限のない高影響アクション)、または OpenClaw が所有する機微な認証情報の露出。 |
| Medium | 実用上の影響は大きいが、悪用可能性が制約されている、または相当な前提条件を必要とする重大なセキュリティ上の弱点。 |
| Low | 多層防御の所見、範囲が限定されたサービス拒否、または実証された信頼境界バイパスを伴わない強化/同等性のギャップ。 |
3. 対応
- 報告者に受領を確認する (機微な場合は非公開で)。
- サポート対象リリースと最新の
mainで再現し、その後リグレッションカバレッジ付きのパッチを実装して検証する。 - Critical/High: 実務上可能な限り迅速にパッチ済みリリースを準備する。
- Medium/Low: 通常のリリースフローでパッチを適用し、緩和策のガイダンスを文書化する。
4. コミュニケーションと開示
影響を受けるリポジトリの GitHub Security Advisories、修正済みバージョンのリリースノート/changelog エントリ、および状態と解決に関する報告者への直接フォローアップを通じて連絡する。
Critical/High インシデントは、適切な場合に CVE 発行を伴う協調的な開示を行う。低リスクの強化所見は、影響とユーザー露出に応じて、CVE なしでリリースノートまたはアドバイザリに文書化される場合がある。
5. 復旧とフォローアップ
修正を出荷した後:
- CI とリリースアーティファクトで修復を検証する。
- 短いインシデント後レビューを実施する: タイムライン、根本原因、検出ギャップ、予防計画。
- フォローアップの強化/テスト/ドキュメントタスクを追加し、完了まで追跡する。
関連
- セキュリティポリシー — 報告範囲と信頼モデル。
- 脅威モデル
Was this useful?
