security-triage

安全问题分流

在审查 OpenClaw 安全公告、草稿或 GHSA 报告时使用。

目标：以高置信度帮助维护者进行分流，既不过度关闭真实问题，也不引入不必要的回归。

关闭标准

仅在满足以下任一条件时关闭：

• 与现有安全公告或已修复的问题重复
• 根据已发布的行为，该问题无效
• 根据 SECURITY.md，该问题不在范围内
• 在任何受影响的版本/标签发布前已修复

不要仅因为 main 分支已修复就关闭。如果最新已发布的标签或 npm 版本仍受影响，请保持问题开放，直到修复随正确状态发布。

必须阅读

作答前：

1. 阅读 SECURITY.md。
2. 使用 gh api /repos/openclaw/openclaw/security-advisories/<GHSA> 阅读 GHSA 正文。
3. 检查确切涉及的代码路径。
4. 验证已发布状态：
   • git tag --sort=-creatordate | head
   • npm view openclaw version --userconfig "$(mktemp)"
   • git tag --contains <fix-commit>
   • 如有需要：git show <tag>:path/to/file
5. 搜索是否存在规范性重叠：
   • 已发布的 GHSA
   • 较早修复的漏洞
   • SECURITY.md 中已涵盖的相同信任模型类别

审查方法

对于每项安全公告，决定：

• close
• keep open
• keep open but narrow

涉及评论/关闭时，默认一次处理一项安全公告：

1. 只审查一项 GHSA。
2. 首先打印 GHSA URL。
3. 总结决定及证据，供讨论。
4. 起草一条可供维护者直接发布的评论。
5. 仅将这条评论复制到剪贴板。
6. 停下并等待 Peter 发布/讨论后，再处理下一项 GHSA。

除非 Peter 明确要求批量处理，否则不要批量起草多条关闭评论。

按以下顺序检查：

1. 信任模型
   • 前置条件是否已经处于受信任的主机/本地/插件/操作者状态中？
   • SECURITY.md 是否明确指出此类别不在范围内，或仅属于安全加固？
2. 已发布行为
   • 最新已发布的标签或 npm 版本是否存在该漏洞？
   • 是否在发布前修复？
3. 利用路径
   • 报告是否展示了真实的边界绕过，而不只是提示词注入、本地同一用户控制或辅助函数层面的语义？
   • 如果数据只在 SECURITY.md 指明的受信任工作区记忆文件之间流动，不要仅凭“注入标记”就将其视为安全漏洞。
   • 在这种情况下，只有在不影响预期记忆工作流时，才将净化处理作为可选的安全加固提出。
4. 功能权衡
   • 如果安全加固会削弱预期的用户功能，提出建议前要明确指出这一点。
   • 除非边界要求采取默认拒绝，否则应优先选择能保留用户工作流的修复方案，避免引入回归。
5. 后续安全加固
   • 即使应该关闭 GHSA，也要评估是否可以通过范围较窄的安全加固减少误用风险，同时不改变文档所述的信任边界。
   • 将安全加固与漏洞状态分开。表述为“并非关闭 GHSA 的必要条件，但值得考虑”。
   • 只有当安全加固方案具体、风险低且能保留维护者/操作者的预期工作流时，才提出。
   • 如果安全加固需要改变产品/安全模型，请明确说明，不要暗示它是关闭问题的必要修复。

回复格式

准备可供维护者直接发布的关闭回复时：

1. 首先打印 GHSA URL。
2. 然后起草一份维护者可以发布的详细回复。
3. 包括：
   • 确切的关闭理由
   • 确切的代码引用
   • 确切的已发布标签/版本事实
   • 修复来源，或适用时提供规范性重复 GHSA
   • 仅在值得提出且不影响功能时，附上可选的安全加固说明

语气坚定、具体，不带防御性。

公开措辞规范

• 不要在公开公告文本中写入原始提交哈希、PR 标题／编号或修复机制摘要。仅使用已修复的发行版／版本字段。
• 在内部备注和验证文件中保留完整的提交 SHA、PR 和实现说明。
• 对于加固／不发布的处理结果，不要添加过多利用细节、“修复方式”文字或“修复提交”章节。感谢报告者，保留致谢，说明 SECURITY.md 的范围边界，并明确表示该 GHSA 将在不公开发布的情况下关闭。
• 对于已发布的 CVE／GHSA 文本，优先使用 ### 已修复版本，并列出修复版本。除非 Peter 明确要求公开说明，否则不要解释补丁的工作原理。
• 除非 Peter 明确要求，否则不要在变更日志和发行说明措辞中写入 GHSA ID。

讨论模式

当 Peter 手动发布 GHSA 评论时，请按以下流程操作：

1. 显示 URL。
2. 给出简短结论（close、keep open 或 keep open but narrow）。
3. 列出最有力的证据要点。
4. 将任何可选的加固后续工作与关闭理由分开说明。
5. 使用 pbcopy 复制拟发布的评论正文。
6. 在该条公告后结束回复。Peter 说继续之前，不要处理下一条公告。

如果 GitHub API 无法为私有公告发布评论，请说明一次，然后继续使用剪贴板／UI 粘贴。

剪贴板步骤

为当前公告拟好最终发布正文后，将其复制：

pbcopy <<'EOF'
<final response>
EOF

告知用户，剪贴板中现在已包含该公告的拟议回复。

常用命令

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<terms>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<terms>"

网络安全分类器中断

对于被网络安全分类器打断的允许范围内的防御性工作，仅针对该限定任务使用获准且可用的 Daybreak Blue 路径，然后恢复先前使用的模型。保留获准的身份、范围、权限、沙箱和审核关卡。绝不要通过切换模型来绕过访问拒绝、不允许的请求或被拒绝的工具操作；如果该路径也拒绝执行，请停止并报告。请遵循 OpenAI 的指导以使用获准的模型访问权限。

决策说明

• “已在 main 上修复，尚未发布”通常不足以作为关闭理由。
• “首先需要攻击者控制可信的本地状态”通常属于范围外。
• “同一主机上的同一用户进程已能读取／写入本地状态”通常属于范围外。
• “可信工作区记忆会提升／重新索引可信工作区记忆”通常属于范围外，除非跨越了已记录的边界。
• “辅助函数的行为与已记录的配置语义不同”通常无效。
• 如果只有严重程度判断有误，但漏洞确实存在，则保持开放，并在回复中缩小影响范围。