How GPU Containers Differ from CPU Containers: The Five Layers and What Traditional Tools Miss
For executives
GPU containers have five security layers, and traditional tools see only two. This article explains what those five layers are, what each one contains, and which monitoring approaches cover which layers. It is the conceptual foundation for understanding why GPU security requires dedicated instrumentation rather than simply extending CPU container security to GPU infrastructure.
The five security layers of a GPU container
Layer 1: Image and build
The container image — the filesystem snapshot that becomes the container's view of the world. This layer includes the base OS, installed packages, application code, model files, and content baked into the image at build time.
What attacks live here: malicious packages, compromised base images, embedded malicious code, unpatched OS packages. What monitoring covers it: container image scanning, SBOM tools, vulnerability management platforms.
Traditional tools see this layer.
Layer 2: Container runtime processes, syscalls, and network
The running processes inside the container, their system calls, and the network connections they make.
What attacks live here: process injection, suspicious process execution, unexpected network connections. What monitoring covers it: eBPF probes, seccomp profiles, Falco rules, network monitoring.
Traditional tools see this layer.
Layer 3: GPU device -- NVIDIA toolkit, drivers, MIG
The software layer between the container and the GPU hardware: the NVIDIA Container Toolkit hooks, the GPU driver, and MIG configuration.
What attacks live here: OCI hook exploitation (CVE-2025-23266, CVE-2024-0132), driver privilege escalation (CVE-2026-24187, CVE-2025-23244), MIG partition violations, Device Plugin API bypass (CVE-2024-0135).
Traditional tools do not see this layer.
Layer 4: GPU execution -- CUDA kernels, contexts
The GPU-side execution environment: CUDA contexts, loaded GPU modules, kernel execution, and GPU memory operations.
What attacks live here: cryptomining kernels, malicious GPU modules, cross-context memory access, GPU memory snooping, Rowhammer-based VRAM attacks.
Traditional tools do not see this layer.
Layer 5: AI workload -- models, inference, training
The application-level AI workload: the model being served, the inference requests being processed, the training data being consumed, the gradients being computed.
What attacks live here: model weight exfiltration, inference-time model inversion, training data poisoning, gradient leakage.
Traditional tools partially see this layer — application-level monitoring exists — but the GPU-level signals most informative for this layer are not available to traditional tools.
The monitoring gap map
Layers 1-2: covered by traditional tools. Layers 3-4: not covered by traditional tools. Layer 5: partially covered by traditional tools, with GPU-specific signals missing.
The Container Toolkit vulnerabilities (the most actively exploited category) live at layer 3. The GPU driver vulnerabilities live at the boundary between layers 2 and 3. Cryptomining lives at layer 4. Model theft spans layers 4 and 5.