security-triage

Triage OpenClaw security advisories and GHSA reports with shipped-tag verification.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/JEROME-PRAKASH-L/openclaw --skill security-triage-jerome-prakash-l
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: security-triage
Source: https://github.com/JEROME-PRAKASH-L/openclaw/tree/main/.agents/skills/security-triage
Command: npx skills add https://github.com/JEROME-PRAKASH-L/openclaw --skill security-triage-jerome-prakash-l

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Maintainers reviewing GitHub Security Advisories (GHSA) risk over-closing real vulnerabilities or shipping unnecessary regressions without a consistent, evidence-based triage process tied to shipped releases and the documented trust model. ## Core Features & Use Cases - Evidence-Based Close Decisions: Applies a strict close bar covering duplicates, invalid reports, out-of-scope trust-model cases, and pre-release fixes, verified against shipped tags and npm releases. - Trust-Model Review Method: Checks each advisory against SECURITY.md scope, shipped behavior, exploit paths, and functional tradeoffs before recommending close, keep open, or narrow. - Maintainer-Ready Responses: Drafts one detailed close comment per advisory with exact code refs, release facts, and optional hardening notes, then copies it to the clipboard for posting. - Use Case: A maintainer receives a new GHSA claiming a workspace memory injection bug. The Skill walks through reading the advisory via the GitHub API, verifying whether the latest shipped tag is affected, checking the SECURITY.md trust boundary, and drafting a firm, specific close or keep-open reply. ## Quick Start Ask the assistant to triage a specific OpenClaw GHSA advisory by its ID and draft a maintainer-ready response with shipped-tag evidence.

Frequently Asked Questions about security-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a GitHub Security Advisory before closing it?

Read the GHSA body via the GitHub API, inspect the implicated code paths, and verify whether the latest shipped tag or npm release is still affected. Close only if it is a duplicate, invalid against shipped behavior, out of scope under SECURITY.md, or fixed before any affected release.

When should a security advisory stay open even if main is fixed?

A fix on the main branch alone is not enough to close. If the latest shipped tag or published npm release still contains the bug, the advisory stays open until the fix is released or published with the correct status.

What vulnerability reports are out of scope under a trust model?

Reports requiring attacker-controlled trusted local state, same-host same-user process access, or trusted workspace memory reindexing itself are typically out of scope. SECURITY.md defines which classes are excluded or treated as hardening-only.

How do I verify which release contains a security fix?

Use git tag --contains <fix-commit> to find tags including the fix, git tag --sort=-creatordate to list recent releases, and npm view to check the published version. Compare these against the affected versions in the advisory.

Should hardening changes be required to close a GHSA?

No. Hardening is separate from vulnerability status and should be framed as optional follow-up, not a closure requirement. Only propose it when it is concrete, low-risk, and preserves intended user workflows.