The Brief and the Environment

Step 1: Set up the project

Open a terminal, navigate to your development directory, and start Claude Code.

cd ~/dev

claude

Paste this setup prompt:

Create the folder ~/dev/cybersecurity/p3. Download the project materials from https://learnbydirectingai.dev/materials/cybersecurity/p3/materials.zip and extract them into that folder. Read CLAUDE.md -- it's the project governance file. Then start the Docker environment with docker compose up -d from the vulnerable-platform directory, and run the verify-environment script.

Claude creates the folder, downloads the materials, reads the governance file, brings up the Docker containers, and runs the verification script. The script checks that each service is reachable -- the ordering platform on port 8080, Grafana on port 3000, and PostgreSQL on port 5432.

Step 2: Verify the environment

Once the containers are running, open your browser and navigate to http://localhost:8080. You should see the Kabylie Gold ordering platform -- a login page for wholesale buyers, not a consumer-facing shop. This is a B2B platform where buyers in Lyon, Hamburg, Montreal, and New York manage their olive oil orders.

Now open http://localhost:3000 in another tab. This is Grafana, the monitoring dashboard the developer set up. Navigate to the Explore view, select the Loki data source, and run a query to see log entries from the application container. Logs flowing means the monitoring stack -- Grafana, Loki, and Alloy -- is collecting data from the running containers.

Check the Docker container listing to see what is running.

docker compose ps

You should see five services: the app container, the PostgreSQL database, Grafana, Loki, and Alloy. All five are part of the assessment scope. In P1 and P2, Docker was the lab environment -- you ran containers, but you assessed the application inside them. This time the container configuration itself is a target. How the containers are built, what user they run as, what they have access to on the host -- all of that matters.

Step 3: Read Samir's messages

The client reaches out on Slack. This is your first-contact artifact -- open the living client configuration or read the Slack messages provided in the platform.

Samir sends four separate messages in under five minutes. He introduces his business, explains the French compliance pressure, mentions the Docker platform and the monitoring tool, and asks for help. His style is immediately visible: enthusiastic, informal, tangential. He mentions olive varieties in the same breath as food safety inspectors.

Under the messages, you have three response options. Pick the one that matches your approach. Each option moves the engagement forward, but they set different tones -- one asks clarifying questions before starting, one acknowledges and begins work, one asks for developer documentation.

Notice what Samir tells you and what he does not. He knows the platform was built by an agency using Docker containers. He knows buyers log in with email and password. He knows the developer set up Grafana. He does not describe how the containers are configured. He does not mention specific security measures. The gap between what the client knows and what you need to discover is where the assessment begins.

Step 4: Read the scope document

Open materials/scope-document.md.

The scope defines four target areas: the web application on port 8080, the PostgreSQL database, the monitoring stack (Grafana, Loki, Alloy), and the container infrastructure itself. That last category is new. In P2, the scope covered the web application and its database. Here it extends to Dockerfiles, compose configuration, runtime users, filesystem permissions, and base image security.

The out-of-scope section matters too. The host operating system beyond container configuration is excluded. Social engineering is excluded. Denial-of-service testing is excluded -- Samir has 40 buyers placing orders daily, and the platform must stay up. There is also a brochure website on a separate server that is explicitly out of scope. Any systems discovered during passive reconnaissance that are not listed in the scope document must be reported to the client, not investigated.

That last rule is a professional constraint. Finding a subdomain or service that was not in the original scope creates an obligation to inform the client, not to start testing it. Scope boundaries are legal boundaries.

Step 5: Read the TTP selection guide

Open materials/ttp-selection-guide.md.

This is different from P2. In P2, the TTP selection listed specific vulnerability types to test -- SQL injection, XSS, command injection. You knew exactly what to look for and in what order. This guide describes four testing categories: passive reconnaissance, active reconnaissance, web application testing, and container security testing. Within each category, it explains the objective and lists the approaches available. It does not tell you which specific tests to run.

The difference is meaningful. A specific test list tells you what to do. A category guide tells you the kinds of questions to ask, and you decide the specific tests based on what your reconnaissance reveals. If passive recon surfaces an unexpected API endpoint, you add API security testing to your web application plan. If the container listing shows unusual port mappings, you adjust your active scanning strategy.

This is also your first encounter with the threat model template in materials/threat-model-template.md. The template uses the STRIDE framework -- Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. You will fill it in for Samir's system as you gather findings. For now, know that it exists and what it is for.