$ ~/registry/skill/openclaw-agents-skills-security-triage

SKILL

security-triage

Name: security-triage
Author: openclaw

Triage security advisories, drafts, and GHSA reports with trusted evidence.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

The material indicates a prompt-only security triage skill with no required secrets, no declared remote endpoints, and no stated local execution or data read/write capability. Combined with its GitHub open-source source and strong community adoption, the overall risk appears low.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and it does not request tokens, API keys, or other sensitive credentials, so credential exposure and abuse risk is low.

Network egressLow risk

The system flags it as prompt-only and the metadata declares no remote endpoints. Although the README mentions `gh api` and `npm view` as manual review steps, the skill itself does not appear to automatically connect to external services or transmit user data.

Code executionLow risk

As a skill marked prompt-only, the material does not indicate actual permission to spawn local processes, run scripts, or invoke system commands. The commands in the README appear to be part of a human review workflow rather than executable capability of the skill itself.

Data accessLow risk

It does not declare the ability to read or write local files, repository contents, the clipboard, or other data resources. While the document suggests reviewing `SECURITY.md`, GHSAs, and code paths, that appears to be guidance rather than inherent data access granted to the skill.

Supply chainLow risk

The source is an open-source GitHub repository, and the system marks it as open-source with very strong community adoption (about 377k stars), which are significant risk-reducing factors. The license and maintenance status are not clearly stated, leaving minor gaps in auditability and upkeep visibility, but not enough on their own to raise the risk level.

Recommendations

Use it as a review-process template and do not grant extra execution-oriented tool permissions.
If future versions add automatic GitHub/NPM/local command access, reassess network and execution risk.
Before adoption, verify the repository license, recent commits, and release history to confirm ongoing maintenance.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "security-triage" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/security-triage/SKILL.md
2. Save it as ~/.claude/skills/security-triage/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Triage a security advisory draft

Prompt

Please triage this OpenClaw security advisory draft, determine affected scope, whether a fix has shipped, and provide shipped-tag and trust-model proof as evidence. Then give a severity rating and remediation recommendation.

Expected

A structured triage result including impact assessment, shipped-status evidence, trust justification, severity, and recommended actions.

Review a GHSA report

Prompt

Please review this GHSA report, verify whether the vulnerability description is accurate, confirm affected and fixed versions, and support your conclusions with shipped-tag and trust-model proof.

Expected

A verification report covering report accuracy, version impact, fix status, and the supporting evidence chain.

Batch summarize security triage findings

Prompt

Please batch summarize the triage findings for the following security advisories and drafts. Output a summary table by severity, fix status, and evidence completeness, and flag items needing manual review.

Expected

A team-friendly summary table highlighting priority, remediation progress, and items requiring further review.

// docs

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

Default to one advisory at a time when comments/closures are involved:

Review exactly one GHSA.
Print the GHSA URL first.
Summarize the decision and evidence for discussion.
Draft one maintainer-ready comment.
Copy only that one comment to the clipboard.
Stop and wait for Peter to post/discuss before moving to the next GHSA.

Do not batch multiple close comments unless Peter explicitly asks for a batch.

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?
- If data only moves between trusted workspace-memory files called out in SECURITY.md, do not treat "injection markers" alone as a security bug.
- In that case, frame sanitization as optional hardening only if it preserves expected memory workflows.
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.
Hardening follow-up
- Even when the GHSA should close, ask whether a narrow hardening change would reduce footguns without changing the documented trust boundary.
- Separate hardening from vulnerability status. Phrase it as "not required for GHSA closure, but worth considering".
- Bring up hardening only if it is concrete, low-risk, and preserves intended maintainer/operator workflows.
- If hardening would require a product/security model change, say that explicitly and do not imply it is a required fix for closure.

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
- fix provenance or canonical duplicate GHSA when applicable
- optional hardening note only if worthwhile and functionality-preserving

Keep tone firm, specific, non-defensive.

Public Wording Hygiene

Keep raw commit hashes, PR titles/numbers, and fix-mechanism summaries out of public advisory text. Use the patched release/version field only.
Keep exact commit SHAs, PRs, and implementation notes in internal notes and verification files.

…

View full docs ↗

Run, debug, monitor, and summarize OpenClaw release CI workflows.

openclawGet→

$ loading_