事件响应

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