Security Finding Validation
Determine whether a security finding is a true positive or false positive. Produce a determination with supporting evidence.
Input
The user provides a finding as a file path or pasted text. If neither is provided, ask for one.
Extract: vulnerability class, specific claim, affected endpoint, code location, and any existing validation evidence.
Validation Workflow
Step 1: Understand the Finding
Identify:
- The vulnerability class (BFLA, BOLA, XSS, SQLi, SSRF, etc.)
- The specific claim being made (what authorization check is missing, what input is unsanitized, etc.)
- The affected endpoint and HTTP method
- The code location
Step 2: Analyze the Source Code
- Read the vulnerable file at the specified line number and all supporting files
- Trace the request flow from route registration through middleware to the handler
- Verify the specific claim — does the code actually lack the described check?
- Look for indirect protections (middleware, helpers, ORM constraints) the scanner may have missed
- Confirm the vulnerable code path is reachable under the described conditions
Step 3: Live Validation (When Available)
If a live instance of the application is accessible and the vulnerability can be confirmed through live interaction, use the proxy skill to confirm exploitability:
- Start reaper proxy scoped to the target domain
- Authenticate (or have the user authenticate) as a legitimate user and capture a valid request to the vulnerable endpoint
- Replay or modify the request to attempt the exploit described in the finding
- Compare the response to expected behavior:
- Does the unauthorized action succeed? (true positive) - Does the server reject it with 401/403/404? (false positive)
- Capture the request/response pair as evidence using
reaper get <id>
Step 4: Make Determination
Classify the finding as one of:
- True Positive: The vulnerability exists and is exploitable. The code lacks the described protection and the endpoint is reachable.
- True Positive (Confirmed): Same as above, plus live testing demonstrated successful exploitation.
- False Positive: The vulnerability does not exist. Provide the specific reason (indirect protection found, code path unreachable, etc.).
- Inconclusive: Cannot determine without additional information. Specify what is needed.
Step 5: Report
Output a summary in the following format:
- Determination: True Positive, False Positive, or Inconclusive
- Confidence: High, Medium, or Low
- Evidence Summary: Key findings from code review and/or live testing
- Code Analysis: Specific lines and logic that support the determination
- Live Test Results (if performed): Request/response pairs demonstrating the behavior
- Recommendation: Fix if true positive, close if false positive, gather more info if inconclusive
Example:
## Validation Result
- **Determination**: True Positive
- **Confidence**: High
- **Evidence**: Handler at routes/transfers.go:142 queries transfers by ID without checking ownership. No middleware or ORM-level constraint enforces user scoping.
- **Recommendation**: Add ownership check — include user_id in the WHERE clause.Step 6: Persist Results
If the finding was provided as a file path, ask the user if they would like to append the validation details to the original finding file. If they agree, append a ## Validation section to the file containing the determination, confidence, evidence summary, and recommendation.
Vulnerability Class Reference
See VULNERABILITY_PATTERNS.md in this skill directory for patterns to look for when validating authorization flaws (BFLA/BOLA/IDOR), injection (SQLi/XSS), and authentication flaws.