Reporting & Disclosure

The most technically brilliant penetration test is worthless if no one acts on it. Findings that can't be understood can't be fixed. Recommendations that aren't prioritized won't be prioritized. The report is the product - it's what the client paid for, and it's what determines whether your work actually makes them more secure. Writing a great pentest report is a skill that separates good testers from great ones.

What a Report Must Accomplish

A pentest report serves three distinct audiences simultaneously:

Executives and decision-makers need to understand business risk without technical jargon. They make budget decisions, approve remediation timelines, and determine risk acceptance. They need: overall risk level, the most serious findings, and business impact in plain language.

Technical teams (developers, sysadmins, architects) need exact reproduction steps, affected components, and specific remediation guidance. They need to understand precisely what was exploited and exactly how to fix it.

Compliance and legal teams may need the report to satisfy audit requirements (PCI-DSS, SOC 2, ISO 27001). They need methodology documentation, scope confirmation, and attestation that testing was authorized.

One document must serve all three. The structure achieves this by separating sections clearly.

Report Structure

Cover Page and Header

At minimum: client name, engagement name, date range of testing, report date, tester name(s) and organization, classification (Confidential - restricted distribution), and version number.

Version tracking matters: reports go through review and client revisions. v1.0 - Initial Draft, v1.1 - Revised per client feedback, v2.0 - Final keeps everyone aligned.

Executive Summary

The first section executives read. Typically 1-3 pages. It must stand alone - an executive should be able to read only this section and understand the risk posture.

Include:

• Engagement overview - what was tested, when, by whom, what methodology was used
• Overall risk rating - a single color/label (Critical / High / Medium / Low) with a brief justification
• Summary of findings - how many findings at each severity level
• Top 3-5 findings - described in business language, not technical jargon
• Positive observations - things the client does well (this matters; clients need balanced feedback)
• Strategic recommendations - high-level direction, not implementation details

Example executive-level finding description:

CRITICAL: Unauthenticated Remote Code Execution on Customer Portal
An attacker without any credentials can execute arbitrary commands as a
system administrator on the server hosting the customer portal, gaining
complete control over the server and access to the customer database
(approximately 2.3M records). This vulnerability requires no special
knowledge to exploit and tools for it are publicly available. Exploitation
was confirmed during testing on [date]. Immediate patching is required.

No mention of CVE numbers, exploit code, or technical detail. Just: what it is, who's affected, what an attacker can do, how hard it is, what to do about it.

Findings Section: The Technical Core

Each finding gets its own entry with a consistent structure:

Finding title: Short, descriptive, specific. "Remote Code Execution via Apache 2.4.49 Path Traversal (CVE-2021-41773)" not "RCE finding #1".

Severity rating: Critical / High / Medium / Low / Informational. Justified, not arbitrary.

CVSS score: A standardized numeric risk score.

Affected component: Specific URL, IP, service, version.

Description: What the vulnerability is. Technical but clear.

Impact: What an attacker can do if they exploit it.

Reproduction steps: Exact steps to reproduce the finding. Screenshots required.

Remediation: Specific, actionable. Not "update your software" but "upgrade to Apache 2.4.51 or later, which patches CVE-2021-41773; references: vendor advisory link."

References: CVE IDs, NVD links, vendor advisories, relevant research.

CVSS: Common Vulnerability Scoring System

CVSS (currently version 3.1, with version 4.0 available) provides a standardized numerical score from 0.0-10.0 for vulnerability severity. Using CVSS ensures consistent, defensible severity ratings that clients and auditors recognize.

CVSS 3.1 Base Score Components

Score Ranges

Scoring Example

Apache CVE-2021-41773 (Path Traversal to RCE):

Attack Vector: Network           (exploitable remotely)
Attack Complexity: Low           (no special conditions)
Privileges Required: None        (no auth needed)
User Interaction: None           (no victim action needed)
Scope: Changed                   (affects multiple components)
Confidentiality: High            (all file system readable)
Integrity: High                  (arbitrary code execution)
Availability: High               (full system compromise)
 
CVSS 3.1 Base Score: 9.8 - CRITICAL

Use the NVD calculator at nvd.nist.gov or first.org/cvss/calculator to score your findings consistently.

Writing Reproduction Steps

Reproduction steps are the most important section for the technical reader. They must be precise enough that a developer or security engineer can reproduce the finding themselves, confirm the fix works after remediation, and understand exactly what happened.

Anatomy of Good Reproduction Steps

## Reproduction Steps
 
**Prerequisites:** Unauthenticated access to https://app.example-target.com
 
1. Intercept an HTTP request to any page on the target using Burp Suite.
 
2. Modify the Host header to: `Host: "><img src=x onerror=alert(1)>`
 
3. Forward the modified request. Observe the reflected XSS executing in
   the response when the browser renders the error page.
 
**Evidence:**
[Screenshot: Burp request with modified host header]
[Screenshot: Browser alert popup showing code execution]
 
**Affected URL:** https://app.example-target.com/ (all pages)
**Parameter:** Host header
**Request:**
 
  POST /login HTTP/1.1
  Host: "><img src=x onerror=alert(1)>
  Content-Type: application/x-www-form-urlencoded
 
  username=test&password=test
 
**Response (excerpt):**
 
  <title>Error - "><img src=x onerror=alert(1)></title>

What makes these steps good:

• Specific tool and version
• Exact request/response with sensitive data redacted
• Screenshot references for each key moment
• Affected URL and parameter clearly identified

