The Report

Step 1: Read the Report Template

Open materials/report-template.md. This is the structure for Jean-Marc's deliverable — the document that turns everything you have done in this project into something he can act on.

The template has sections: executive summary, findings with risk ratings, remediation actions taken, hardening actions taken, and recommendations. Each section has a purpose. The executive summary is for Jean-Marc — a lodge owner who does not know what SQL injection is but needs to understand whether his guests' data is safe. The findings section is the evidence. The remediation and hardening sections show what was fixed and how it was verified. The recommendations are what comes next.

Read the whole template before you start filling it in. A finding without methodology is an assertion, not evidence. The template's structure — what was found, how it was found, what the risk is, what was done about it — is how security work becomes professionally meaningful. Every piece of evidence you gathered across the previous five units feeds into this document.

Step 2: Direct Claude to Fill In the Report

Direct Claude to populate the report template using the findings from this assessment:

Read materials/report-template.md. Fill in the report using the findings from our assessment of the DVWA booking page. The executive summary must be written for Jean-Marc — a non-technical lodge owner who needs to understand what was found and whether his guests' data is now safe. Use plain language in the executive summary. The findings, remediation, and hardening sections can include technical detail, but each finding should explain why it matters for Jean-Marc's business.

That prompt gives Claude the constraints that matter: who the audience is, what language to use, and what the report needs to accomplish. A prompt that says "fill in the report template" gives Claude nothing to work with — it will default to whatever report style appears most often in its training data, which is usually technical documentation written for other security professionals. Jean-Marc is not a security professional. He runs a lodge.

When the prompt omits the audience, Claude fills the gap from its training distribution. The result reads like a penetration test report from a large consultancy — full of ATT&CK IDs, CVSS scores, and language that assumes the reader knows what a prepared statement is. That is not wrong. It is not what Jean-Marc needs.

Step 3: Review the Findings Section

Read what Claude produced for the findings section. Each finding should answer four questions:

1. What was found? (SQL injection in the booking search parameter.)
2. Why does it matter for Jean-Marc? (An attacker could extract every guest record — names, emails, passport numbers.)
3. What was done to fix it? (The vulnerable code was replaced with a prepared statement.)
4. What evidence proves the fix works? (sqlmap re-test failed to exploit the injection.)

If the findings section reads like a list of technical observations without connecting them to Jean-Marc's business, redirect Claude. The SQL injection finding is not "parameter id is vulnerable to UNION-based injection (ATT&CK T1190)." It is "someone could type a crafted string into your booking search and download every guest's passport number." The ATT&CK mapping belongs in the technical detail — not the summary of what was found.

Check that the risk rating makes sense. A vulnerability that exposes guest passport numbers is not "medium." It is high. If Claude defaulted to a moderate rating, adjust it.

Step 4: Review the Hardening Section

Read the hardening section. Each action should explain two things: what was changed, and what risk it addresses.

"Closed port 3306" is a configuration record. "Closed port 3306 because external MySQL access allows direct database connection, bypassing application-layer controls" is a security communication. The difference matters because whoever maintains Jean-Marc's system after this assessment needs to understand why the port was closed — not just that it was. If they reopen it without understanding the rationale, the hardening is undone.

Check that each hardening item includes the verification result. Port 3306 closed — confirmed by Nmap scan. Default credentials disabled — confirmed by failed login attempt. The evidence chain does not stop at "we made the change." It stops at "we verified the change took effect."

Step 5: Review the Full Report

Read the report from start to finish as if you were Jean-Marc. He is not a security professional. He runs an eco-lodge on Nosy Be. His developer moved to France. A friend's hotel in Mauritius was hacked through their booking system, and he is worried about the same thing happening to him.

Would he understand the executive summary? Would he know what was found, whether it was fixed, and what he should do next? If the answer is no — if the summary is full of jargon, if the findings assume technical knowledge, if the recommendations are vague — redirect Claude.

The report is the deliverable. Everything you did in the previous five units — the reconnaissance, the exploitation, the detection review, the remediation, the hardening — exists to support this document. If the report does not communicate what happened and why it matters, the technical work is professionally incomplete.

Step 6: Send the Report to Jean-Marc

The report is ready. Send it to Jean-Marc. In the client email, include a brief summary of what the assessment found and what was done about it — the email is not the report, but it frames the report so Jean-Marc knows what he is reading.

Jean-Marc responds warmly. He reads the report and understands what was wrong with his booking page. He is relieved that his guests' passport numbers are now protected. Whale season starts soon, and he does not want to be worrying about whether someone can steal his guests' personal information through the booking form.

Then he asks: "Could you also check if our guest Wi-Fi is safe? Since you mentioned the encryption thing, I have been wondering."

This is out of scope. The scope document you read in Unit 1 defined the assessment boundaries — the web application on port 80/8080 and its database services. Wi-Fi networks were explicitly listed as out of scope. Jean-Marc's concern is legitimate. His question is reasonable. But a Wi-Fi assessment is a different engagement with different tools, different scope, and different authorization.

Acknowledge his concern and explain that a Wi-Fi security assessment would need its own scope and authorization. Offer to discuss it as a separate engagement. Do not downplay the question — he is right to wonder — but do not expand into work that was not authorized.

This is scope management. It is a professional skill, not a technicality. Expanding scope without authorization exposes both you and Jean-Marc to risk — you would be testing systems you are not authorized to test, and he would receive findings from an assessment that was not properly scoped.

Step 7: Write the README

A repository without a README is a list of files with no explanation. Anyone visiting the repo -- including you, or whoever maintains Jean-Marc's systems next -- needs to understand what was assessed and what was found.

Direct Claude to write a README for the project: "Write a README.md that describes what this assessment covered, the scope, the key finding and its remediation status, and what files are in the repository. Keep it concise."

Review what Claude produces. Does it accurately describe the assessment scope and outcome? A README that says "critical vulnerability found" when the finding was medium-severity is wrong. The README should match the report.

Step 8: Push to GitHub

The assessment is complete. The report is delivered. Commit the project and push it to GitHub.

Commit all the project files -- the report, the assessment evidence, the README, and any configuration changes from the remediation and hardening work. Push to GitHub.

The commit captures the assessment outcome -- not just the report, but the full body of work that supports it. Jean-Marc has his deliverable. The booking page vulnerability is fixed. The hardening is verified. The project is done.