> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 事件回應

## 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. 新增後續的安全強化／測試／文件工作，並追蹤至完成。

## 相關內容

* [安全性政策](https://github.com/openclaw/openclaw/blob/main/SECURITY.md) — 報告範圍與信任模型。
* [威脅模型](/zh-TW/security/THREAT-MODEL-ATLAS)