Pentest Reporter

Pentest Reporter

Scope-only: report output may only contain information covered by the engagement Rules of Engagement. Findings outside scope (even when noticed) go via separate side-channel communication with the customer, not into the main report without explicit sign-off.

When to use

A pentest is done when the report is on paper, not when the testing stops. This skill connects the technical work from recon-agent, web-exploit-triage, exploit-chain, payload-crafter, ad-attacks, and post-exploit to a deliverable the customer can use to fix things, show to auditors, and prioritize internally.

Triggers on:

• A question like "write a pentest report for engagement X", "build the exec summary", "score these findings with CVSS", "build a remediation roadmap", "retest template".
• A bug-bounty submission that needs structure — lower bar than a full pentest report, same discipline.
• A red-team engagement where multiple reports (technical detail + exec summary + detection-gaps report) are needed.
• A retest cycle after an earlier report: per-finding sign-off plus overall attestation.
• A handoff from security-review when a found issue needs a formal finding entry.

When NOT (handoff)

• Active exploitation or PoC building → the relevant pentest skills (exploit-chain, payload-crafter, web-exploit-triage, ad-attacks).
• Internal security-review reporting (not engagement-bound) → security-review. Different audience, different tone.
• Compliance-audit evidence → audit-evidence. Different format, different audience.
• Threat-model delivery → threat-modeler has its own output structure.
• Incident-response reporting → ir-runbook from the blue bundle plus forensics.
• Vulnerability-disclosure coordination (CVD) to upstream vendors → out of scope; needs its own process.

Approach

Seven phases. Phase 2 (finding-template consistency) and phase 4 (CVSS scoring discipline) are the places where reports come apart.

1. Report architecture and audience

A single pentest often delivers two to three report variants for different readers:

• Technical report: complete, with reproduction steps, screenshots, requests/responses. Audience: engineering + security team.
• Executive summary: 2–4 pages, risk-oriented, no technical jargon. Audience: management, compliance, sometimes the customer CISO.
• Remediation roadmap: source-only, sorted by fix priority with deadlines. Audience: product owners, scrum masters.
• Attestation letter (red-team / compliance context): a short confirmation that the engagement took place per RoE, with scope + period + high-level conclusion. Audience: external auditors, customers' customers.

Agreeing the architecture in the kickoff reduces rewrite load. Keep template sets for each type.

Standard report structure (technical):

1. Executive summary (page 1–4)
2. Engagement details (scope, RoE, period, team)
3. Methodology (PTES/OWASP WSTG/MITRE ATT&CK — which frameworks were used)
4. Findings (sorted by severity)
5. Remediation roadmap
6. Retest section (in follow-up engagements)
7. Appendices: tool output, requests/responses, CVSS vector details

2. Finding template (consistent across the report)

Every finding follows the same structure. Consistency keeps the report scannable and audit-compatible.

Required fields:

• Title: descriptive without spoilers. "IDOR in /api/documents/{id} allows document enumeration", not "Critical Security Flaw Found".
• Finding ID: FIND-YYYY-NNN or similar, unique per report.
• Severity: Critical / High / Medium / Low / Informational.
• CVSS v3.1 base score + vector. Optionally CVSS v4.0 alongside (some vendors now ask for it).
• CWE classification and where relevant OWASP Top 10 2021 + OWASP API Top 10 2023 mapping.
• Affected endpoints/components: specific, with paths and parameters.
• Description: what the vulnerability is at conceptual level (2–4 sentences).
• Impact: a concrete scenario the attacker can achieve; quantitative where possible (number of records, which role escalation, business outcome).
• Reproduction steps: numbered, reproducible, with screenshots or request/response pairs. Redacted where PII or production credentials appear. No version-specific exploits against production without explicit sign-off.
• Recommendation: concrete fix direction, with handoff to internal skill ref or framework doc. Not "improve security" — but "parameterize the query with placeholders, example in the appendix".
• References: CWE, OWASP, vendor advisories, CVEs where relevant (always verify against NVD before citing).
• Status: Open / Fixed / Won't Fix (with business-acceptance rationale) / Verified Fixed.

Optional fields for red-team-style engagements:

• MITRE ATT&CK technique IDs the finding covers.
• Detection opportunity: which signal would the blue team have caught (input for the detection engineer).
• Exploitation-chain position: does this finding stand alone, or is it a link in a chain (handoff to exploit-chain work).

3. Executive summary discipline

The exec summary decides whether findings get fixed. Three rules:

• Lead with risk, not technology. "We found that an attacker without authentication could access customer data in 3 of 5 tested systems" is a lead. "We found SQL injection" is not.
• Give numbers. "X critical, Y high, Z medium" plus one or two impactful conclusions. Numbers are verifiable, adjectives are not.
• End with a program-level recommendation, not per-finding. "The biggest risk reduction comes from: (1) MFA roll-out for admin flows, (2) session-token rotation on privilege change, (3) a code-review process for changes to auth middleware."

Executive-friendly: no CVE IDs, no stack traces, no exploit code. Yes: reach, business consequences, time estimate for fixes.

Length: a high-impact engagement may have 3–4 pages of exec summary, a small engagement one page. Longer than 5 is almost always not exec-friendly and should move to the technical report.

4. CVSS scoring discipline

CVSS scoring is where reports lose credibility when it is sloppy.

