security-triage

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

Updated Jun 19, 2026
One-click install
npx skills add https://github.com/AmirulAndalib/Vilvona-AI --skill security-triage-amirulandalib
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: security-triage
Source: https://github.com/AmirulAndalib/Vilvona-AI/tree/main/.agents/skills/security-triage
Command: npx skills add https://github.com/AmirulAndalib/Vilvona-AI --skill security-triage-amirulandalib

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: Verifies whether a bug affects the latest shipped tag or npm release before closing, using git tags, npm version checks, and fix-commit provenance. - Trust-Model Scoping: Evaluates reports against SECURITY.md boundaries to distinguish real boundary bypasses from out-of-scope local same-user or prompt-injection findings. - Maintainer-Ready Responses: Drafts one firm, specific close or narrow comment per advisory, copies it to the clipboard, and separates optional hardening notes from closure rationale. - Use Case: A maintainer receives a new GHSA claiming a workspace-memory injection bug; the skill walks through reading the advisory, checking shipped tags, confirming the trust-model scope, and drafting a single public-safe reply. ## Quick Start Ask the assistant to triage a specific OpenClaw GHSA advisory and draft a maintainer-ready response with shipped-release 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 SECURITY.md, fetch the GHSA body via the GitHub API, inspect the implicated code paths, and verify whether the latest shipped tag or npm release is affected. Close only if the report is a duplicate, invalid against shipped behavior, out of scope, or fixed before any affected release.

When should a GHSA be closed as out of scope?

Close as out of scope when the prerequisite attacker state is already inside trusted host, local, plugin, or operator boundaries documented in SECURITY.md. Same-host same-user process access and trusted workspace-memory flows are typically out of scope unless they cross a documented boundary.

Does a fix on the main branch justify closing a security advisory?

No. A fix on main that is unreleased is usually not a close. If the latest shipped tag or npm release is still affected, keep the advisory open until the fix is published with the correct status.

What details should be kept out of public GHSA advisory text?

Keep raw commit hashes, PR numbers, and fix-mechanism explanations out of public advisory text. Use only the patched release version field, and keep GHSA ids out of changelogs and release notes unless explicitly requested.

How should hardening suggestions be handled during advisory triage?

Separate hardening from vulnerability status and phrase it as not required for closure. Suggest hardening only when it is concrete, low-risk, and preserves intended maintainer and operator workflows without changing the documented trust boundary.