Remediation and the Report

Step 1: Remediate web application findings

Start with the web application vulnerabilities you confirmed in Unit 4. Work in risk-priority order -- the finding that puts the most buyer data at risk gets fixed first.

For each vulnerability, direct Claude to implement the fix, then re-run the original exploit to verify it fails.

Remediate the web application vulnerabilities in risk-priority order. For each fix, re-run the original exploit to confirm it no longer works.

Fixing multiple vulnerabilities is not repeating the single-fix process. Fixes can interact. A change to input validation might affect how another endpoint handles requests. AI fixes each vulnerability independently without checking whether the fixes compose correctly. After all fixes are applied, run the full set of exploits again to confirm nothing was reintroduced.

Step 2: Compile the report

Open materials/report-template.md.

This report integrates two assessment domains in one document: web application findings and container security findings. In P2, the report covered web vulnerabilities only. This time, container hardening decisions -- non-root USER, read-only filesystem, Trivy scanning, CI pipeline -- sit alongside web exploitation findings. The report must make both domains coherent to a reader who may understand one but not the other.

Using the report template, compile the full assessment report. Start with the web application findings, then add the container security findings, then the hardening actions, then the compliance summary.

Step 3: Write the executive summary

The executive summary is what Samir reads first -- and possibly the only section the French inspectors read in detail. It must answer Samir's core question: can he show the inspectors that the platform is secure?

Write it in business language, not technical language. The inspectors care about whether buyer data is protected, whether the platform's integrity can be verified, and whether Kabylie Gold has a process for maintaining security going forward. They do not care about CVE numbers or Docker USER directives.

Write the executive summary addressing French food safety digital security requirements. Frame the findings and remediations in terms of buyer data protection, platform integrity, and ongoing security practices. Mention the EU export certification context.

AI commonly defaults to technical jargon in executive summaries. If the draft mentions "SQL injection," "non-root USER," or "Trivy CVEs" in the executive summary, it needs rewriting. Samir understands "someone could see all your buyers' pricing terms" but not "unauthenticated API endpoint returns JSON payloads."

Step 4: Translate container findings

The container security section is the new challenge. Web application findings translate naturally -- "someone could steal buyer data" makes immediate sense to Samir. Container findings require more work.

"The container runs as root" means nothing to Samir. "The boxes your platform runs in were set up so that anyone who breaks into one of them gets the keys to the whole server -- including your monitoring system and every other application on it" -- that, he understands.

Rewrite the container security findings in language that a non-technical business owner would understand. Explain each finding in terms of what it means for the business, not what it means in Docker terminology.

For each container finding, the template asks for description, impact, evidence, remediation action, and verification result. The description and impact sections must be in Samir's language. The evidence and verification sections can be more technical -- the inspectors may want to see them, and Yacine can explain if needed.

Step 5: Address API and SSL findings

If you discovered the unauthenticated API endpoint during Unit 4 testing, it should be in the report as a web application finding. An endpoint that returns the full buyer list -- company names, addresses, pricing tiers -- without requiring any login is a direct threat to the commercially confidential data Samir's buyers trust him with.

If the SSL certificate gap came up in conversation with Samir (he may mention that buyers complained about browser warnings), document it in the report with a recommendation for certificate monitoring.

Step 6: Write recommendations

Recommendations tell Samir what to do next. Each recommendation should be specific enough that someone -- Yacine, the development agency, a future assessor -- can act on it.

Write prioritized recommendations. Include immediate actions (critical fixes), short-term improvements (monitoring, access controls), and longer-term steps (regular assessments, CI pipeline maintenance). Each recommendation should be actionable and specific.

Include a recommendation about the brochure site. Samir will ask about it -- he has an older website on a different server and wants to know if it needs assessment too. The brochure site is on a separate server and was not part of this engagement's scope. The correct recommendation is a separate assessment, not an expansion of this one.

Step 7: Send the report to Samir

This is the deliverable Samir has been waiting for. Send the completed report.

Samir reads fast. He skips to the executive summary and the part about what to tell the French inspectors. He is relieved the platform is not wide open. He asks about the container findings: "So the boxes are fixed now?" He wants confirmation in plain language.

He also asks: "We also have an older website -- just a brochure site for the brand, different server. Should we worry about that too?" The brochure site is out of scope. Recommend a separate assessment rather than expanding this engagement.

Step 8: Push to GitHub

The assessment is complete. Initialize a git repository if you have not already, commit the full project, and push to GitHub.

git add -A
git commit -m "p3-t6: complete assessment report and remediation"
git push origin main

The repository should contain: the remediated application code, the hardened Dockerfile, the docker-compose configuration, the GitHub Actions workflow, your reconnaissance documentation, the Sigma rules, and the final assessment report.