> ## 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 issue/discussion。
* 自动化信号：Dependabot、CodeQL、npm advisories、secret scanning。

初始分诊：

1. 确认受影响的组件、版本和信任边界影响。
2. 使用 `SECURITY.md` 的范围和范围外规则，将其分类为安全问题或加固/无需操作。
3. 事件负责人据此响应。

## 2. 严重性

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

## 3. 响应

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

## 4. 沟通和披露

通过受影响仓库中的 GitHub Security Advisories、已修复版本的发布说明/changelog 条目，以及向报告者直接跟进状态和解决情况来沟通。

严重/高事件进行协调披露，并在适当时发布 CVE。低风险加固发现可根据影响和用户暴露程度，在发布说明或 advisories 中记录而不发布 CVE。

## 5. 恢复和跟进

发布修复后：

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

## 相关

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