Validate Vulnerability
Overview
Prove or refute the narrow claim with the least invasive reproduction. Separate vulnerable code or package presence from reachability, controllability, boundary crossing, and demonstrated impact.
Read references/validation-evidence.md for proof levels and controls.
Workflow
- Confirm authorization and exact target/build/configuration.
- State the hypothesis.
- Define attacker position, controlled input, preconditions, code/endpoint, expected security property, and observable violation.
- Establish controls.
- Prepare a known-vulnerable or claimed build, fixed/patched or negative build, baseline input, and minimally changed trigger when practical.
- Trace reachability.
- Show how input reaches the affected component and whether authentication, feature flags, deployment topology, sanitization, mitigations, or dead code block it.
- Use Codex Security for repository attack-path analysis when appropriate.
- Reproduce minimally.
- Prefer harmless markers, bounded data, synthetic accounts, and local fixtures.
- Stop before destructive impact, persistence, unrelated data access, lateral movement, or instability beyond scope.
- Capture evidence.
- Record request/input, response/output, traces/logs, process or state change, exact tool/version, timestamps, cleanup, and retest.
- Classify.
- Validated exploitable, validated but constrained, vulnerable component present but not reachable, false positive for this target, fixed, or unresolved.
Output
Return hypothesis, environment, controls, reachability, smallest safe proof, impact boundary, classification/confidence, cleanup, and remediation/retest criteria.
1---2name: validate-vulnerability3description: Validate a vulnerability claim in an authorized environment. Use for scanner candidates, advisories, CVEs, PoCs, source concerns, configuration weaknesses, or regressions with a safe proof and controls.4---56# Validate Vulnerability78## Overview910Prove or refute the narrow claim with the least invasive reproduction. Separate vulnerable code or package presence from reachability, controllability, boundary crossing, and demonstrated impact.1112Read [references/validation-evidence.md](references/validation-evidence.md) for proof levels and controls.1314## Workflow15161. Confirm authorization and exact target/build/configuration.172. State the hypothesis.18 - Define attacker position, controlled input, preconditions, code/endpoint, expected security property, and observable violation.193. Establish controls.20 - Prepare a known-vulnerable or claimed build, fixed/patched or negative build, baseline input, and minimally changed trigger when practical.214. Trace reachability.22 - Show how input reaches the affected component and whether authentication, feature flags, deployment topology, sanitization, mitigations, or dead code block it.23 - Use Codex Security for repository attack-path analysis when appropriate.245. Reproduce minimally.25 - Prefer harmless markers, bounded data, synthetic accounts, and local fixtures.26 - Stop before destructive impact, persistence, unrelated data access, lateral movement, or instability beyond scope.276. Capture evidence.28 - Record request/input, response/output, traces/logs, process or state change, exact tool/version, timestamps, cleanup, and retest.297. Classify.30 - Validated exploitable, validated but constrained, vulnerable component present but not reachable, false positive for this target, fixed, or unresolved.3132## Output3334Return hypothesis, environment, controls, reachability, smallest safe proof, impact boundary, classification/confidence, cleanup, and remediation/retest criteria.
gaelic-ghost