事件回應

# 1. 偵測與分流

我們監控來自以下來源的安全訊號：

• GitHub 安全公告（GHSA）與私密漏洞回報。
• 回報內容不敏感時的公開 GitHub 議題/討論。
• 自動化訊號（例如 Dependabot、CodeQL、npm 公告與密鑰掃描）。

初步分流：

1. 確認受影響的元件、版本與信任邊界影響。
2. 使用儲存庫 SECURITY.md 的範圍與不在範圍內規則，分類為安全問題或強化/無需處置。
3. 事件負責人據此回應。

# 2. 評估

嚴重性指南：

• 嚴重： 套件/發布/儲存庫遭入侵、正在遭受主動利用，或未經驗證即可繞過信任邊界，造成高影響控制權或資料暴露。
• 高： 經驗證的信任邊界繞過，且只需要有限前提條件（例如已驗證但未授權的高影響操作），或暴露 OpenClaw 擁有的敏感憑證。
• 中： 具有實際影響的重大安全弱點，但可利用性受限或需要大量前提條件。
• 低： 縱深防禦發現、範圍狹窄的阻斷服務，或未展示信任邊界繞過的強化/對等性缺口。

# 3. 回應

1. 向回報者確認收到回報（敏感內容採私密方式）。
2. 在支援的發布版本與最新 main 上重現，然後實作並驗證修補程式，並加入迴歸覆蓋。
3. 對於嚴重/高等級事件，盡快準備已修補的發布版本。
4. 對於中/低等級事件，在正常發布流程中修補，並記錄緩解指引。

# 4. 溝通

我們透過以下方式溝通：

• 受影響儲存庫中的 GitHub 安全公告。
• 修復版本的發布說明/變更記錄項目。
• 直接向回報者追蹤狀態與解決結果。

揭露政策：

• 嚴重/高等級事件應採協調式揭露，並在適當時核發 CVE。
• 低風險強化發現可依影響與使用者暴露程度，記錄於發布說明或公告中，而不核發 CVE。

# 5. 復原與後續追蹤

修復發布後：

1. 在 CI 與發布成品中驗證補救措施。
2. 執行簡短的事件後檢討（時間線、根本原因、偵測缺口、預防計畫）。
3. 新增後續強化/測試/文件任務，並追蹤至完成。