/fp-check

name: fp-check
description: "Run the 6-gate false positive elimination process on the current finding. Usage: /fp-check (run from a target directory with findings)."

/fp-check

Run the full false positive elimination process on the current finding.

Prerequisites

This command expects:

• A finding documented in `targets/<repo>/findings.md`
• A PoC script at `targets/<repo>/poc_<vuln_type>.py`
• The target repo cloned at `targets/<repo>/`

Process

Step 0: Restate the Claim

Before any verification, restate the vulnerability claim in one precise sentence:

CLAIM: <package-name>@<version> has a <vulnerability-type> in <function/file>
       that allows <attacker with X privileges> to <achieve Y impact>
       by <sending Z input>.

If this sentence doesn't make coherent sense, STOP. The finding is likely false.

Gate 1: Process Completeness

Check that all required evidence exists:

• [ ] File path and line number of the vulnerable code
• [ ] Sink identified (the dangerous function call)
• [ ] Source identified (where attacker input enters)
• [ ] Data flow traced (source -> ... -> sink)
• [ ] PoC script exists and has all required sections
• [ ] CWE classification is correct

**FAIL if**: Any of the above is missing or the CWE doesn't match.

Gate 2: Reachability

Verify the attacker can actually reach the vulnerability:

1. Read the source code at the identified entry point 2. Trace every function call from entry to sink 3. Check for authentication requirements on the route/function 4. Verify the attacker controls the data that reaches the sink

# Trace the call chain
grep -n "<entry_function>" targets/<repo>/repo/src/**/*.js
grep -n "<intermediate_function>" targets/<repo>/repo/src/**/*.js
grep -n "<sink_function>" targets/<repo>/repo/src/**/*.js

**FAIL if**: There's no path from external input to the sink, or auth blocks it.

Gate 3: Real Impact

Determine if exploitation has genuine security consequences:

• Is the result a security violation (confidentiality, integrity, availability)?
• Or is it just an error/exception that the application handles gracefully?
• Would a security team investigate if this happened in production?

**FAIL if**: The "impact" is a caught exception, a logged warning, or behavior within intended limits.

Gate 4: PoC Validation

Execute the PoC 3 times:

# Run 1
python3 targets/<repo>/poc_<vuln_type>.py
echo "Exit code: $?"

# Run 2
python3 targets/<repo>/poc_<vuln_type>.py
echo "Exit code: $?"

# Run 3
python3 targets/<repo>/poc_<vuln_type>.py
echo "Exit code: $?"

All 3 runs must:

• Exit with code 0 (success)
• Produce the claimed evidence
• Show consistent results

**FAIL if**: Any run fails or produces different results. 3 failures = FALSE POSITIVE.

Gate 5: Math/Bounds Analysis

For DoS vulnerabilities only:

# Time the execution with increasing input sizes
time python3 -c "
import time
# Test with input size N=10, 20, 30, 40
for n in [10, 20, 30, 40]:
    start = time.time()
    # Run the vulnerable function with input of size n
    elapsed = time.time() - start
    print(f'N={n}: {elapsed:.3f}s')
"

• ReDoS: Must show exponential growth (not linear)
• Recursion: Must show OOM/crash (not caught RangeError)
• Decompression: Must show disproportionate output size
• Entity expansion: Must show exponential memory growth

**FAIL if**: Growth is linear, or errors are caught gracefully.

Gate 6: Environment Check

# Check latest version
npm view <package> version 2>/dev/null
pip3 index versions <package> 2>/dev/null

# Check for runtime protections in the actual code
grep -rn "sanitize\|validate\|escape\|normalize" targets/<repo>/repo/src/
grep -rn "middleware\|interceptor\|filter" targets/<repo>/repo/src/

• Is this the latest version?
• Are there runtime protections we missed?
• Is this default config or a custom insecure config?

**FAIL if**: Already patched, or runtime/framework blocks the attack.

13-Item Checklist

Run through all 13 items (see Validator agent instructions for full list). Any "yes" answer requires investigation before proceeding.

Devil's Advocate

Answer all 7 self-check questions honestly:

1. Am I seeing a vulnerability because the pattern "looks dangerous"? 2. Am I incorrectly assuming attacker control over trusted data? 3. Am I hallucinating this? 4. Am I dismissing a real vulnerability because the exploit seems complex? 5. Am I inventing mitigations I haven't verified in source code? 6. Did I actually read the README/docs? 7. Did I verify the EXACT version?

Final Verdict

FP-CHECK RESULT: <TRUE POSITIVE / FALSE POSITIVE>

Gate 1 (Process):     PASS / FAIL - <reason>
Gate 2 (Reachability): PASS / FAIL - <reason>
Gate 3 (Real Impact):  PASS / FAIL - <reason>
Gate 4 (PoC):         PASS / FAIL - <runs passed>/<3>
Gate 5 (Math):        PASS / FAIL / N/A - <data>
Gate 6 (Environment):  PASS / FAIL - <reason>

Checklist flags: <any items that flagged>
Devil's advocate: <any concerns raised>

VERDICT: <CONFIRMED / FALSE_POSITIVE / NEEDS_MORE_INFO>