Pentest Reporting (REPORT phase — the end that makes the work count)

Overview

A vulnerability nobody fixes isn't security. This phase converts raw findings into a report that engineers can act on and leaders can prioritize: consistent severity, crisp reproduction, honest impact, concrete fixes, and tracked closure.

Core principle: Write for two readers at once — an executive who needs risk and priority, and an engineer who needs exact steps to reproduce and fix.

Structure of a good report

1. Executive summary — plain-language risk posture, top 3–5 risks, overall verdict. No jargon.
2. Scope & methodology — what was tested, environment, dates, what was out of scope.
3. Findings — one entry each (see template), ordered by severity.
4. Remediation roadmap — prioritized fix list with effort estimates.
5. Retest results — status per finding after fixes (Open / Fixed / Risk-accepted).
6. Appendix — tools, raw evidence, references.

Finding template (use for every issue)

Title:        <Concise, e.g. "IDOR in /api/invoices exposes other users' billing">
Severity:     Critical | High | Medium | Low | Info   (CVSS x.x — vector)
Affected:     <endpoint / file:line / component>
Summary:      <1–2 sentences: what's wrong and why it matters>
Reproduction: <numbered, copy-pasteable steps / exact request>
Evidence:     <response excerpt / screenshot, real data redacted>
Impact:       <business consequence: data exposed, money, accounts, scope>
Remediation:  <specific fix, link to security-hardening pattern>
Status:       Open | Fixed (retested <date>) | Risk-accepted

Severity & CVSS

Score consistently so priorities are defensible. See references/cvss-and-template.md for the CVSS v3.1 metrics, a base-score cheat sheet, and a full report skeleton.

Adjust for business context: a "Medium" on the payment path may be a "High" for you.

Writing rules

• Reproducible or it didn't happen — steps a developer can paste and rerun.
• Impact in business terms — "any user can read all invoices," not "missing authz check."
• One fix per finding — point to the exact security-hardening pattern.
• No fear, no fluff — accurate severity; over-hyping burns trust, under-hyping gets ignored.
• Redact real data in evidence.

Retest & closure

For each fixed finding: rerun the original PoC, record pass/fail and date, set status. The report isn't done until every High+ is Fixed or explicitly Risk-accepted by an owner.

Hand-off

Findings come from all FIND/EXPLOIT skills; fixes from security-hardening; this skill packages and tracks them to closure (retest each High+ before marking it fixed).

Common mistakes

• Dumping scanner output as "the report" — triage, dedupe, and verify first.
• Severity by gut feel — use CVSS + business context so priorities hold up.
• Reproduction steps that only you can follow — write for a stranger.
• No retest — "fixed" without rerunning the exploit is a guess.