1. 检测与分类
监控来源：
- GitHub Security Advisories（GHSA）和私有漏洞报告
- 公开 GitHub issues/discussions（非敏感报告）
- 自动化信号（Dependabot、CodeQL、npm advisories、secret scanning）
初始分类步骤：
- 确认受影响组件、版本和信任边界影响
- 使用仓库
SECURITY.md范围和排除规则分类为安全问题 vs 加固/无需操作 - 事件负责人相应响应
2. 严重程度评估
| 级别 | 标准 |
|---|---|
| Critical | 包/发布/仓库妥协、主动利用、或未认证信任边界绕过且高影响 |
| High | 已验证的信任边界绕过（需有限前提条件），或 OpenClaw 自有敏感凭证暴露 |
| Medium | 有实际影响但可利用性受限或需大量前提条件的重大安全弱点 |
| Low | 纵深防御发现、范围窄的 DoS、或无已证明信任边界绕过的加固差距 |
3. 响应流程
- 向报告者确认收到（敏感时私下进行）
- 在支持的发布版本和最新
main上复现，实现并验证带回归覆盖的补丁 - Critical/High：尽快准备补丁发布
- Medium/Low：在正常发布流程中修补，记录缓解指导
4. 沟通
渠道：
- 受影响仓库的 GitHub Security Advisories
- 已修复版本的发布说明/变更日志
- 直接向报告者跟进状态和解决方案
披露策略：
- Critical/High：协调披露，适时发布 CVE
- 低风险加固发现：可在发布说明或 advisory 中记录，无需 CVE
5. 恢复与跟进
发布修复后：
- 在 CI 和发布产物中验证修复
- 进行简短的事后审查（时间线、根本原因、检测差距、预防计划）
- 添加后续加固/测试/文档任务并跟踪完成
相关页面
- security-threat-model-atlas — MITRE ATLAS 威胁模型
- security-formal-verification — 形式化验证