• Version choice: CVSS v3.1 remains the de facto standard in 2025–2026; NVD publishes both. Use v3.1 as primary, v4.0 optionally alongside (relevant for some vendor programs).
• Calculate the base score strictly via the FIRST calculator, not by gut feel. Document the vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) so readers can verify it themselves.
• Attack Vector (AV): Network / Adjacent / Local / Physical. A pre-auth bug on an internet-exposed surface is AV:N; one that only works via SSH access is AV:L.
• Privileges Required (PR): None / Low / High. "Authenticated" = Low or High depending on role; regular user = Low, admin required = High.
• User Interaction (UI): None / Required. XSS that requires a click is UI:R; SSRF directly is UI:N.
• Scope (S): Unchanged / Changed. A bug that operates outside its security authority's reach (e.g. RCE in container → host) is S:C.
• CIA: the impact triangle in the context of the bug itself, not the whole organization. Be specific.
• Temporal and Environmental optional. NVD publishes Base only; at the report level Temporal (exploit maturity, remediation level) and Environmental (target-specific CIA weights) are extra information the customer can use.

Severity buckets per CVSS range:

• 9.0–10.0 Critical | 7.0–8.9 High | 4.0–6.9 Medium | 0.1–3.9 Low | 0.0 Informational.

Discipline check: could you defend this score publicly? If the vector says "Authenticated RCE pre-auth", something is off.

5. Remediation roadmap

Findings on their own motivate less than a planned order does.

• Per finding: expected effort (S/M/L/XL in sprint units), owner role (frontend / backend / SRE / sec / vendor), target deadline.
• Prioritization matrix: severity × effort. Critical-small-effort first (quick wins), Critical-large-effort in parallel with compensating controls in the meantime, Medium-low-effort batched.
• Compensating-controls bridge: if a fix takes weeks, what can sit in between (WAF rule, feature flag, rate limit)?
• Repetition patterns: if you found five SQL injections across different endpoints, the remediation is not "fix each separately" but "introduce parameterized-query discipline plus a SAST gate that prevents future ones". Name the patterns.

The roadmap lives longer than the report itself; make it trackable (tickets + dashboard), not just text.

6. Retest and sign-off

After remediation comes retest. Structure:

• Per earlier finding: status (Open / Fixed / Partially Fixed / Won't Fix + rationale).
• Verification method: which test was performed, the result. Fixed only when reproduction steps now fail.
• Overall attestation: in a small engagement a paragraph in the main report, in compliance trajectories a separate attestation letter on letterhead.
• New findings during retest: registered as new IDs, not hidden inside existing ones.

7. Verification-loop

Layer 1: scope (the report covers exactly the RoE period, not later, not earlier; out-of-scope observations to side-channel?), assumptions (CVSS vectors correct, every reproduction step actually works?), gaps (all findings recorded during the engagement either in the report or omitted with rationale?). Layer 2: CVE IDs verified against NVD, CWE classifications real, no invented version-bound exploit details in findings, exec-summary numbers match the finding count in the report.

Output

The report itself, plus a zip-style delivery package:

Pentest report — <engagement-name>
Customer:    <name>              | Engagement-ID: <...>
Period:      <start → end>       | Type: <web-app / network / red-team / BB>
Team:        <testers, with role>| RoE: <document ref>

Executive summary (3–5 pages):
  <risk-driven lead>
  <findings figures: N critical, M high, K medium, L low>
  <three program-level recommendations>

Engagement details:
  Scope:             <in + out>
  RoE deviations:    <none | list>
  Methodology:       <PTES / OWASP WSTG / MITRE ATT&CK subset>

Findings:
  ## FIND-YYYY-001 — <title>
     Severity:       <Critical/High/Medium/Low/Informational>
     CVSS v3.1:      <score> (<vector>)
     [CVSS v4.0:     <score> (<vector>)]
     CWE:            CWE-<N>
     OWASP:          <A0x / API0x>
     Affected:       <endpoints/components>
     Description:    ...
     Impact:         ...
     Reproduction:   <numbered steps>
     Recommendation: ...
     References:     ...
     Status:         <Open/Fixed/Won't Fix>
     [MITRE ATT&CK:  <T-IDs for red-team>]
     [Detection opportunity: <for blue team>]

Remediation roadmap:
  <priority matrix with effort + owner + deadline>
  <compensating controls per long-running fix>
  <pattern-level recommendations>

Retest section (if applicable):
  <per earlier finding: status + verification>

Appendices:
  A. CVSS vector details
  B. Tool output (redacted)
  C. Request/response pairs
  D. Reference list

Attestation letter (compliance context):
  <separate document, letterhead>

Verification-loop: ...

Delivery channel: encrypted package (7z+password via a separate channel, or sharing platform with access control), not as an email attachment. PII in findings redacted before delivery. Retention agreements from the RoE (who keeps what for how long) in the delivery email.

References

• FIRST CVSS v3.1 — https://www.first.org/cvss/v3-1/specification-document and calculator https://www.first.org/cvss/calculator/3.1.
• FIRST CVSS v4.0 — https://www.first.org/cvss/v4-0/specification-document.
• PTES (Penetration Testing Execution Standard) — http://www.pentest-standard.org/. Reporting-phase details.
• OWASP WSTG — Reporting — https://owasp.org/www-project-web-security-testing-guide/.
• NIST SP 800-115 — https://csrc.nist.gov/pubs/sp/800/115/final. §7 Reporting Guidelines.
• CWE — https://cwe.mitre.org/.
• MITRE ATT&CK — https://attack.mitre.org/. For red-team engagements.
• OWASP Risk Rating Methodology — https://owasp.org/www-community/OWASP_Risk_Rating_Methodology. Alternative when CVSS is too technical for the audience.
• CREST Penetration Testing Guidance — https://www.crest-approved.org/. Professional-standards reference.

Categories

• pentest