SBOM Gaps and Supply Chain Privilege Escalation: Invisible Components, Invisible Risk
For executives
A Software Bill of Materials (SBOM) is supposed to tell security teams what is in a container — which libraries, which versions, which dependencies — so that known vulnerabilities can be identified and patched. The problem is that GPU containers contain components that standard SBOM tools do not see. CUDA runtime libraries installed without a package manager, proprietary NVIDIA driver compatibility libraries bind-mounted from the host, and GPU kernel modules that live on the host rather than in the container are all part of the effective attack surface of a GPU container but absent from its SBOM. An SBOM that is incomplete is a false sense of security.
What a GPU container SBOM typically contains
When an SBOM tool scans a GPU container image, it typically discovers: OS packages installed via apt, yum, or similar package managers; Python packages installed via pip that are registered in pip's package database; and system libraries that have package manager entries.
For a typical deep learning container, this covers the application code, its Python dependencies, and the base OS packages.
What it misses
The CUDA runtime libraries that NVIDIA includes in its official base images are installed by NVIDIA's own installation scripts, which do not always create standard package manager entries. libcuda.so, libcublas.so, and similar libraries may be present in the container's filesystem but invisible to SBOM tools that rely on package manager databases.
The NVIDIA Container Toolkit — the component in 100% of GPU containers that the entire CVE vulnerability series in this library targets — is installed on the host, not in the container. It does not appear in the container's SBOM at all.
Driver compatibility libraries bind-mounted from the host at container runtime are not part of the container image. They appear in the container's runtime environment but not in its static image SBOM.
The NVIDIA GPU driver kernel module is a host component entirely. Its version is not represented in any container-level SBOM.
Why this matters for vulnerability management
Vulnerability management workflows that use SBOMs to identify which containers are affected by a newly disclosed CVE will systematically fail for GPU infrastructure CVEs that affect host components:
A Container Toolkit CVE (CVE-2025-23266, CVE-2024-0132, etc.) is not visible in any container's SBOM because the Container Toolkit is a host component. A GPU display driver CVE (CVE-2026-24187, CVE-2025-23244, etc.) is not visible in any container's SBOM because the driver is a host kernel module.
Security teams relying on container SBOM scanning alone will not be alerted to these vulnerabilities by their standard tooling. The affected component simply does not appear in the SBOM.
The supply chain privilege escalation path
The SBOM gap enables supply chain privilege escalation: an attacker introduces a malicious version of a component that SBOM tools do not see. A malicious CUDA library installed by a compromised NVIDIA setup script in a base image build pipeline is not registered in the package manager and therefore invisible to SBOM scanning. A container that loads the malicious library at runtime gains whatever capability the attacker embedded.
A compromised k8s-device-plugin image on a Kubernetes GPU node carries known OS package CVEs that go unpatched across minor releases. An attacker who controls the package source for one of those OS packages can introduce a malicious update that reaches the k8s-device-plugin and executes on GPU nodes with the plugin's privileges.
What complete GPU infrastructure vulnerability management requires
Effective vulnerability management for GPU infrastructure requires monitoring at three levels: container image contents (standard SBOM), host component versions (Container Toolkit, GPU driver, GPU Operator, k8s-device-plugin), and runtime telemetry (what is actually executing, regardless of what the SBOM says). The third is the compensating control for the first two: if a malicious component reaches execution, runtime monitoring at the CUDA and driver layer provides detection signal that static SBOM analysis cannot.