一、技能概述
该技能用于审核 OpenClaw 的安全公告、草案或 GHSA 报告。目标是以高置信度完成维护者级别的分类（triage），既不过度关闭真实问题，也不引入不必要的回归。
核心原则：不因 main 分支已修复就关闭公告，若最新发布的 tag 或 npm 版本仍受影响，则保持开启直到正确发布。
二、核心功能
1. 关闭标准（Close Bar）
只有在以下情况之一成立时才关闭公告：
-
与现有公告或已修复问题重复
-
与已发布行为不符（invalid）
-
在
SECURITY.md定义的范围之外 -
在所有受影响的 release/tag 之前已修复
不因 main 已修复而关闭。
2. 前置必读与证据收集
在给出结论前，必须完成以下步骤：
-
阅读
SECURITY.md -
通过
gh api获取 GHSA 正文 -
检查确切的受影响代码路径
-
验证已发布状态：
-
git tag --sort=-creatordate | head -
npm view openclaw version -
git tag --contains <SHA> -
git show :path/to/file
-
-
搜索规范重叠项：已发布的 GHSA、旧的已修复 Bug、已在
SECURITY.md中覆盖的相同信任模型类别
3. 审核方法（Review Method）
对每个公告，决定：
-
关闭（close）
-
保持开启（keep open）
-
保持开启但收窄范围（keep open but narrow）
逐个处理原则：
-
一次只审核一个 GHSA
-
先输出 GHSA URL
-
总结决策和证据供讨论
-
草拟一条维护者可直接使用的评论
-
复制该评论到剪贴板
-
停下来等待 Peter 发布/讨论，然后再处理下一个 GHSA
-
不批量处理多个关闭评论，除非 Peter 明确要求
4. 检查顺序（Check Order）
按以下顺序进行检查：
| 检查维度 | 关键问题 |
|---|---|
| 信任模型 | 前提条件是否已在受信主机/本地/插件/操作员状态内？SECURITY.md 是否明确将其归为范围外或仅加固（hardening-only）？ |
| 已发布行为 | Bug 是否存在于最新发布的 tag 或 npm 版本？是否在发布前已修复？ |
| 利用路径 | 报告是否展示了真正的边界绕过（boundary bypass），而不仅仅是指令注入、本地同用户控制或 helper 级语义问题？ |
| 功能权衡 | 加固性修改是否会减少预期的用户功能？优先选择保留用户工作流的修复方案，而非默认拒绝（deny-by-default）的回归 |
| 加固跟进 | 即使 GHSA 应关闭，是否有一个窄的加固修改可以减少误用风险而不改变文档化的信任边界？ |
5. 数据安全边界判断
-
如果数据仅在
SECURITY.md中声明的受信工作区内存文件之间移动，不将“注入标记”单独视为安全 Bug -
此类情况应将清理（sanitization）框架化为可选的加固（optional hardening），前提是它不影响预期的内存工作流
6. 响应格式（Response Format）
准备维护者可用的关闭回复时：
-
先输出 GHSA URL
-
草拟详细回复，包含：
-
关闭的确切理由
-
确切的代码引用
-
确切的已发布 tag/release 事实
-
修复来源（fix provenance）或规范重复 GHSA（如适用）
-
可选的加固说明（仅当有价值且不破坏功能时）
-
语气保持坚定、具体、非防御性。
7. 公开措辞卫生（Public Wording Hygiene）
| 应做 | 不应做 |
|---|---|
| 使用 patched release/version 字段 | 在公开公告文本中包含原始 commit hash、PR 标题/编号或修复机制摘要 |
| 将 SHA、PR 和实现说明保留在内部笔记和验证文件中 | 在加固/不发布的结果中添加利用细节、“Fixed by”文本或“Fix Commit(s)”章节 |
感谢报告者、保留署名、说明 SECURITY.md 边界、明确 GHSA 将关闭而不发布 |
在 changelog 和 release-note 中提及 GHSA ID，除非 Peter 明确要求 |
已发布 CVE/GHSA 文本中优先使用 ### Patched Versions 加修复版本 |
解释补丁如何工作，除非 Peter 明确要求公开细节 |
8. 讨论模式（Discussion Mode）
当 Peter 手动发布 GHSA 评论时：
-
显示 URL
-
给出简洁 verdict（close / keep open / keep open but narrow）
-
列出最强证据要点
-
将可选的加固跟进与关闭理由分开陈述
-
使用
pbcopy复制提议的评论正文 -
回复完一个公告后停止，直到 Peter 示意继续
9. 决策参考（Decision Notes）
技能提供了明确的决策参考：
| 场景 | 结论 |
|---|---|
| “fixed on main, unreleased” | 通常不是关闭理由 |
| “需要攻击者先控制受信本地状态” | 通常属于范围外 |
| “同主机同用户进程已可读写本地状态” | 通常属于范围外 |
| “受信工作区内存提升/重索引受信工作区内存” | 通常属于范围外，除非跨越文档化的边界 |
| “helper 行为与文档化的 config 语义不同” | 通常是无效的 |
| 严重等级错误但 Bug 真实存在 | 保持开启，在回复中收窄影响范围 |
三、主要用途
-
审核 GitHub 安全公告（GHSA）：对新的或现有的安全报告进行系统化分类
-
判断公告应关闭、保持开启还是收窄：基于信任模型、已发布行为和利用路径三个维度做出决策
-
准备维护者可用的关闭/回复评论：包含确切的理由、代码引用和发布事实
-
区分真实漏洞与范围外报告：防止将信任模型内的行为误判为安全漏洞
-
提出可选加固建议：在不改变信任边界的前提下，识别可减少误用的低风险改进
-
维护公开措辞卫生：确保公开公告不泄露敏感的修复实现细节
四、重要原则
-
不因
main已修复而关闭 —— 若最新发布版本仍受影响，保持开启直到正确发布 -
逐个处理 —— 一次只审核一个 GHSA，等待 Peter 确认后再处理下一个
-
证据驱动 —— 每个决策必须包含确切的代码引用和已发布 tag/release 事实
-
信任模型优先 —— 先判断前提条件是否已在受信边界内
-
加固与漏洞状态分离 —— 加固是可选的，不作为关闭的必要条件
-
公开措辞卫生 —— commit hash、PR 编号和修复细节保留在内部，不进入公开公告
-
功能优先 —— 优先选择保留用户工作流的修复方案，而非默认拒绝的回归
五、总结
Security Triage 是 OpenClaw 项目中用于安全公告分类与审核的维护者专用技能，通过信任模型、已发布行为和利用路径三个维度的系统化检查，帮助判断 GHSA 报告应关闭、保持开启还是收窄范围。它以交付标签（shipped-tag）为证据核心，强调“不因 main 已修复而关闭”、“逐个处理”、“加固与漏洞状态分离”等原则，并严格规范公开措辞卫生——将 commit hash、PR 细节和修复机制保留在内部，仅公开必要的 patched version 信息。该技能适用于 OpenClaw 维护者在收到 GHSA 报告时进行高置信度分类与审核的场景。
