How do you ensure container image supply chain security from build to production?

Think of container image supply chain security like the pharmaceutical supply chain. A drug must be manufactured from verified raw materials in a certified facility, tested at every production stage, sealed in tamper-evident packaging, tracked through every warehouse, and verified at the pharmacy before a patient receives it. If any link in the chain is broken, contaminated, or unverifiable, the drug is rejected. Container images carry application code that processes financial transactions, so the same rigor applies in banking environments.

The supply chain starts with base images. Every container image inherits vulnerabilities from its parent image, so starting from an unvetted public image is like building a banking application on an untrusted foundation. Production teams maintain a curated internal registry of approved base images that are pre-scanned, hardened, and regularly updated. These golden images use minimal distributions like Alpine, Distroless, or UBI-minimal to reduce attack surface. The internal registry team patches base images on a defined cadence, and downstream teams receive notifications when their base image has a new version available. Dockerfile linting tools like Hadolint enforce policies such as pinning image tags to digests instead of mutable tags, avoiding running as root, and not installing unnecessary packages.

During the CI build, vulnerability scanning tools like Trivy, Grype, or Prisma Cloud analyze every layer of the built image against multiple CVE databases. The scan produces a Software Bill of Materials that lists every package, library, and dependency with known vulnerabilities. In banking pipelines, the scan result is compared against a risk policy: critical CVEs block the build immediately, high CVEs trigger a review workflow, and medium CVEs are tracked for remediation within a defined SLA. The SBOM itself becomes an audit artifact, proving to regulators exactly what components were running in production at any given time.

Image signing creates cryptographic proof that an image was built by an authorized pipeline and passed all required checks. Tools like Cosign from the Sigstore project sign images using keyless signing with OIDC identity providers, meaning the signature is tied to the CI/CD pipeline's verified identity rather than a manually managed private key. The signature and attestations are stored alongside the image in the OCI registry. Admission controllers like Kyverno or OPA Gatekeeper enforce signature verification at deployment time: any image without a valid signature from the authorized pipeline is rejected, preventing both tampered images and unauthorized builds from reaching the cluster.

The production gotcha is the gap between scanning and deployment. An image scanned as clean on Monday can have a new critical CVE published on Tuesday. Continuous scanning in the registry detects newly discovered vulnerabilities in already-deployed images and triggers remediation workflows. Another subtle risk is tag mutability: if a pipeline uses latest or v1.2 tags instead of immutable SHA digests, an attacker who compromises the registry can replace the image behind the same tag. Production registries enforce tag immutability, and admission controllers validate image digests rather than tags. Banking teams also restrict which registries pods can pull from, blocking public Docker Hub pulls in production namespaces entirely.