reporting

Security Reporting

End-to-end pentest reporting for web and application security engagements -- from data gathering through structured report generation. This skill integrates deeply with elliot's data layer to produce comprehensive, evidence-backed deliverables aligned with OWASP Testing Guide and PTES reporting standards.

Why This Matters

The report is the only artifact the client keeps. Every vulnerability discovered, every technique attempted, every chain identified -- it all means nothing if the report is unclear, incomplete, or poorly structured. A good report drives remediation. A bad report gets filed and forgotten.

Report Lifecycle

Data Gathering --> Finding Prioritization --> Report Structure --> Writing --> Quality Review --> Delivery

Every phase draws on elliot's data layer. Skip nothing.

Phase 1 -- Data Gathering

Before writing a single line, collect all engagement data from elliot's trackers.

Vulnerability Data

# Full findings summary -- severity counts, status breakdown
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" summary

# All findings with details
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" list

# Search for specific finding types
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" search sqli
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" list --severity CRITICAL
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" list --type xss

# Export findings as formatted HTML
node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" html

Testing Coverage

# Technique coverage summary -- tools used, results, gaps
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" summary

# Full coverage analysis -- what was tested, what was not
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" coverage

# All tool reports generated during the engagement
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" reports

# Export techniques as formatted HTML
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" html

# Search for specific technique results
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" list --result success
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" list --result blocked

Exploit Chains

# Detect exploit chains from combined findings
node "${CLAUDE_PLUGIN_ROOT}/scripts/chain-detector.js"

# Check if a specific finding participates in chains
node "${CLAUDE_PLUGIN_ROOT}/scripts/chain-detector.js" check f-001

# View chain rule glossary
node "${CLAUDE_PLUGIN_ROOT}/scripts/chain-detector.js" glossary

Chain detection uses 11 built-in rules that match finding combinations (e.g., SSRF + cloud metadata = cloud credential theft, SQLi + file read = source code disclosure). Chains elevate the severity of their component findings and MUST be documented in the report.

Campaign Metadata

# Campaign state -- phases, steps, progress, blockers
node "${CLAUDE_PLUGIN_ROOT}/scripts/session-state.js" show

# Current scan profile (loud/normal/stealth/paranoid)
node "${CLAUDE_PLUGIN_ROOT}/scripts/scan-profile.js" show

Target Context

# Target intelligence gathered during the engagement
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" summary

# All intel for a specific target
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" show example.com

# Intel by category
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" list --category tech-stack
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" list --category defense
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" list --category credential

Hexstrike Report Tools

Load: ToolSearch -> select:mcp__hexstrike-ai__create_vulnerability_report

Use create_vulnerability_report for formatted individual vulnerability documentation via Hexstrike.

Load: ToolSearch -> select:mcp__hexstrike-ai__create_scan_summary

Use create_scan_summary to consolidate multiple tool runs into a unified summary.

Load: ToolSearch -> select:mcp__hexstrike-ai__format_tool_output_visual

Use format_tool_output_visual to format raw tool output for inclusion in reports.

Phase 2 -- Finding Prioritization

After gathering data, prioritize findings for the report. This determines report structure and emphasis.

Severity Classification

Use CVSS 3.1 base scores for technical precision. Map to qualitative ratings:

| Severity | CVSS Range | Characteristics | Report Priority | |----------|-----------|-----------------|-----------------| | Critical | 9.0 - 10.0 | RCE, full DB access, payment compromise, pre-auth admin takeover | Lead the report, executive summary highlight | | High | 7.0 - 8.9 | Auth bypass, IDOR with sensitive data, SQLi with data access | Second tier, individual writeups | | Medium | 4.0 - 6.9 | Stored XSS, info disclosure, missing rate limits, CSRF | Grouped by category, standard writeups | | Low | 0.1 - 3.9 | Reflected XSS requiring interaction, minor info leak, verbose errors | Grouped, abbreviated writeups | | Informational | 0.0 | Best practices, hardening suggestions, version disclosure | Table format, no individual writeups |

See references/finding-writeup.md for CVSS vector string construction.

Chain Elevation

When the chain detector identifies exploit chains, elevate the severity of the chain as a whole:

• Document the chain as a separate finding with its own ID
• Chain severity is typically one level above the highest component finding
• Reference component finding IDs in the chain writeup
• Include the full attack path: entry point -> pivots -> objective

Risk Matrix

Map findings to business impact dimensions:

| Dimension | What to Assess | Example | |-----------|---------------|---------| | Financial | Payment manipulation, fraud potential, regulatory fines | SQLi on payment DB = potential PCI breach | | Data | PII exposure, data breach potential, record counts | IDOR exposing 50K user records | | Availability | DoS potential, service disruption, recovery time | ReDoS on login form = full app lockout | | Reputation | Defacement, customer-facing impact, media risk | Stored XSS on public-facing pages | | Compliance | Regulatory violation, audit failure | Missing HTTPS = PCI-DSS failure |

Phase 3 -- Report Structure

Choose the appropriate report type based on the engagement and audience.

Report Types

| Report Type | Audience | When to Use | Template | |-------------|----------|-------------|----------| | Executive Summary | C-suite, board, non-technical stakeholders | Every engagement | references/executive-summary.md | | Full Technical Report | Development team, security team, sysadmins | Standard pentest deliverable | references/report-templates.md | | Remediation Plan | Development team, project managers | When client requests actionable fix list | references/remediation-guidance.md | | Retest Report | Security team, compliance | After remediation, verifying fixes | references/report-templates.md | | Finding Writeup | Bug bounty, individual vuln documentation | Per-finding documentation | references/finding-writeup.md |

Report Output Location

Reports are written to the project directory under reports/:

reports/
  executive-summary-<target>-<YYYYMMDD>.md
  technical-report-<target>-<YYYYMMDD>.md
  remediation-plan-<target>-<YYYYMMDD>.md
  retest-report-<target>-<YYYYMMDD>.md
  evidence/
    screenshots/          # Annotated screenshots
    requests/             # HTTP request/response pairs
    tool-output/          # Formatted tool output
  findings-export.html    # From findings-tracker.js html
  techniques-export.html  # From techniques-tracker.js html

Phase 4 -- Writing

Full Technical Report Structure

Follow this structure for the primary deliverable. See references/report-templates.md for the complete template.

1. Cover Page
2. Table of Contents
3. Executive Summary (1-2 pages max)
4.