Documentation & Reporting¶

Finding the vuln is only half the job
If you can't communicate what you found and how to fix it , your work has zero value

Translation of technical findings into actionable business intelligence — that's the difference between a report that gets read and one that gets filed in /dev/null

Report Structure¶

Every finding follows this structure — consistent , repeatable , useful

1. Executive Summary¶

High-level overview for people who sign checks

• Business impact in plain language
• Risk level (Critical / High / Medium / Low)
• Number of findings by severity
• Quick wins that can be fixed immediately

No technical jargon here
Your CTO needs to understand the risk without a comp sci degree

2. Technical Details¶

The actual meat for the engineers who have to fix this shit

• Vulnerability type and CWE/CVE reference
• Affected endpoints , versions , configurations
• Step-by-step reproduction
• Environment context (when discovered , what tools used)

3. Proof of Concept¶

Show , don't tell

# Example PoC format — commands that reproduce the finding
# Include exact requests , payloads , and output
curl -X POST https://target.com/api/auth \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "admin123"}' \
  -v

# Response showing the 200 OK when it should be 401
< HTTP/1.1 200 OK
< {"token": "eyJhbGciOiJIUzI1NiIs..."}

4. Evidence¶

Screenshots , logs , timestamps — everything that proves the finding exists

# Screenshot organization
screenshots/
├── recon/
│   ├── subdomain-enumeration.png
│   └── open-ports.png
├── exploitation/
│   ├── sql-injection-proof.png
│   └── shell-access.png
└── reporting/
    └── cvss-calculator.png

5. Remediation¶

Don't just complain — offer solutions

• Immediate — stop the bleeding (disable endpoint , rotate keys , block IP)
• Short-term — patch , configure WAF rules , fix input validation
• Long-term — architectural changes , security training , SDLC improvements

6. References¶

• CVE numbers
• OWASP categories
• Vendor advisories
• Related research

Remediation Guidance Categories¶

Ethical Disclosure¶

Responsible disclosure isn't optional

• Set expectations — tell them when the report is coming
• Give time — industry standard is 90-120 days for remediation
• Coordinate — involve all affected parties
• Professional always — no shaming , no public disclosure without consent

flowchart LR
    A[Discovery] --> B[Notify Vendor]
    B --> C{Acknowledged?}
    C -->|Yes| D[Provide Details]
    D --> E[Wait for Fix]
    E --> F{Timeline Met?}
    F -->|Yes| G[Public Disclosure]
    F -->|No| H[Coordinate Extension]
    H --> E
    C -->|No| I[Escalate]
    I --> J[CISA/CERT]
    J --> D

Tools for Report Generation¶

# Serpico — open source report generation
# Dradis — collaboration + reporting
# PwnDoc — pentest documentation with templates

# Markdown to PDF conversion
pandoc report.md -o report.pdf --from markdown --to pdf

# Template-based HTML report generation
# Never start from scratch — always use templates

What Makes a Good Report¶

• Reproducible — anyone with the same access should be able to replicate
• Prioritized — not every finding is P1 , and pretending it is dilutes the real criticals
• Actionable — the fix should be clear enough that a junior dev can implement it
• Honest — if you're not sure about something , say so Faking confidence burns credibility

Bad reports get ignored
Good reports get things fixed
Great reports get you rehired