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