Back to Details

security-triage

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Triage

安全分类处理

Use when reviewing OpenClaw security advisories, drafts, or GHSA reports.
Goal: high-confidence maintainers' triage without over-closing real issues or shipping unnecessary regressions.
适用于审核OpenClaw安全公告、草稿或GHSA报告的场景。
目标：为维护者提供高置信度的分类结果，既不会误关真实问题，也不会引入不必要的回归问题。

Close Bar

关闭门槛

Close only if one of these is true:
  • duplicate of an existing advisory or fixed issue
  • invalid against shipped behavior
  • out of scope under 
    SECURITY.md
  • fixed before any affected release/tag
Do not close only because 
main
is fixed. If latest shipped tag or npm release is affected, keep it open until released or published with the right status.
仅当满足以下任一条件时才可关闭：
  • 与现有公告或已修复问题重复
  • 针对已发布版本的行为判定无效
  • 属于
    SECURITY.md
    中约定的非处理范围
  • 在任何受影响的发布版本/标签发布前已修复
请勿仅因为
main
分支已修复就关闭公告。如果最新发布的标签或npm版本仍受影响，需保持公告打开状态，直到修复版本发布并更新为对应状态。

Required Reads

必读内容

Before answering:
  1. Read 
    SECURITY.md
    .
  2. Read the GHSA body with 
    gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
    .
  3. Inspect the exact implicated code paths.
  4. Verify shipped state: 
    • git tag --sort=-creatordate | head
    • npm view openclaw version --userconfig "$(mktemp)"
    • git tag --contains <fix-commit>
    • if needed: 
      git show <tag>:path/to/file
  5. Search for canonical overlap:
    • existing published GHSAs
    • older fixed bugs
    • same trust-model class already covered in 
      SECURITY.md
回复前需完成以下操作：
  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
      中已覆盖的同类型信任模型问题

Review Method

审核方法

For each advisory, decide:
  • close
  • keep open
  • keep open but narrow
Check in this order:
  1. Trust model
    • Is the prerequisite already inside trusted host/local/plugin/operator state?
    • Does 
      SECURITY.md
      explicitly call this class out as out of scope or hardening-only?
  2. Shipped behavior
    • Is the bug present in the latest shipped tag or npm release?
    • Was it fixed before release?
  3. Exploit path
    • Does the report show a real boundary bypass, not just prompt injection, local same-user control, or helper-level semantics?
  4. Functional tradeoff
    • If a hardening change would reduce intended user functionality, call that out before proposing it.
    • Prefer fixes that preserve user workflows over deny-by-default regressions unless the boundary demands it.
针对每个公告，判定为以下三种状态之一：
  • close
    （关闭）
  • keep open
    （保持打开）
  • keep open but narrow
    （保持打开但缩小范围）
按以下顺序校验：
  1. 信任模型
    • 漏洞前置条件是否已经属于受信任的主机/本地/插件/运维状态？
    • SECURITY.md
      是否明确将此类问题标记为非处理范围或仅需加固？
  2. 已发布版本行为
    • 缺陷是否存在于最新发布的标签或npm版本中？
    • 是否在版本发布前就已修复？
  3. 利用路径
    • 报告是否证明存在真实的边界绕过，而非只是提示注入、本地同用户控制或工具级语义问题？
  4. 功能权衡
    • 如果安全加固变更会影响预期用户功能，提出前需明确说明。
    • 优先选择保留用户工作流的修复方案，除非安全边界要求必须采用默认拒绝的策略，否则不要引入回归问题。

Response Format

回复格式

When preparing a maintainer-ready close reply:
  1. Print the GHSA URL first.
  2. Then draft a detailed response the maintainer can post.
  3. Include:
    • exact reason for close
    • exact code refs
    • exact shipped tag / release facts
    • exact fix commit or canonical duplicate GHSA when applicable
    • optional hardening note only if worthwhile and functionality-preserving
Keep tone firm, specific, non-defensive.
准备供维护者使用的关闭回复时：
  1. 首先列出GHSA URL。
  2. 然后撰写维护者可直接发布的详细回复。
  3. 包含以下内容：
    • 关闭的具体原因
    • 具体的代码引用
    • 已发布标签/版本的具体事实
    • 适用情况下提供具体的修复提交或重复GHSA链接
    • 仅当加固方案有价值且不影响功能时，可选添加加固说明
回复语气需坚定、具体、无辩解感。

Clipboard Step

剪贴板步骤

After drafting the final post body, copy it:
bash
pbcopy <<'EOF'
<final response>
EOF
Tell the user that the clipboard now contains the proposed response.
撰写完最终发布内容后，执行以下操作复制内容：
bash
pbcopy <<'EOF'
<final response>
EOF
告知用户剪贴板中已存储建议回复内容。

Useful Commands

常用命令

bash
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>"
bash
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>"

Decision Notes

决策说明

  • “fixed on main, unreleased” is usually not a close.
  • “needs attacker-controlled trusted local state first” is usually out of scope.
  • “same-host same-user process can already read/write local state” is usually out of scope.
  • “helper function behaves differently than documented config semantics” is usually invalid.
  • If only the severity is wrong but the bug is real, keep it open and narrow the impact in the reply.
  • “main分支已修复但未发布”通常不可关闭。
  • “需要攻击者先控制受信任的本地状态”通常属于非处理范围。
  • “同主机同用户进程已可读写本地状态”通常属于非处理范围。
  • “工具函数行为与文档记录的配置语义不一致”通常判定为无效。
  • 如果仅严重等级判定错误但缺陷真实存在，保持公告打开并在回复中缩小影响范围。