/common-exploit-verification

name: common-exploit-verification
description: Enforce "No Exploit, No Report" policy with PoC construction standards, false-positive filtering, and evidence collection per vulnerability class across backend, frontend, and mobile. Use when validating security findings, constructing exploit proofs, filtering false positives, or writing pentest findings.
metadata:
  triggers:
    keywords:
    - exploit verification
    - proof of concept
    - PoC
    - false positive
    - validate finding
    - exploit proof
    - pentest finding
    - security evidence

Exploit Verification Standard

**Priority: P0 (CRITICAL)**

Always-Apply Rules

• **No Exploit = No Report**: Finding without reproducible PoC is discarded. No exceptions.
• **No Theoretical Findings**: "This could be exploited if..." → rejected. Demonstrate actual impact.
• **No Tool Output as Evidence**: Scanner output alone insufficient. Manual verification required.

PoC Construction

Every confirmed finding must include all fields:

ID: [unique identifier]
Vulnerability: [CWE-XXX: type name]
Platform: [backend|frontend|mobile-ios|mobile-android]
Component: [file:line or endpoint]
Severity: [Critical|High|Medium|Low] (CVSS: X.X)
OWASP: [mapping — e.g., A03:2021, API1:2023, M4:2024]

-- Proof of Concept --
Preconditions: [required state, auth level, config]
Steps:
1. [exact step with command/payload]
2. [expected vs actual result]
Payload: [exact input — copy-paste ready]
Evidence: [response body, status code, data returned]

-- Impact --
Impact: [what attacker gains — data, access, control]
Blast Radius: [lateral movement, escalation paths]

-- Remediation --
Fix: [specific code change, not generic advice]

Validation Gate

| Result | Action | Criteria | |---|---|---| | ✅ Confirmed | Include in report | PoC reproduces, impact demonstrated | | ⚠️ Conditional | Include with conditions | Requires specific config/timing/race | | ❌ Unconfirmed | **Discard** | Cannot reproduce despite 3 attempts | | 🔄 Degraded | Downgrade severity | Partial impact, mitigating controls exist |

False Positive Filters

See [false-positive-checklist](references/false-positive-checklist.md) for platform-specific filters.

Quick checks before reporting:

• **SAST-only finding**: Is the flagged code actually reachable from user input? Trace full data flow.
• **Scanner noise**: Does the "vulnerability" have compensating controls (WAF, middleware, framework defaults)?
• **Version mismatch**: Is the CVE for a function the project actually uses (reachability analysis)?
• **Client-side only**: Is the "bypass" only client-side while server enforces correctly?

Anti-Patterns

• **No severity inflation**: Missing header ≠ Critical. CVSS score must match demonstrated impact.
• **No duplicate findings**: Same root cause across endpoints = 1 finding with multiple affected components.
• **No remediation without specificity**: "Use parameterized queries" → include the exact code change for the affected file.

References

• [False Positive Checklist](references/false-positive-checklist.md) — platform-specific false positive filters
• [Exploit Playbook](references/exploit-playbook.md) — PoC templates per vulnerability class (backend, frontend, mobile)