You're assessing the ordering platform and Docker infrastructure for an olive oil exporter in Bejaia, Algeria — the deliverable is a security report for EU export compliance inspectors.
The discipline skills: passive OSINT as a technique category (demonstrating the crt.sh / Shodan / Google-dork workflow on a lab target with no public DNS footprint, then practicing the same pedagogy against sources that are genuinely public for this deployment — Docker Hub base image metadata, NVD and GitHub Security Advisory data for pinned versions, committed source artifacts); multi-protocol active scanning including UDP and OS detection; container hardening with non-root execution, pinned base images, and Trivy scanning; building a CI pipeline with GitHub Actions for automated security checks.
The AI-direction lesson: AI presents every OSINT result as equally relevant. A pinned version lookup returns dozens of CVEs; a committed source review surfaces every string that looks like a secret — AI lists them without distinguishing what's in scope from what's not, what's current from what's stale, what's confirmed from what's disclosed. You impose the scope. This project also introduces cross-checking: a second AI reviews your Sigma rules with fresh context, catching interpretation gaps that self-review normalizes. The same reasoning that produced an artifact also evaluates it — which is why a second perspective matters.
Your Role
You are assessing the ordering platform and the server infrastructure it runs on. The scope now includes Docker containers and the monitoring stack — infrastructure, not just the application inside it.
The TTP selection guide describes categories of testing without listing every specific test. You decide what to test within each category. You also fill in a threat model template for Samir's system.
What's New
Last time you assessed a web application with multi-vulnerability exploitation, wrote Sigma rules for each attack type, remediated in priority order, and produced a multi-finding report. You know the purple team pipeline. You know that different attacks produce different log signatures. You know that AI's field names in Sigma rules may not match the actual log format.
Two new domains enter at once.
Passive reconnaissance. Before you run any scans, you gather intelligence from sources that are already public — without touching Samir's infrastructure. On a public-internet engagement that means crt.sh, Shodan, and Google dorks. On this lab deployment (no public hostname, no routable IP) those sources return empty, which is itself a scope-relevant finding. You then practice the same pedagogy against the sources that are genuinely public for this target: Docker Hub metadata for every pinned base image, public CVE data from NVD and GitHub Security Advisories, and read-only review of the committed platform source. The technique is identical in every engagement; the public sources shift with the deployment. The challenge is that AI treats every result as equally relevant. You impose scope.
Container hardening. The Docker containers running Samir's platform were built with default configurations. After the assessment, you harden them — non-root execution, pinned base images, vulnerability scanning, a CI pipeline that catches problems before deployment. This is the first time you work with the infrastructure layer rather than just the application layer. Build-time security decisions differ fundamentally from the runtime fixes you have done before.
The hard part is holding both perspectives at once. Passive OSINT and container hardening look like separate concerns, but they connect through the same principle: least privilege extends from what the public can see about your infrastructure to what a compromised container can access on the host.
Tools
- crt.sh, Shodan/Censys, Google dorks — canonical passive OSINT sources. Demonstrated as a category; return empty on this private-by-deployment lab, which is recorded as a finding. New.
- Docker Hub, NVD, GitHub Security Advisories — public registry and vulnerability data for pinned base images. The passive OSINT sources that are genuinely public for this deployment. New.
- Nmap — multi-protocol scanning, now including UDP and OS detection. Extended.
- ffuf — content discovery and directory brute-forcing. New.
- Wireshark/tshark — packet-level network analysis. New.
- Trivy — container image vulnerability scanning. New.
- GitHub Actions — CI pipeline for automated security scanning. New.
- Docker — running the vulnerable application and monitoring stack, then hardening the containers.
- Grafana/Loki/Alloy — log viewing and monitoring. Continuing.
- pySigma — Sigma rule to LogQL conversion. Continuing.
- Claude Code — AI agent directing all tool execution.
- Git/GitHub — version control and project submission.
Materials
- Scope document — assessment boundaries, now including container infrastructure and monitoring.
- TTP selection guide — testing categories without enumerated tests. You choose the specific tests.
- Threat model template — blank STRIDE template for you to fill in for Samir's system.
- Sigma rule starter — YAML structure template for detection rule authoring.
- Report template — assessment report structure with compliance framing for the French inspectors.
- Docker environment — the ordering platform, database, Grafana, Loki, and Alloy running in containers.
- CLAUDE.md — project governance file with the client, stack, and verification targets.