⚠️ Lab Environment Only: The findings documented in DVWA Pentest Report Lab come from DVWA running on your own local machine. Report writing skills transfer to authorised engagements only. Never document findings from systems you do not have explicit written authorisation to test.
I have reviewed hundreds of pentest reports submitted by junior practitioners applying for roles on my team. The pattern is consistent: the technical work is solid — they found real vulnerabilities, they exploited them cleanly, they have the screenshots. But the reports do not communicate what they found. The executive summary is three bullet points that mention SQL injection and XSS without explaining why those things matter to the business. The findings are technically accurate but the remediation sections say “implement proper input validation.” The CVSS scores are missing or wrong. The report does not tell the story that makes a client act.
Report writing is the skill that closes the gap between finding vulnerabilities and getting paid to find them. A client cannot implement what they cannot understand. A hiring manager cannot evaluate skills they cannot read. Lab 28 is where you document everything you found in DVWA Labs 1 through 27 in a professional deliverable format — the same structure I use for client engagements. By the end of this lab you will have a complete pentest report you can show in interviews, submit as a portfolio piece, and adapt as a template for your first paid engagement.
🎯 What You’ll Master in Lab 28
Write a professional executive summary that communicates risk to a non-technical audience
Calculate accurate CVSS v3.1 scores for each DVWA finding category
Write complete technical finding write-ups with evidence, reproduction steps, and remediation
Structure a full pentest report in the format used by professional consultancies
Labs 1 through 27 built your technical exploitation and source review skills across every major DVWA vulnerability class. Lab 28 is the capstone — turning everything you found into a document that communicates those findings professionally. The DVWA lab series concludes at Lab 30 with advanced exploitation chaining. This report becomes the documentation for that chain as well.
Professional Report Structure — The Complete Template
Professional penetration test reports follow a consistent structure across the industry. The structure matters because clients and their security teams know what to expect and where to find specific information. Deviating from it adds friction. Here is the complete section order I use on every engagement.
OWASP Testing Guide version, CVSS v3.1, any relevant CVEs
🧠 EXERCISE 1 — THINK LIKE A HACKER (20 MIN · NO TOOLS)
Triage and Severity-Rank All Your DVWA Findings Before Writing
⏱️ 20 minutes · No tools needed — just your lab notes
Before writing a word of the report, professional pentesters triage all findings and sort them by severity. Getting the severity wrong changes the client’s response — a Critical that is filed as Medium gets deprioritised. A Low that is filed as Critical creates panic where none is needed. Work through this triage exercise before opening your report template.
For each DVWA finding below, assign a severity (Critical/High/Medium/Low)
and write a one-sentence business impact statement.
Do not use the vulnerability name in the impact statement.
Explain what an attacker can DO, not what the vulnerability IS.
FINDING A: SQL Injection in login form — attacker can extract
the users table including username/password hashes.
FINDING B: Stored XSS in comment field — script executes for
every user who views the page.
FINDING C: Command injection in ping utility — attacker can
run arbitrary OS commands as the web server user.
FINDING D: CSRF in password change form — no token required.
FINDING E: File inclusion — attacker can read /etc/passwd.
FINDING F: Reflected XSS in search parameter — requires victim
to click a crafted link.
FINDING H: Brute force login — no lockout after failed attempts.
For each finding, write:
Severity: [Critical/High/Medium/Low]
CVSS Score range: [e.g. 8.0-9.0]
Business Impact: “[One sentence — no jargon]”
Evidence needed: “[What screenshot/request proves this?]”
✅ You just triaged 8 findings and have the severity rankings, business impact statements, and evidence checklist that structure the entire report. Expected answers: (A) Critical/9.8 — full database access including user credentials; (B) High/8.8 — every user’s browser session can be hijacked; (C) Critical/9.8 — complete server compromise; (D) Medium/6.5 — account modification without user action; (E) High/7.5 — sensitive server files accessible; (F) Medium/6.1 — victim session theft requires one click; (G) High/7.5 — account compromise by guessing; (H) Medium/5.3 — credential stuffing feasible without detection. The sorted list is your Findings Summary Table for Section 4.
📸 Share your completed triage table in #dvwa-labs on Discord.
Executive Summary — Writing for Non-Technical Readers
The executive summary is the most-read and least-well-written section in most pentest reports. Every CISO reads it. Most CTOs read it. The CEO or CFO reads it when the finding is significant. None of them want to read about SQL injection — they want to know whether the company is at risk, what could happen, and what to do first.
Three rules I follow for every executive summary. First: no technical jargon whatsoever. Replace “SQL injection” with “the ability to read the entire user database.” Replace “stored XSS” with “code that runs in any visitor’s browser and can steal their login session.” Replace “command injection” with “the ability to run any command on the web server.” Second: lead with the overall risk, not the finding count. “The application presents a Critical level of risk to the organisation” is a stronger opener than “we found 14 vulnerabilities.” Third: end with one action. One specific, named, achievable action the client should take this week.
EXECUTIVE SUMMARY TEMPLATE — DVWA REPORT
EXECUTIVE SUMMARY
SecurityElites conducted a web application penetration test of the
DVWA application between [dates]. The assessment identified
[X] vulnerabilities across [X] severity categories.
The application presents CRITICAL risk to the organisation.
An unauthenticated attacker with internet access can:
→ Read every username and password stored in the database
→ Execute arbitrary commands on the web server operating system
→ Redirect any user’s browser session to an attacker-controlled page
These capabilities exist because the application processes user
input without verification before using it in database queries,
operating system commands, and web page output.
FINDINGS SUMMARY
Critical: 2 findings
High: 3 findings
Medium: 4 findings
Low: 3 findings
IMMEDIATE ACTION REQUIRED
The two Critical findings (SQL injection in the user lookup function
and OS command injection in the network utility) should be remediated
before this application is accessible to users. Remediation guidance
is provided in Section 5 of this report.
CVSS v3.1 Scoring — Getting the Numbers Right
CVSS scores are the shared language that lets clients prioritise remediation, lets vendors communicate severity, and lets security teams justify budget. Getting them wrong undermines your credibility. Getting them right — with the vector string that shows your reasoning — demonstrates professional rigour.
Use the calculator at first.org/cvss/calculator/3.1 for every finding. Never guess the score. The six base metrics are the only ones that go in the base score — Temporal and Environmental metrics are optional and rarely used in standard pentest reports.
CVSS v3.1 SCORING — DVWA FINDINGS WORKED EXAMPLES
# ── FINDING: SQL Injection (unauthenticated, full DB read) ──────
Each technical finding in Section 5 follows the same structure. Consistency matters — a reviewer reading finding 8 should not have to search for the CVSS score in a different place than finding 2. Here is the complete format with a worked SQL injection example.
COMPLETE FINDING FORMAT — SQL INJECTION WORKED EXAMPLE
Business Impact
An unauthenticated attacker can extract every username and password hash from the database. MD5 hashes are crackable — this finding represents a complete compromise of all user accounts.
Remediation
Replace direct variable concatenation with PDO prepared statements (as implemented in DVWA Impossible security level, sqli/source/impossible.php).
📸 Professional finding block showing the complete format: severity badge, CVSS score, affected component, business impact in plain language, and source-specific remediation recommendation. This format is consistent across every finding in the report — Critical findings lead in red, the business impact uses no jargon, and the remediation cites the specific file and function to change.
⚡ EXERCISE 2 — KALI TERMINAL (25 MIN)
Calculate CVSS Scores for All 8 DVWA Findings
⏱️ 25 minutes · Browser — CVSS calculator at first.org/cvss
This exercise calculates accurate CVSS v3.1 base scores for the 8 DVWA findings from Exercise 1. Work through every metric for each finding. Getting the scores right requires thinking through each metric carefully — do not estimate.
Open the CVSS v3.1 calculator: https://www.first.org/cvss/calculator/3.1
For each finding, work through all 6 base metrics and record:
— Base Score (e.g. 9.8)
— Severity Label (Critical/High/Medium/Low/Informational)
— Vector String (e.g. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
FINDING A: SQL Injection — unauthenticated, reads full user table
FINDING B: Stored XSS — executes for every page visitor (no click needed)
FINDING C: Command Injection — requires login, runs OS commands
FINDING D: CSRF — changes password without user action (attacker needs link clicked)
FINDING E: File Inclusion — reads /etc/passwd, unauthenticated
FINDING F: Reflected XSS — requires victim to click crafted link
FINDING G: Weak session token — sequential integers, no authentication
FINDING H: Brute force login — no account lockout
Key metrics to reason through carefully:
— User Interaction: Required only if victim must actively click something
— Scope: Changed if the impact crosses security boundaries (e.g. web → OS)
— Privileges Required: None if unauthenticated access works; Low if any login
Cross-check your scores against the worked examples above.
For any score that differs significantly, re-examine that metric.
What did you assess differently and why?
✅ You just calculated accurate CVSS scores for 8 findings — the foundation of the findings table in Section 4. Expected scores: (A) 9.8 Critical; (B) 8.8 High; (C) 9.0 Critical; (D) 8.8 High; (E) 7.5 High; (F) 6.1 Medium; (G) 7.5 High; (H) 5.3 Medium. The most common errors: marking Scope as Unchanged for command injection (it should be Changed — you move from web app to OS), and marking User Interaction as None for CSRF (it should be Required — a victim must visit the malicious page). Both change the final score significantly.
📸 Screenshot your CVSS calculator showing the vector string for the most complex finding. Share in #dvwa-labs on Discord.
Evidence Documentation — Screenshots and Request Captures
Evidence in a pentest report has one job: prove to a reader who was not present that the vulnerability exists and the impact you described is real. Every Critical and High finding needs a minimum of two evidence items: a screenshot showing the vulnerability being exploited and the Burp Suite HTTP request that triggered the finding. The screenshot proves the impact visually. The request proves reproducibility technically — a developer can copy that request into their own Burp and confirm the finding immediately.
EVIDENCE CHECKLIST PER FINDING SEVERITY
# CRITICAL findings — maximum evidence
✅ Screenshot of exploit payload submitted
✅ Screenshot of response showing extracted data
✅ Burp Suite request with payload (from Proxy history export)
✅ Burp Suite response showing sensitive data
✅ Step-by-step reproduction numbered list
# HIGH findings
✅ Screenshot of vulnerability confirmed
✅ Burp request showing the exploitation
✅ Numbered reproduction steps
# MEDIUM findings
✅ Screenshot or request showing the issue exists
✅ Numbered reproduction steps
# LOW / INFORMATIONAL findings
✅ Brief description with URL/parameter affected
Optional: screenshot if helpful for clarity
# Screenshot best practices
— Annotate with red boxes or arrows pointing to the key detail
— Include the URL bar to show the target is correct
— Blur any real passwords, personal data, or irrelevant credentials
— Export Burp requests as text (right-click → Copy to file)
— Caption every figure: “Figure 5.1.1 — SQL injection payload returning user hashes”
⚡ EXERCISE 3 — KALI TERMINAL (30 MIN)
Write Your Complete DVWA Pentest Report
⏱️ 30 minutes · Your word processor · All DVWA screenshots ready
This is the capstone exercise for the entire DVWA lab series. Using the triage table from Exercise 1, the CVSS scores from Exercise 2, and your screenshots and Burp captures from previous labs, write a complete penetration test report. Work through every section in order.
REPORT WRITING SEQUENCE:
1. Create your document using the structure from Section 1.
Set up all headings and sub-sections before writing content.
2. Write Section 4 (Findings Summary Table) first — you already
have severity, CVSS scores, and finding titles from Exercise 1 and 2.
Create a table: Finding | Severity | CVSS | Status (Open)
3. Write each technical finding in Section 5.
Use the complete format from this article for each one.
Start with Critical findings, work down to Low.
For each finding write: Title, Severity, CVSS, URL, Description,
Steps to Reproduce, Evidence (figure references), Business Impact,
Remediation (cite Impossible source from Lab 27).
Minimum 4 technical findings documented in full.
4. Write Section 3 (Scope and Methodology).
State: testing was against DVWA running at http://localhost/dvwa.
Testing approach: manual with Burp Suite proxy.
Security level tested: Low.
Tools used: Burp Suite, manual payload testing.
5. Write the Executive Summary last.
Use the template from Section 2.
Fill in your actual finding counts.
Name the two Critical findings specifically.
Write the Immediate Action Required paragraph.
6. Add cover page and appendix structure.
7. Review: read the executive summary out loud.
If you cannot explain it to a non-technical person in 3 minutes,
rewrite it until you can.
✅ You have a complete penetration test report. This document represents the full output of a professional web application security assessment and is the deliverable that clients receive at the end of an engagement. It is also your portfolio piece — something tangible you can show in interviews and include in your professional profile. The report writing skill you just practised is what separates practitioners who find vulnerabilities from professionals who get paid to find vulnerabilities and communicate them clearly. Keep this template. You will adapt it for every future engagement.
📸 Screenshot your completed report’s executive summary page. Share in #dvwa-labs on Discord. Tag #lab28complete and #dvwa-series-complete
Finding sort orderCritical first, descending by CVSS score within each level
✅ Lab 28 Complete — Professional Pentest Report
You have a complete penetration test report documenting your DVWA findings with professional severity ratings, CVSS scores, business impact statements, and source-informed remediation recommendations. Lab 29 covers Metasploitable 2 — a new target, all new vulnerabilities, and the same report writing skills applied to a broader attack surface than DVWA’s controlled environment.
🧠 Lab 28 Check
You are scoring a command injection vulnerability in DVWA. It requires the attacker to be authenticated (low privileges), can be exploited remotely, has no complexity beyond basic injection, requires no user interaction, and gives the attacker OS-level command execution beyond the web application boundary. What Scope and Privileges Required values do you assign, and why does Scope = Changed matter for the final score?
❓ Pentest Report Writing FAQ
What should a penetration test report include?
A complete pentest report includes: cover page and engagement details; executive summary (non-technical, one page); scope and methodology; findings table sorted by severity; individual technical finding write-ups (title, severity, CVSS, description, reproduction steps, evidence, business impact, remediation); remediation roadmap; and appendices with raw tool output. Every Critical and High finding needs a minimum of two evidence items.
How do you calculate CVSS scores for pentest findings?
Use the CVSS v3.1 calculator at first.org/cvss/calculator/3.1. Assess six base metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the three impact metrics (Confidentiality, Integrity, Availability). The calculator outputs a base score and vector string — include both in the report. Never estimate CVSS scores; always use the calculator.
What is the difference between a pentest report and a bug bounty report?
A bug bounty report is a single finding with a title, reproduction steps, impact statement, and fix — submitted via a platform form. A penetration test report is a formal comprehensive document covering all findings from a scoped engagement with executive summary, risk ratings, business context, and a remediation roadmap. Bug bounty reports are brief; pentest reports are 20-100+ page professional deliverables.
How do you write a good executive summary for a pentest report?
Write it last but place it first. No technical jargon whatsoever — replace “SQL injection” with “ability to read the entire user database.” Lead with overall risk, not finding count. Name the most critical finding in business impact terms. End with one specific, named, achievable immediate action. If you cannot explain it to a CFO in five minutes, rewrite it.
What makes a pentest finding write-up professional quality?
Professional findings have: a clear title describing the vulnerability and affected component; accurate CVSS score with vector string; numbered reproduction steps an independent tester can follow; at least one screenshot confirming impact; a business impact statement explaining what an attacker can do (not what the technical vulnerability is); and a specific remediation recommendation citing the exact fix, not generic guidance.
What tools do pentesters use to write reports?
Common tools: PlexTrac and AttackForge for professional report management with finding libraries. Dradis for open-source report collaboration. SysReptor for modern markdown-based reports. Many consultancies use custom Word templates. For individual practitioners, a structured Word or Markdown template with consistent finding blocks works perfectly. The structure and content matter far more than the tool.
← Previous
Lab 27 — Source Code Review
Next →
DVWA Lab Series Hub
📚 Further Reading
Lab 27 — Source Code Review— The remediation recommendations in your report cite the DVWA Impossible source code — Lab 27 source analysis is the direct prerequisite for this lab.
Lab 22 — Vulnerability Chaining— When two findings combine to produce a higher-impact chain, the report section needs to document the chain finding as a separate entry above its component findings.
DVWA Complete Lab Series— All 30 labs from setup through advanced exploitation — the complete skills reference that produced the findings in your Lab 28 report.
CVSS v3.1 Calculator — FIRST.org— The authoritative CVSS v3.1 scoring calculator — bookmark this. Every finding in every report you write from this point forward gets a score from this page.
OWASP Web Security Testing Guide— The industry standard methodology reference cited in the Appendix B of professional pentest reports — maps DVWA vulnerability classes to formal testing procedures and remediation standards.
ME
Mr Elite
Owner, SecurityElites.com
The report that got me my first consultancy role was the DVWA report I wrote as a self-directed lab exercise. Not a client report — a practice report exactly like the one you just wrote in Lab 28. The hiring manager asked me to walk through one finding on a whiteboard during the interview. I walked through the SQL injection finding: source code, payload, CVSS calculation, business impact, remediation citing the prepared statement fix. He told me afterwards that most candidates could demonstrate the exploit but could not explain the CVSS score or write the business impact without jargon. Report writing is the skill that closes. Build the habit now and every engagement becomes easier to deliver.
