Container Image Supply Chain

Container images are not simply packaging for application code , they are complete software artifacts that include the application code, its runtime dependencies, system libraries, operating system utilities, and the base image's entire software stack. When a vendor delivers software as a container image, the security assessment must extend to every layer of that image: the application code layer, the dependency layers added during the build process, and the base image layer that forms the foundation. Vulnerabilities in the base image's system libraries are vulnerabilities in the delivered software, regardless of how clean the application code layer is.

The base image staleness problem is the most common container supply chain failure. Base images , the foundation layers from which application container images are built , contain operating system packages and libraries that accumulate vulnerabilities over time. A vendor who builds their application on a base image and does not regularly update that base image is progressively increasing the vulnerability count in their delivered containers. The python:3.9-slim base image from four months ago has a different vulnerability profile than the same tag built today , because vulnerability publications accumulate and the base image incorporates operating system package updates when it is rebuilt, but only if it is rebuilt.

The image tag immutability misunderstanding is the specific configuration problem. Container image tags , python:3.9-slim, ubuntu:22.04 , appear to reference consistent versions but are actually mutable pointers that may be updated by the base image maintainer. An image built on python:3.9-slim today may have a different software composition than an image built on python:3.9-slim tomorrow if the base image maintainer pushes an update to that tag. Vendors who build their images on mutable tags and do not rebuild frequently may have images with stale base layers regardless of their intent to use current images.

Why this matters

Container image supply chain risk matters for TPRM because container-delivered software includes the vendor's entire software stack , including system libraries and operating system components , not just the application code. A vendor who has invested heavily in application code security while neglecting container base image currency may be delivering software with critical system-level vulnerabilities that bypass all the application security assurance the enterprise has collected.

• Application security assessed without container image assessment
• Base image age and vulnerability status not assessed
• System library vulnerabilities in containers not in standard SCA scope
• Image rebuild cadence not assessed alongside application patching
• Container SBOM not requested alongside application SBOM

What good looks like

Mature container supply chain programmes assess the full image vulnerability profile , including base image layers , using container-specific scanning tools, request container SBOMs alongside application SBOMs, require regular base image rebuilds to incorporate operating system package updates, and track container image age as a security metric.

• Container image vulnerability scanning , full layer assessment including base image
• Container SBOM including system libraries and base image components
• Base image rebuild cadence , how frequently images are rebuilt from updated base
• Image age tracking , how old the running container image is relative to latest rebuild
• Distroless or minimal base images reducing system library attack surface

Tooling

Container Scanning , Trivy, Grype, AWS ECR scanning, Google Container Analysis for full-layer container image scanning

Container-specific scanning tools assess the full image layer stack , including base image system libraries , rather than only the application dependencies that standard SCA tools cover. Trivy and Grype both support container image scanning with full layer analysis. For TPRM practitioners, asking whether vendors scan their container images using full-layer tools (rather than only application-layer SCA) provides a specific container security question.

Base Image , Google Distroless, Chainguard Images for minimal attack surface base images

Distroless and minimal base images , which contain only the application runtime and nothing else , significantly reduce the system library attack surface compared to general-purpose base images. For TPRM practitioners, asking whether vendors use distroless or minimal base images provides a specific attack surface reduction question that addresses the base image vulnerability accumulation problem.

Governance challenges

The governance challenge with container image supply chain is the rebuild discipline problem. Rebuilding container images regularly , to incorporate base image updates , requires operational discipline that competes with deployment stability. Vendors may resist frequent rebuilds because each rebuild introduces potential regression risk. The governance resolution is automated rebuild pipelines triggered by base image updates, combined with regression testing that makes frequent rebuilds operationally sustainable.

• Request container image vulnerability scan results alongside application SCA
• Ask about base image rebuild cadence , how frequently images are rebuilt
• Request container SBOM including system library and base image components
• Ask about distroless or minimal base image adoption
• Track container image age as vulnerability accumulation indicator

If you are a small team

For your vendor's most critical container-delivered software, ask for the full container image vulnerability scan results from Trivy or an equivalent full-layer scanner. Compare those results to the application-layer SCA results the vendor may have previously provided. The delta , vulnerabilities in the container scan that are not in the application SCA , is the system library and base image vulnerability exposure that the application assessment did not address. Ask how frequently the container image is rebuilt from the current base image.

• Request full-layer container scan results for critical container-delivered software
• Compare container scan to application SCA , identify base image vulnerability delta
• Ask about base image rebuild cadence
• Request container SBOM including system libraries

What to require

Ask directly:

"For your container-delivered software , do you scan the full image layer stack including base image system libraries, and how frequently do you rebuild your container images from an updated base to incorporate operating system package updates?"

Expect as evidence

• Full-layer container image scan results
• Base image rebuild cadence and process
• Container SBOM including system libraries
• Base image selection rationale , distroless or minimal preference

A vendor who confirms application security should be asked about container image security. Application SCA covers what the vendor wrote. Container scanning covers what the vendor built their code on. Both are needed for container-delivered software.

How to evidence it

• Container scan results for delivered software
• Base image currency assessment
• Container SBOM review
• Container security requirement in vendor assessment

Key Takeaway

Application: secure. Container base image: 4 months outdated, 17 CVEs, 2 critical RCEs in glibc. Application assessment: complete. Container layer: not assessed. Container images include the entire software stack , application code and the system libraries it runs on. Application SCA covers the code layer. Container scanning covers the full stack. The base image's system library vulnerabilities are the delivered software's vulnerabilities regardless of how clean the application code is. Distroless images reduce the surface. Regular rebuilds keep it current. Full-layer scanning makes it visible.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security