security-triage

Original：🇺🇸 English

Translated

Triage GitHub security advisories for OpenClaw with high-confidence close/keep decisions, exact tag and commit verification, trust-model checks, optional hardening notes, and a final reply ready to post and copy to clipboard.

1installs

Sourcesteipete/clawdis

Added on2026-03-29

NPX Install

npx skill4agent add steipete/clawdis security-triage

SKILL.md Content

View Translation Comparison →

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.

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.

Required Reads

Before answering:

Read
```
SECURITY.md
```
.

Read the GHSA body with

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>

.

Inspect the exact implicated code paths.

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
```

Search for canonical overlap:
- existing published GHSAs
- older fixed bugs
- same trust-model class already covered in
```
SECURITY.md
```

Review Method

For each advisory, decide:

```
close
```
```
keep open
```
```
keep open but narrow
```

Check in this order:

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?
Shipped behavior
- Is the bug present in the latest shipped tag or npm release?
- Was it fixed before release?
Exploit path
- Does the report show a real boundary bypass, not just prompt injection, local same-user control, or helper-level semantics?
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.

Response Format

When preparing a maintainer-ready close reply:

Print the GHSA URL first.
Then draft a detailed response the maintainer can post.
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.

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.

Useful Commands