---
read_when:
    - 响应安全报告或疑似安全事件
    - 准备协调披露或已修补的安全发布
    - 复盘事件后跟进预期
summary: OpenClaw 如何分诊、响应并跟进安全事件
title: 事件响应
x-i18n:
    generated_at: "2026-07-05T11:44:18Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 30f2d754408e95133ee86254ce193c0d8aab293040df55e0c1cec0c4d7644c56
    source_path: security/incident-response.md
    workflow: 16
---

## 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)