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