Triage Vulnerability Report
Overview
Convert incoming claims into a testable hypothesis tied to an exact product, version, configuration, and asset. Do not reproduce active impact until authorization and the smallest safe validation plan are explicit.
Read references/vulnerability-intake.md for the normalized record.
Workflow
- Preserve the original report and source.
- Normalize identity.
- Record product/component, versions, commit/build/image, dependency identity, advisory/CVE/CWE, endpoints/code paths, deployment/configuration, and affected assets.
- Extract the claim.
- State attacker position, prerequisites, input, security boundary crossed, result, impact, and supplied reproduction.
- Grade evidence.
- Separate scanner matching, vulnerable-code presence, reachability, successful reproduction, external advisory, and speculation.
- Record logs, requests/responses, traces, screenshots, code, and environment details.
- Check authoritative context.
- Use vendor advisories, source/release history, OSV/ecosystem advisories, CISA KEV, and current disclosure state; date lookups.
- Route ownership.
- Use Codex Security for repository/diff scanning or attack-path work when available.
- Route to vulnerability validation for a supplied claim and to the owning stack for remediation only after acceptance criteria are clear.
- Define immediate action.
- Identify exposed assets, reversible mitigations, missing evidence, safe validation, and disclosure/notification needs.
Output
Return normalized identity, claim, evidence grade, asset applicability, duplicates/advisories, urgency, validation plan, and owner.
1---2name: triage-vulnerability-report3description: Triage a vulnerability report, scanner result, advisory, CVE, PoC, bug bounty, ticket, or researcher note. Use when affected versions, credibility, prerequisites, evidence, applicability, validation, and exposure must be established.4---56# Triage Vulnerability Report78## Overview910Convert incoming claims into a testable hypothesis tied to an exact product, version, configuration, and asset. Do not reproduce active impact until authorization and the smallest safe validation plan are explicit.1112Read [references/vulnerability-intake.md](references/vulnerability-intake.md) for the normalized record.1314## Workflow15161. Preserve the original report and source.172. Normalize identity.18 - Record product/component, versions, commit/build/image, dependency identity, advisory/CVE/CWE, endpoints/code paths, deployment/configuration, and affected assets.193. Extract the claim.20 - State attacker position, prerequisites, input, security boundary crossed, result, impact, and supplied reproduction.214. Grade evidence.22 - Separate scanner matching, vulnerable-code presence, reachability, successful reproduction, external advisory, and speculation.23 - Record logs, requests/responses, traces, screenshots, code, and environment details.245. Check authoritative context.25 - Use vendor advisories, source/release history, OSV/ecosystem advisories, CISA KEV, and current disclosure state; date lookups.266. Route ownership.27 - Use Codex Security for repository/diff scanning or attack-path work when available.28 - Route to vulnerability validation for a supplied claim and to the owning stack for remediation only after acceptance criteria are clear.297. Define immediate action.30 - Identify exposed assets, reversible mitigations, missing evidence, safe validation, and disclosure/notification needs.3132## Output3334Return normalized identity, claim, evidence grade, asset applicability, duplicates/advisories, urgency, validation plan, and owner.