FP Check

​

Overview

​

Verification Paths

​

Standard Path

• Clear, specific vulnerability claim (not vague or ambiguous)
• Single component — no cross-component interaction
• Well-understood bug class (buffer overflow, SQL injection, XSS, etc.)
• No concurrency or async involved
• Straightforward data flow from source to sink

1. Data flow tracing
2. Exploitability proof
3. Impact assessment
4. PoC sketch (pseudocode)
5. Devil’s advocate spot-check (7 questions)
6. Gate review (6 mandatory gates)

​

Deep Path

• Ambiguous claim with multiple interpretations
• Cross-component bug path (data flows through 3+ modules)
• Race conditions, TOCTOU, or concurrency
• Logic bugs without a clear spec to verify against
• Standard verification was inconclusive
• User explicitly requests full verification

1. Claim analysis and bug class classification
2. Context extraction (execution, caller, architectural, historical)
3. Phase 1: Data flow analysis (trust boundaries, API contracts, environment protections)
4. Phase 2: Exploitability verification (attacker control, bounds proofs, race proofs)
5. Phase 3: Impact assessment (real security impact vs operational robustness)
6. Phase 4: PoC creation (pseudocode, executable, unit test, negative PoC)
7. Phase 5: Devil’s advocate review (13 questions with LLM self-check)
8. Gate reviews: Six mandatory gates before any verdict

​

Components

​

Skills

​

Agents

​

Hooks

​

Installation

/plugin install fp-check

​

Triggers

• “Is this bug real?” / “Is this a true positive?”
• “Is this a false positive?” / “Verify this finding”
• “Check if this vulnerability is exploitable”

​

Step 0: Understand the Claim

• Exact vulnerability claim: e.g., “heap buffer overflow in parse_header() when content_length exceeds 4096”
• Alleged root cause: e.g., “missing bounds check before memcpy at line 142”
• Supposed trigger: e.g., “attacker sends HTTP request with oversized Content-Length header”
• Claimed impact: e.g., “remote code execution via controlled heap corruption”
• Threat model: What privilege level? Is it sandboxed? What can the attacker already do?
• Bug class: Memory corruption, injection, logic bug, race condition, etc.
• Execution context: When and how is this code path reached?
• Caller analysis: What functions call this code and what constraints do they impose?
• Historical context: Any recent changes, known issues, or previous security reviews?

​

Standard Verification Workflow

​

Step 1: Data Flow

• Map trust boundaries crossed (internal/trusted vs external/untrusted)
• Identify all validation and sanitization between source and sink
• Check API contracts — many APIs have built-in bounds protection
• Check for environmental protections (compiler, runtime, OS, framework)

​

Step 2: Exploitability

• Attacker control: Prove the attacker controls data reaching the vulnerable operation
• Bounds proof: For integer/bounds issues, create an explicit algebraic proof
• Race feasibility: For race conditions, prove concurrent access is actually possible

​

Step 3: Impact

• Distinguish real security impact (RCE, privesc, info disclosure) from operational robustness issues (crash recovery)
• Distinguish primary security controls from defense-in-depth

​

Step 4: PoC Sketch

Data Flow: [Source] → [Validation?] → [Transform?] → [Vulnerable Op] → [Impact]
Attacker controls: [what input, how]
Trigger: [pseudocode showing the exploit path]

​

Step 5: Devil’s Advocate Spot-Check

1. Am I seeing a vulnerability because the pattern “looks dangerous” rather than because it actually is?
2. Am I incorrectly assuming attacker control over trusted data?
3. Have I rigorously proven the mathematical condition for vulnerability can occur?
4. Am I confusing defense-in-depth failure with a primary security vulnerability?
5. Am I hallucinating this vulnerability? LLMs are biased toward seeing bugs everywhere.

6. Am I dismissing a real vulnerability because the exploit seems complex or unlikely?
7. Am I inventing mitigations or validation logic that I haven’t verified in the actual source code?

​

Step 6: Gate Review

​

Example: True Positive

void parse_header(char* header) {
    char buffer[4096];
    int content_length = atoi(get_header_value(header, "Content-Length"));
    memcpy(buffer, header, content_length);  // Line 142
}

• Source: HTTP request header (attacker-controlled)
• Sink: memcpy() at line 142
• Trust boundary: External network → internal buffer
• Validation: None found between atoi() and memcpy()
• API contract: memcpy() has no bounds protection (memcpy_s would prevent this)

• Attacker control: YES — attacker sends HTTP header with Content-Length: 10000
• Bounds proof: content_length = 10000, sizeof(buffer) = 4096, 10000 > 4096 → overflow confirmed
• No upstream validation prevents large values

• Real security impact: YES — heap buffer overflow enables RCE
• Not defense-in-depth: This is a primary boundary

Send HTTP request:
POST / HTTP/1.1
Content-Length: 10000

[10000 bytes of data]

→ content_length = 10000
→ memcpy(buffer[4096], header, 10000)
→ 5904 byte overflow
→ heap corruption
→ RCE

1. Pattern bias? NO — mathematically proven overflow
2. Trust assumption? NO — HTTP headers are attacker-controlled
3. Math proof? YES — explicit bounds proof above
4. Defense-in-depth? NO — primary boundary
5. Hallucination? NO — code analysis confirmed

• Gate 1 (Control): PASS — attacker controls Content-Length header
• Gate 2 (Reachability): PASS — any HTTP POST triggers this path
• Gate 3 (Validation): FAIL — no validation, vulnerability confirmed
• Gate 4 (API): FAIL — memcpy() has no bounds protection
• Gate 5 (Environment): FAIL — no compiler/OS protection for this pattern
• Gate 6 (Impact): PASS — RCE is real security impact

​

Example: False Positive

def get_user(username):
    query = "SELECT * FROM users WHERE username = ?"
    return db.execute(query, (username,))

• Source: User-supplied username (attacker-controlled)
• Sink: db.execute()
• Validation: None visible in this function
• API contract: Parameterized query — ? placeholder with separate parameters

• Attacker control: YES — attacker can provide any username
• BUT: API contract check reveals parameterized queries prevent injection
• The ? placeholder and separate (username,) tuple mean the database driver escapes the value

• No exploitation possible due to API protection

• Gate 1 (Control): PASS — attacker controls username
• Gate 2 (Reachability): PASS — code is called on every login
• Gate 3 (Validation): PASS — no explicit validation needed
• Gate 4 (API): PASS — Parameterized queries prevent SQL injection by design
• Gate 5 (Environment): PASS — database driver escapes parameters
• Gate 6 (Impact): N/A — no exploitation possible

​

Rationalizations to Reject

​

Batch Triage

1. Run Step 0 for all bugs first — restating each claim often collapses obvious false positives immediately
2. Route each bug independently (some may be standard, others deep)
3. Process all standard-routed bugs first, then deep-routed bugs
4. After all bugs are verified, check for exploit chains — findings that individually failed may combine to form a viable attack

​

Final Summary

1. Counts: X TRUE POSITIVES, Y FALSE POSITIVES
2. TRUE POSITIVE list: Each with brief vulnerability description
3. FALSE POSITIVE list: Each with brief reason for rejection

​

Related Skills

• Audit Context Building - Deep context helps verification
• Differential Review - May discover bugs requiring verification