What Bad Reproduction Steps Look Like

Reproduction Steps:
Used Burp Suite to find XSS in the login page. The site is vulnerable.

No tool configuration, no specific parameter, no evidence, no reproducibility. Useless.

Screenshots and Evidence

Every finding needs visual evidence. Standards for screenshots:

• Capture the entire browser or terminal window - include the URL bar or command prompt
• Show the payload input and the impact in the same screenshot, or use two linked screenshots
• Timestamp: include system time in screenshots when possible
• Annotate: red boxes or arrows pointing to the critical element help readers understand what they're looking at
• Redact: if screenshots contain real PII, credentials, or business-sensitive data, redact before including in the report

Tools: Flameshot or Spectacle for Linux, ShareX on Windows. For terminal evidence, script (Linux) or a timestamped tmux session capture is more reliable than screenshots.

Executive vs Technical Sections: Side by Side

The same finding, written twice:

Executive version:

An attacker on the internet can take complete control of the customer portal
server without logging in. This server holds the personal and financial
records of all 2.3 million customers. Exploitation requires publicly
available tools and no specialized knowledge. This vulnerability was
confirmed during testing on January 15, 2024.
 
Business risk: Customer data breach, regulatory fines (GDPR, PCI-DSS),
reputational damage. Immediate remediation is required.

Technical version:

CVE-2021-41773 - Apache HTTP Server 2.4.49 Path Traversal and RCE
 
CVSS 3.1: 9.8 (Critical)
Affected: app.example-target.com (Apache/2.4.49, confirmed via banner)
 
Description:
Apache 2.4.49 contains a path normalization flaw that allows an
unauthenticated attacker to traverse outside the document root using
URL-encoded path sequences (../ encoded as %2e%2e/). When mod_cgi is
enabled, this path traversal becomes remote code execution.
 
Reproduction Steps:
1. curl -v --path-as-is https://app.example-target.com/cgi-bin/.%2e/%2e%2e/
   %2e%2e/%2e%2e/bin/sh -d 'echo Content-Type: text/plain; echo; id'
   
2. Observed response:
   uid=33(www-data) gid=33(www-data) groups=33(www-data)
 
[Screenshot evidence attached]
 
Remediation:
Upgrade to Apache 2.4.51 or later. Vendor advisory:
https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-41773
 
If immediate upgrade is not possible: disable mod_cgi, or add "Require all
denied" to all cgi-bin directories as a temporary workaround.

Both are accurate. Neither would work if substituted into the other's section.

Remediation Guidance: Be Specific

"Patch the software" is not remediation guidance. Specific guidance that a developer or administrator can act on:

Reference vendor documentation, CWE IDs (for vulnerability class), and OWASP guides where appropriate.

Responsible Disclosure Etiquette

If you discover vulnerabilities outside an authorized engagement - for example, during authorized testing of one system you discover evidence of a breach, or during bug bounty research - responsible disclosure is the professional standard.

The responsible disclosure process:

1. Document the vulnerability with sufficient evidence to prove it exists
2. Do not exploit further than necessary to demonstrate impact
3. Contact the vendor/organization through their published security contact (security.txt, HackerOne, bug bounty program)
4. Include clear description, reproduction steps, and your contact information
5. Agree on a timeline - industry standard is 90 days from report to public disclosure (Google Project Zero standard)
6. Follow up if you don't hear back within a reasonable time (1-2 weeks)
7. Publish a writeup after the fix is deployed and the agreed disclosure window has passed

What responsible disclosure is not:

• Threatening to publish unless paid (that's extortion)
• Publishing immediately without giving the vendor time to fix
• Sharing the vulnerability with others while the fix is pending
• Exploiting the vulnerability against real users to "prove impact"

Report Quality Checklist

Before delivering a report:

Executive Summary
  [ ] Risk rating is clearly stated and justified
  [ ] All findings summarized in business language
  [ ] Positive observations included
  [ ] Strategic recommendations present
 
Findings
  [ ] Every finding has: title, severity, CVSS score, description, impact, steps, remediation, references
  [ ] Reproduction steps are specific enough to reproduce independently
  [ ] All claims are backed by screenshot evidence
  [ ] Screenshots don't contain unredacted sensitive data
  [ ] Severity ratings are consistent and defensible
 
Remediation
  [ ] All recommendations are specific and actionable
  [ ] References to CVEs, vendor advisories, and CWEs included
  [ ] Short-term workarounds provided where immediate patching isn't possible
 
Format and Delivery
  [ ] Report is encrypted (PDF with password, or encrypted ZIP)
  [ ] Delivered to authorized recipient only
  [ ] Version clearly labeled
  [ ] Report date and testing dates clearly stated
  [ ] Tester and organization information complete

Key Takeaways

• The report is the product. Technical skill without communication skill means findings don't get fixed.
• Executive summary communicates business risk in plain language; technical findings communicate exact reproduction steps and specific remediation.
• CVSS 3.1 provides standardized, defensible severity scoring. Score every finding and justify it.
• Reproduction steps must be precise enough for the client's technical team to independently reproduce and verify fixes.
• Remediation guidance must be specific and actionable - tool commands, code changes, configuration settings - not generic platitudes.
• Responsible disclosure etiquette: 90-day disclosure window, contact through official channels, don't exploit beyond proof of concept.
• Reports are among the most sensitive documents an organization holds. Handle with encryption, restricted distribution, and confirmed deletion.