Container Escape Risk Calculator
Score container escape risk from privileged containers, mounted runtime sockets, host namespaces, capabilities, runtime class and kernel patch age.
Inputs
Container Escape Risk Score
92.3/ 100
Risk Level
Critical
Weighted Escape Vector Points
490points
Escape Points per 1000 Containers
408.3
Workload Configuration Penalty
61.3points
Host Hardening Penalty
31.0points
Primary Escape Vector
Privileged containers — full host device and kernel access
Highest-Value Fix
Remove the runtime socket mount — use a build service or rootless builder instead
Step by step
Values used
Containers running in the fleet = 1,200 containers; Containers running privileged = 18 containers; Containers mounting the container runtime socket = 6 containers; Containers holding CAP_SYS_ADMIN = 11 containers; Containers sharing the host PID namespace = 9 containers; Containers with a writable hostPath mount = 24 containers; Container runtime = containerd with runc on a patched kernel — 6; Seccomp profile = Unconfined — 12; SELinux or AppArmor = Permissive — 6; Age of the running kernel patch level = 140 days
Container Escape Risk
Escape points = 12 × runtime-socket mounts + 10 × privileged + 8 × CAP_SYS_ADMIN + 6 × host-PID + 4 × writable hostPath containers, normalised per 1000 containers.
Host hardening
Host hardening penalty = runtime class + seccomp + SELinux/AppArmor points + min(15, 0.05 × kernel patch age in days). Total risk = workload penalty + host penalty, clamped to 0–100.
Container Escape Risk Score
= 92.3 / 100
Risk Level
= Critical
Weighted Escape Vector Points
= 490 points
Escape Points per 1000 Containers
= 408.3
Workload Configuration Penalty
= 61.3 points
Host Hardening Penalty
= 31.0 points
How it works
Escape risk has two independent halves: what the workload is allowed to ask for, and what the host would let it get away with. A mounted runtime socket scores highest because it needs no exploit at all — you simply ask the daemon to start a privileged container — while seccomp, SELinux and a current kernel are the controls that turn a published kernel CVE into a failed syscall. Container escape converts one compromised application into a compromised node, and from there into every secret and token that node has ever mounted, which is why the multi-tenancy assumption behind most clusters depends on this number staying low.
Formulas
Container Escape Risk
Escape points = 12 × runtime-socket mounts + 10 × privileged + 8 × CAP_SYS_ADMIN + 6 × host-PID + 4 × writable hostPath containers, normalised per 1000 containers.
- escapePoints
- Weighted escape vector total
- vectorsPer1000
- Escape points ÷ containers × 1000
- workloadPenalty
- min(70, 0.15 × escape points per 1000 containers)
Host hardening
Host hardening penalty = runtime class + seccomp + SELinux/AppArmor points + min(15, 0.05 × kernel patch age in days). Total risk = workload penalty + host penalty, clamped to 0–100.
- hostPenalty
- Points for the runtime, syscall filtering, MAC and kernel currency
- kernelPenalty
- Penalty growing with how stale the node kernel is
Frequently Asked Questions
How is Container Escape Risk calculated?
Escape points = 12 × runtime-socket mounts + 10 × privileged + 8 × CAP_SYS_ADMIN + 6 × host-PID + 4 × writable hostPath containers, normalised per 1000 containers. Escape risk has two independent halves: what the workload is allowed to ask for, and what the host would let it get away with. A mounted runtime socket scores highest because it needs no exploit at all — you simply ask the daemon to start a privileged container — while seccomp, SELinux and a current kernel are the controls that turn a published kernel CVE into a failed syscall.
Why does Container Escape Risk matter?
Container escape converts one compromised application into a compromised node, and from there into every secret and token that node has ever mounted, which is why the multi-tenancy assumption behind most clusters depends on this number staying low.
What values do I need to enter?
This calculator takes 10 inputs: Containers running in the fleet, Containers running privileged, Containers mounting the container runtime socket, Containers holding CAP_SYS_ADMIN, Containers sharing the host PID namespace, Containers with a writable hostPath mount, Container runtime, Seccomp profile, SELinux or AppArmor, Age of the running kernel patch level. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Is a mounted Docker socket really that bad?
It is equivalent to giving the container root on the host. Anything that can talk to the runtime socket can create a new container with the host filesystem mounted and no restrictions, then chroot into it. There is no configuration that makes it safe — use a rootless builder such as Kaniko or Buildah, or a separate build service.
Do sandboxed runtimes remove the risk?
They substantially reduce it. gVisor intercepts syscalls in userspace and Kata gives each pod its own kernel in a lightweight VM, so a kernel bug in the guest does not reach the host. The cost is syscall latency and some incompatibility, which is why they are usually reserved for untrusted or multi-tenant workloads.
You might also need
- Container Image Vulnerability CalculatorCommonly used together
- Pod Security Risk CalculatorCommonly used together
- Kubernetes RBAC Risk CalculatorCommonly used together
- Runtime Security CalculatorCommonly used together
- Cloud IAM Risk CalculatorAlso in Cloud Security
- Cloud Security Health Score CalculatorAlso in Cloud Security