Security Testing
Advanced 20 min read Security Testing

Penetration Testing & Reporting

Penetration testing simulates an attacker's methods within a defined scope to find exploitable weaknesses and measure real impact. Learn how findings become severity-scored, evidence-backed report entries, and how remediation and retest close the loop for the business.

penetration testingpentestCVSSfindingexecutive summaryremediationretestevidence
Prerequisites: Security Testing Fundamentals SAST, DAST & Dependency Scanning Auth & Session Attacks
Introduction

What is this?

Penetration testing (pentesting) simulates an attacker's methods against a system within a defined scope to find exploitable weaknesses and measure the real impact of a breach. Reporting converts those findings into a prioritized, evidence-backed document that lets the business decide what to fix first. A pentest without a clear report is just 'we broke our own app'.

Motivation

Why do you need it?

  • The report is the deliverable — the test's value is only realized when findings are understood and acted on.
  • Severity ratings such as CVSS give stakeholders a shared, comparable measure of risk.
  • Reproducible evidence (requests, responses, payloads) lets developers verify the fix and the retest.
  • Compliance programs require periodic pentests with documented remediation and retest evidence.
  • Executive summaries translate technical findings into business risk so leadership can prioritize spend.
Think about it

Mental model

Imagine

A structural engineer's inspection report

Think of

A pentest report

The engineer does not just tell you 'the building is unsafe' — they identify the cracked beam, why it cracked, how urgent it is, and what to fix first. A pentest report does the same for software, so the decision to spend effort on a fix is evidence-based.

Mechanics

How it works

  • Define the engagement scope, rules of engagement and reporting cadence before testing starts.
  • Testers record every finding with the exact steps, requests and responses that reproduce it.
  • Each finding is scored with CVSS and classified by type (CWE, OWASP) and location.
  • The report is written in layers: executive summary, technical findings, remediation guidance and retest results.
  • The team fixes criticals first, the tester retests each fix, and the report is closed out with verified evidence.

From scoping to a closed-out report.

Scoping meeting
Testing & evidence capture
Findings triage
Report drafted
Remediation & retest
Reference

Key commands

git rev-parse HEAD

Record the exact build under test so the report stays traceable.

2f3a1c9b4e8d7c6f5a4b3c2d1e0f9a8b7c6d5e4f
curl -s -i -H "Cookie: <alice-session>" "http://sandbox.local/api/invoices/42" -o H-01-evidence.txt

Capture the exact request/response pair as reproducible evidence for a finding.

date -u +%Y-%m-%dT%H:%MZ

Timestamp every step so findings and retests can be placed on a timeline.

2026-07-03T14:02Z
curl -s "http://sandbox.local/login" -c cookies.txt -o /dev/null

Create a reusable cookie jar for authenticated testing before capture.

jq -r '.site[] | [.name, (.alerts[] | .riskdesc)] | @tsv' zap-report.json | sort -u

Summarize DAST alerts by risk for the findings table.

Hands-on

Examples

A finding entry in a pentest report

A finding entry in a pentest report
# Penetration Test Report — checkout-api v2.3.1
Scope: https://staging.checkout.example.com (per SOW 2026-014)
Dates: 2026-07-01 to 2026-07-05   Testers: A. Reyes, T. Okafor
 
## Executive Summary
Two critical, three high and four medium findings were identified.
No finding allows remote code execution; one critical allows full
account takeover of any registered user. Two criticals and one high
were remediated and retested during the engagement window.
 
## Finding H-01 (Critical)
Title: Broken object-level authorization on GET /api/invoices/:id
CWE-639 - CVSS 9.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
- Reproduction: log in as alice, then call GET /api/invoices/42 with alice's token
- Evidence: (request/response pair pasted below, 2026-07-03 14:02 UTC)
- Impact: any authenticated user can read any other user's invoices,
  including payment card metadata.
- Recommendation: add an owner check in the handler (see secure snippet)
  and release a hotfix.
- Status: OPEN - verified on 2026-07-04
 
## Finding M-01 (Medium)
Title: Session cookie missing SameSite attribute
...
 
## Remediation Summary
| ID       | Severity | Status                          |
| H-01     | Critical | OPEN                            |
| H-02     | Critical | FIXED - retest 2026-07-09       |
| M-01     | Medium   | FIXED - retest 2026-07-08       |

Every finding entry has a title, a canonical CWE and a CVSS vector, plus reproduction steps, timestamped evidence, impact, remediation guidance and a status. The executive summary and remediation table let leadership see the risk profile and progress at a glance, while the technical sections give developers everything they need to reproduce and fix. This structure makes the report usable by both audiences.

Real world

In production

  • Executives read the summary and engineers read the technical section — the report is written with both audiences in mind.
  • Every finding includes reproduction steps and evidence so the fix can be verified and the retest is fast.
  • Reports are versioned and stored alongside the engagement contract for compliance audits.
  • Retest results close the loop and prove remediation, which auditors and renewal processes rely on.
Guidelines

Best practices

  • Agree on severity definitions and CVSS scoring with the client before testing.
  • Write findings that are reproducible: exact request, response, payload, account and build hash.
  • Separate facts from opinions — 'we observed X' versus 'we believe Y'.
  • Include remediation guidance at the developer's level, with code snippets and configuration.
  • Re-test every fix and record the outcome in the final report.
Watch out

Common mistakes

  • Dumping raw scanner output and calling it a report.
  • Scoring without context, so everything comes out 'critical' and nothing is prioritized.
  • Skipping the executive summary, leaving leadership unable to act.
  • Reporting a finding once without re-testing the fix afterward.
Root cause analysis

Common issues

Error
A developer cannot reproduce the reported issue
Root cause

The report omits the environment, account or exact payload.

Fix

Add the exact URL, headers, payload, account details and build hash to the finding.

Error
Stakeholders dispute the severity score
Root cause

The CVSS vector was applied without documenting its context.

Fix

Record the CVSS vector and the impact scenario for each finding so the score is explainable.

Error
Retest shows the issue is still present after the fix
Root cause

The fix addressed a symptom, not the root cause.

Fix

Update the remediation guidance to target the root cause and re-open the finding with the new evidence.

When things break

Debugging tips

  • Keep a raw request/response pair for every finding before writing a single word.
  • Include timestamps, tool versions and the target build hash so the report is reproducible months later.
  • If a finding cannot be reproduced twice, it is not ready to be reported.
Interviews

Interview checkpoint

Practice

Hands-on lab

From Findings to Report: Document a WebGoat Exploit
50 min · advanced
In progress
Objectives
  • Exploit a WebGoat lesson and capture reproducible evidence
  • Score the finding with a CVSS vector and map it to a CWE
  • Write an executive summary and a full finding entry
  • Define a remediation and a retest plan for the finding

From Findings to Report: Document a WebGoat Exploit

50 min · advanced

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which part of a pentest report is aimed at enabling leadership to make prioritization decisions?

2

A pentest report should only contain findings that are confirmed and reproducible.

3

The same technical flaw is found on a public profile endpoint and on an admin-only payment endpoint. How should the severity differ?

Quick reference

Cheat sheet

Reporting essentials
git rev-parse HEADBuild hash under test
curl -s -i ... -o evidence.txtCapture request/response
date -u +%Y-%m-%dT%H:%MZTimestamp every step
CWE + CVSS vectorClassify and score each finding
Reproduction steps + impactRequired for every finding
Remediation + retest statusClose the loop per finding
Go deeper

Official documentation

OWASP Web Security Testing Guide
docs
Penetration Testing Execution Standard (PTES)
docs
CWE — Common Weakness Enumeration
docs
OWASP WebGoat Project
docs