What's inside the image isn't how it's run

Speaker notes

• Make the distinction explicit up front: everything covered so far in this module (Trivy) answers 'what's inside this image' — packages, versions, known CVEs. Docker Bench answers a completely different question: 'how is this container actually being run, and how is the daemon itself configured.' A perfectly scanned, vulnerability-free image can still be launched in a dangerous way.
• Take the three flags one at a time. privileged: true disables nearly every isolation control from the previous slide's namespaces/cgroups/seccomp discussion in a single flag. pid: host breaks process-namespace isolation specifically — the container can see and signal every process on the host, not just its own. The Docker socket mount is the most severe: walk through the actual mechanism on the callout, don't just assert it's risky.
• The mechanism, stated precisely: the Docker daemon usually runs as root on the host. Anyone with access to its socket can ask it to do anything the Docker API supports, including 'start a new container, with the host filesystem bind-mounted in, running privileged.' That's a single command away from an interactive root shell on the real host — this is not a best-practice suggestion, it's a direct, mechanical privilege escalation path.
• Connect forward: this is exactly why the Module 3 admission-control slide later enforces things like 'no privileged containers' automatically — a policy engine closes this class of mistake structurally, rather than relying on every engineer remembering this slide.

Deck map