Mandate Proof of Concept for all vulnerability findings

[valITino]

Summary

This change enforces a mandatory Proof of Concept (PoC) requirement for all vulnerability findings across all assessment templates and the data model. Every vulnerability must now include reproducible steps, exact payloads/commands, raw evidence output, and demonstrated impact before it can be considered a valid finding.

Key Changes

Data Model Updates

• VulnerabilityEntry class (aggregated_payload.py):
  • Added three new fields with detailed descriptions:
    • poc_steps: Ordered list of reproduction steps for independent verification
    • poc_payload: Exact, copy-pasteable payload, command, or HTTP request
    • evidence: Enhanced field description emphasizing concrete, non-theoretical proof
  • Updated class docstring to clarify that findings without reproducible PoC are invalid

Playbook & Template Updates

• claude_playbook.md:

  • Renamed "Phase 3 -- Enumeration" to "Phase 3 -- Enumeration & Exploitation"
  • Added explicit requirement: "Validate every finding with a concrete Proof of Concept (PoC)"
  • Created new dedicated "PoC Requirements" section with:
    • Required PoC elements table (reproduction steps, exact command/payload, raw output, impact demonstration, screenshots)
    • PoC requirements by vulnerability class (SQL injection, XSS, RCE, LFI, SSRF, auth bypass, IDOR, default credentials, security headers, SSL/TLS, information disclosure)
    • Instructions for storing PoC data in AggregatedPayload
    • PoC validation checklist
  • Updated Phase 4 aggregation to require evidence, poc_steps, and poc_payload population
  • Added explicit statement: "A finding without a PoC is not a valid finding"

• All assessment templates (full-pentest.md, full-attack-chain.md, bug-bounty.md, api-security.md, vuln-assessment.md, web-app-assessment.md, network-infrastructure.md, quick-scan.md):

  • Added PoC requirement callouts in Phase 4/Exploitation sections
  • Updated findings sections to mandate PoC inclusion with specific elements (reproduction steps, exact payload, raw evidence, impact proof, screenshots)
  • Added guidance that findings without PoC must be downgraded to "info" severity
  • Included reminders to populate poc_steps, poc_payload, and evidence fields

Agent Updates

• processingagent.md:

  • Added PoC data preservation guidance during deduplication
  • Clarified that when merging duplicate findings, the entry with the most complete PoC data should be retained
  • Added flag for findings with empty PoC fields as likely false positives

• synthesisagent.md:

  • Added PoC validation step to verify all findings with severity > "info" have evidence
  • Implemented automatic downgrade of unvalidated findings to "info" severity with explanatory note
  • Clarified that findings without PoC are not valid

• ingestionagent.md:

  • Added PoC extraction guidance for specific tools (nikto, sqlmap, hydra/medusa)
  • Provided examples of how to populate poc_steps and poc_payload from tool output

Notable Implementation Details

• The PoC requirement is mandatory for all severity levels (critical through low), though findings without PoC can be downgraded to "info" severity rather than discarded
• PoC elements are tool-agnostic and include both automated tool output and manual verification methods (screenshots, HTTP responses)
• The change emphasizes that PoC must be independently reproducible — an administrator not present during testing must be able to confirm the finding using only the provided steps and payload
• Bug bounty and pentest templates explicitly warn that findings without PoC will be rejected by programs/clients
• All templates include consistent guidance on what constitutes valid evidence (raw output, not theoretical descriptions)

https://claude.ai/code/session_01UC8hHFgeUeMFboP3grei4t