---
read_when:
    - 响应安全报告或疑似安全事件
    - 准备协调披露或已修补的安全发布
    - 审查事故后的跟进预期
summary: OpenClaw 如何分诊、响应并跟进安全事件
title: 事件响应
x-i18n:
    generated_at: "2026-05-03T11:34:41Z"
    model: gpt-5.5
    provider: openai
    source_hash: ef39b037cf3574a61fd67b356654f1ea0b91d84f89345c22aae93c1db7694df8
    source_path: security/incident-response.md
    workflow: 16
---

# 事件响应

## 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. 添加后续加固/测试/文档任务，并跟踪到完成。
