The Report for Dimitar

Step 1: Compile the assessment report

Open materials/report-template.md. The template has sections for everything you have produced: executive summary, assessment scope, methodology, web findings, API findings, exploit chains, remediation status, CIS and ASVS compliance, and recommendations.

Using the report template, compile the full assessment report. Pull findings from the remediation log, compliance documentation, exploit chain evidence, and detection rule inventory. Each finding should include CVSS/EPSS scores, CIS or ASVS mapping where applicable, and remediation status.

AI will populate the template. Check the output against your actual findings. AI commonly reorders findings by severity instead of your CVSS/EPSS prioritization, or drops the compliance mappings you built in Unit 8. The report should reflect your assessment -- your priority order, your triage decisions, your evidence.

Step 2: Write the executive summary

The executive summary is for Dimitar. He reads this section first. If it does not make sense to a winemaker, it fails.

Write the executive summary for Dimitar. Translate every technical finding into business language. "Your restaurant partners' pricing information could be accessed by anyone with a valid API key" -- not "BOLA vulnerability in /api/v1/wholesale/pricing/{partner_id}." Include the business impact: revenue risk, customer data exposure, partner trust.

Dimitar understands doors, wine, seasons, and partnerships. The API handling 40% of his revenue is not an abstract technical system -- it is how his restaurant partners order wine. Customer data is not "PII" -- it is the names, addresses, and order histories of people who buy his wine. Frame every finding in those terms.

Step 3: Prepare the technical section

The technical section serves whoever maintains the platform next -- Dimitar's nephew, an external developer, or a future security assessor. This audience needs specifics: CIS item numbers, ASVS requirement references, exact remediation steps, detection rules deployed, and what remains unfixed.

Write the technical section with specific remediation steps for each finding. Reference CIS and ASVS item numbers. Include the detection rules deployed and their verification status. List any findings that were not remediated and explain why.

Two audiences, one document. The executive summary moves Dimitar to action. The technical section tells the implementer exactly what to do. Both must be present. A report that only speaks to one audience fails the other.

Step 4: Review with Dani Okafor

Dani Okafor, a senior detection engineer, reviews the report. Dani is precise and methodical. She reads the detection rule section and asks one question:

"Your exploit chain crosses three stages -- authentication bypass, privilege escalation, data access. Your detection suite has rules for each stage individually. What happens if an attacker executes stages one and two but stops before three? Does your detection catch the partial chain, or only the complete sequence?"

This is a real gap in detection design. Individual rules catch individual events. A partial chain -- where the attacker probes but stops short of full exploitation -- may not trigger any alert if detection is designed only for the complete sequence. Consider whether your rules need correlation logic or whether the individual stage alerts are sufficient.

Step 5: Send the report to Dimitar

Send the final report through the living client interface.

Dimitar reads the executive summary first. He understands the risk because it is in his terms: restaurant partners might see each other's pricing, customer order histories could be accessed, and during harvest season -- when orders flow daily -- a disruption would cost real revenue.

He thanks you and asks about next steps. Then he mentions the mobile app again: "My nephew's app connects to the same system. Should that be checked too?"

The mobile app is out of scope. It was out of scope when you started, and it remains out of scope now. Acknowledge the legitimate concern -- the app does connect to the same API, and that is worth noting in the report's recommendations. But expanding the assessment boundary after the engagement is complete is not the professional response. If Dimitar wants the mobile app assessed, that is a separate engagement with its own scope document.

Step 6: Push to GitHub

The assessment is complete. The repository should contain: the target profile, the STRIDE threat model, all exploitation evidence, detection rules, remediation documentation, compliance assessments, and the final report.

Review the repository contents. Ensure all assessment artifacts are committed with clear commit messages. Push to GitHub.

The commit history tells a story. Someone reviewing this repository should see the assessment phases in sequence: reconnaissance, scanning, exploitation (web then API), detection, remediation, compliance, reporting. Clean commits with descriptive messages are part of the professional deliverable.