Ghost Validate

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.