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

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.