Reporting — The Actual Deliverable

pentest1-4 through pentest1-8 produced real, confirmed findings. None of that has any value to the client until it's written down clearly, prioritized honestly, and communicated to the right audience. This chapter is about that final, essential step.

The Report Is the Product

The exploitation itself leaves no lasting artifact — once testing ends, everything that happened during pentest1-4 through pentest1-8 only continues to exist for the client in one form: the written report. A pentest that finds real, serious vulnerabilities but produces a poor report has, in a real and practical sense, failed to deliver the thing the client actually paid for.

This closes a loop opened all the way back in pentest1-2: the engagement began with a written document — the scope agreement and Rules of Engagement — and it ends with a written document, the report. Both are the tangible, contractual artifacts of the entire engagement; the actual testing happens in between them, but the client's lasting deliverable is written on both ends.

Two Audiences, Two Sections

Both sections are necessary, for symmetric reasons: a report with only technical detail rarely secures the budget or priority needed from people who don't have time to parse it; a report with only an executive summary gives the engineers who need to fix each issue nothing concrete to act on. A good report serves both audiences without forcing either one to wade through content meant for the other.

CVSS — Common Vulnerability Scoring System

Not every finding deserves equal urgency, and CVSS is the standardized way to communicate that consistently. It scores a vulnerability across several metrics — attack vector, attack complexity, privileges required, user interaction needed, and impact on confidentiality/integrity/availability — combining them into a 0–10 score and a Low/Medium/High/Critical rating. Standardization matters here for the same reason pentest1-3's own frameworks mattered: a "Critical" finding should mean roughly the same thing regardless of which tester or firm wrote the report.

Remediation Guidance

A finding without a fix isn't actionable — the report needs concrete remediation guidance, not just a description of the weakness. This is where this course's own "toolkit" chapters (pentest1-6) pay off a second time, now applied to the defensive side rather than the offensive matching side: a SQL injection finding's remediation should point specifically at sqli1's own parameterized-query material; an XSS finding at xss1's own output-encoding material; a weak-authentication finding at bc1's own material on password hashing and MFA. Remediation guidance should generally be ordered by CVSS severity — though a realistic, useful report is honest that both severity and ease of fix genuinely matter to a client's actual remediation roadmap, not severity alone.

Hands-On Exercises