事件回應

1. 偵測與分流處理

安全性訊號來自：

• GitHub Security Advisories (GHSA) 與私下提交的弱點報告。
• 報告不涉及敏感資訊時，使用公開的 GitHub 議題／討論。
• 自動化訊號：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. 新增後續的安全強化／測試／文件工作，並追蹤至完成。

相關內容

• 安全性政策 — 報告範圍與信任模型。
• 威脅模型