Supply chain security for Kubernetes is often described as a two-step problem: verify where an image came from (provenance) and verify what it contains (scanning). Both steps are correct. Both together are still insufficient.
The missing third step is continuous verification—confirming that the workload running in your cluster today matches the hardened, verified artifact that was admitted at deployment time.
Why Admission Control Isn’t the End of Supply Chain Verification?
Admission control checks an image when it’s deployed. It can verify:
- The image has a valid signature from a trusted source
- The image meets CVE threshold requirements at deployment time
- The image has a valid SBOM attestation
Once the pod is running, admission control is done. It doesn’t monitor whether the container’s runtime behavior changes. It doesn’t detect if a container starts executing processes that weren’t in its expected profile. It doesn’t notice if a running workload is doing something the admitted image wasn’t supposed to be capable of.
The gap between admission and runtime is where supply chain attacks complete. The malicious code that slipped past signing verification—or was introduced after signing—executes in the runtime environment without triggering any re-verification.
Supply chain verification that ends at deployment is like a security checkpoint that only screens passengers at the gate, not on the plane.
Building Continuous Verification
Runtime drift detection as the third step
Software supply chain security for Kubernetes requires monitoring whether running workloads deviate from their expected execution profile. The expected profile comes from runtime profiling conducted during the hardening process: these are the processes that should run, these are the files that should be accessed, these are the network connections that should be established.
When a running workload deviates from that profile—executing processes outside the expected set, accessing files that weren’t accessed during profiling—it may indicate supply chain tampering that wasn’t caught at admission.
Runtime bill of materials as a continuous inventory
A static SBOM captures what was in the image at build time. A runtime bill of materials captures what actually executes—updated continuously as the container runs. This is a fundamentally more useful supply chain artifact because it reflects the live state of what’s running, not the build-time snapshot.
Secure software supply chain programs that include RBOM generation can answer the runtime question: “Is what’s running in production today actually the hardened image we intended to deploy?” The answer should be verifiable, not assumed.
Provenance verification throughout the deployment lifecycle
Image provenance verification happens at admission. Provenance maintenance happens continuously. An image’s provenance chain includes: who built it, what base it was built from, what hardening was applied, what CVEs were present at build time, and what CVEs have been disclosed since.
The continuous verification component tracks CVE disclosure against running images and triggers remediation when new CVEs affect packages in the runtime bill of materials.
Practical Steps for Complete Supply Chain Coverage
Implement signing and attestation as a CI pipeline requirement. Every image that leaves the CI pipeline should be signed by a key controlled by your organization. The signing step should cover the hardened image digest, not an intermediate build artifact.
Store SBOMs as OCI artifacts co-located with images. SBOMs stored separately from images become decoupled over time. Use the OCI artifact specification to attach SBOMs to image manifests. The SBOM travels with the image through promotion and deployment.
Deploy runtime monitoring with profile-based anomaly detection. Configure runtime monitoring to alert on deviations from the expected execution profile per container. New process executions, unexpected file accesses, and unusual network connections are all potential indicators of supply chain compromise.
Build re-verification triggers for new CVE disclosures. When a new CVE is disclosed, check whether any running workloads use affected packages. If they do, trigger an immediate re-hardening and redeployment. This is the runtime response to the ongoing CVE landscape.
Produce audit evidence that spans build, admission, and runtime. For compliance programs that require software supply chain evidence, the complete picture includes: the build-time SBOM, the admission-time attestation verification, and the runtime behavioral record. Collect all three and make them co-queryable for audit purposes.
Frequently Asked Questions
What is Kubernetes supply chain security and what three steps does it require?
Kubernetes supply chain security involves verifying image provenance (where it came from), verifying image content (what it contains via scanning and SBOMs), and performing continuous verification of running workloads to confirm they match the hardened artifact that was deployed. Most programs have solved the first two steps but lack continuous runtime verification—which is where successful supply chain attacks typically complete.
Why isn’t admission control sufficient for Kubernetes supply chain security?
Admission control checks an image at deployment time, verifying signatures, CVE thresholds, and SBOM attestations. Once the pod is running, admission control is done. It does not monitor whether the container’s runtime behavior changes or detect if a container starts executing processes outside its expected profile. Malicious code that slipped past signing verification—or was introduced after signing—can execute in the runtime environment without triggering any re-verification.
What is a runtime bill of materials and how does it improve Kubernetes supply chain security?
A runtime bill of materials (RBOM) captures what actually executes inside a running container—updated continuously as the container runs. Unlike a static SBOM that reflects the build-time snapshot, an RBOM reflects the live state of what is running in production. This makes it possible to answer the continuous question: “Is what’s running today actually the hardened image we intended to deploy?” and to track CVE exposure against packages that are actively executing rather than merely present in the image.
How should organizations respond to new CVE disclosures affecting running Kubernetes workloads?
When a new CVE is disclosed, check whether any running workloads use affected packages by querying the runtime bill of materials for those packages. If affected workloads are found, trigger an immediate re-hardening and redeployment cycle. New CVE disclosures against packages in actively running containers should be treated as time-sensitive remediation triggers, not as items to queue for the next scheduled maintenance window.
The Current Gap in Most Programs
Most Kubernetes supply chain security programs have solved provenance (signing, attestation) and initial content verification (SBOM, admission scanning). The continuous verification layer is where programs typically end.
This is understandable—it’s the newest and most complex layer. But it’s also the layer that matters most for detecting successful supply chain attacks. An attack that slips through initial verification has already passed your security gates. Continuous verification is what catches it before it achieves its objective.
The organizations investing in this layer now—building runtime behavioral baselines, implementing drift detection, maintaining live runtime BOMs—are building the capability that will differentiate mature supply chain programs from compliance-checkbox programs in the next two to three years.
The supply chain threat landscape has grown sophisticated enough that point-in-time verification is insufficient. The attackers have learned to pass the admission gates. The response has to be continuous.