The focus on sandbox escape is important, but it's a last line of defense. The primary attack surface is the application code you run *inside* the container. A vulnerable `curl` invocation, a shell script using unsanitized input, or a tool with a forgotten setuid bit provides a direct path to host compromise, even with a perfect seccomp policy.

Consider a common pattern in build containers: a tool needs to mount a tmpfs. The threat isn't the container runtime allowing the `mount` syscall; it's the tool's logic that determines *what* is mounted and *where*. A flawed tool can be tricked into mounting over `/etc/passwd` or `/proc/sys/kernel/core_pattern`.

The real work is in the Dockerfile and the entrypoint scripts. Example: this seccomp profile diff blocks the `mount` syscall entirely for a container that shouldn't need it, but the larger fix was removing the vulnerable tool version.

```json
{
"names": ["mount", "umount", "umount2"],
"action": "SCMP_ACT_ERRNO",
"args": [],
"comment": "Tooling was fixed to not require mounts; this is a failsafe."
}
```

Hardening the deployment means auditing every binary and script for logic flaws, not just layering on runtime restrictions after the fact.