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

# 事件响应

## 1. 检测与分诊

安全信号来自：

* GitHub 安全公告（GHSA）和私有漏洞报告。
* 当报告不敏感时，公开的 GitHub issue/讨论。
* 自动化信号：Dependabot、CodeQL、npm 安全公告、密钥扫描。

初始分诊：

1. 确认受影响的组件、版本和信任边界影响。
2. 使用 `SECURITY.md` 的范围和不在范围内规则，将其归类为安全问题 vs. 加固/无需处理。
3. 事件负责人作出相应响应。

## 2. 严重性

| 严重性 | 定义                                                          |
| --- | ----------------------------------------------------------- |
| 严重  | 包/发布/仓库被攻破、正在进行的利用，或未经身份验证的信任边界绕过，且具有高影响的控制或数据暴露。           |
| 高   | 已验证的信任边界绕过，仅需有限前置条件（例如，已认证但未授权的高影响操作），或 OpenClaw 持有的敏感凭据泄露。 |
| 中   | 具有实际影响但可利用性受限，或存在较高前置条件的显著安全弱点。                             |
| 低   | 深度防御类发现、范围较窄的拒绝服务，或未证明存在信任边界绕过的加固/一致性缺口。                    |

## 3. 响应

1. 向报告者确认已收到（涉及敏感信息时私下确认）。
2. 在受支持的版本和最新的 `main` 上复现问题，然后实现并验证补丁，同时提供回归覆盖。
3. 严重/高：尽快准备已修补的版本。
4. 中/低：按正常发布流程修补，并记录缓解指导。

## 4. 通信与披露

通过受影响仓库中的 GitHub 安全公告、修复版本的发行说明/变更日志条目，以及对报告者的状态和解决情况进行直接跟进来进行沟通。

严重/高危事件采用协调披露，在适当情况下会分配 CVE。低风险的加固发现可根据影响和用户暴露情况记录在发行说明或公告中，而无需 CVE。

## 5. 恢复与跟进

在发布修复后：

1. 在 CI 和发布构件中验证修复措施。
2. 进行一次简短的事后复盘：时间线、根本原因、检测缺口、预防计划。
3. 添加后续加固/测试/文档任务，并跟踪直至完成。

## 相关

* [安全策略](https://github.com/openclaw/openclaw/blob/main/SECURITY.md) — 报告范围和信任模型。
* [威胁模型](/security/THREAT-MODEL-ATLAS)