fp-check

/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?