快速开始
事件响应
1. 检测和分诊
安全信号来自：
- GitHub Security Advisories (GHSA) 和私有漏洞报告。
- 报告不敏感时的公开 GitHub issue/discussion。
- 自动化信号：Dependabot、CodeQL、npm advisories、secret scanning。
初始分诊：
- 确认受影响的组件、版本和信任边界影响。
- 使用
SECURITY.md的范围和范围外规则，将其分类为安全问题或加固/无需操作。 - 事件负责人据此响应。
2. 严重性
| 严重性 | 定义 |
|---|---|
| 严重 | 包/发布/仓库被攻陷、正在被主动利用，或未经身份验证的信任边界绕过，并伴随高影响控制或数据暴露。 |
| 高 | 已验证的信任边界绕过，需要有限前置条件（例如，已认证但未授权的高影响操作），或 OpenClaw 所有的敏感凭证暴露。 |
| 中 | 具有实际影响的重大安全弱点，但可利用性受限或需要大量前置条件。 |
| 低 | 纵深防御发现、范围狭窄的拒绝服务，或未证明存在信任边界绕过的加固/一致性缺口。 |
3. 响应
- 向报告者确认收到（敏感时私下确认）。
- 在受支持的发布版本和最新
main上复现，然后实现并验证带回归覆盖的补丁。 - 严重/高：尽快准备已修补的发布版本。
- 中/低：在正常发布流程中修补，并记录缓解指导。
4. 沟通和披露
通过受影响仓库中的 GitHub Security Advisories、已修复版本的发布说明/changelog 条目，以及向报告者直接跟进状态和解决情况来沟通。
严重/高事件进行协调披露，并在适当时发布 CVE。低风险加固发现可根据影响和用户暴露程度，在发布说明或 advisories 中记录而不发布 CVE。
5. 恢复和跟进
发布修复后：
- 在 CI 和发布产物中验证补救措施。
- 运行简短的事件后复盘：时间线、根因、检测缺口、预防计划。
- 添加后续加固/测试/文档任务，并跟踪至完成。
相关
Was this useful?
