A CI vulnerability scan tells you what's inside an image. It can't tell an auditor where the image came from, which pipeline built it, or whether someone deployed a different image straight to production. Container supply chain security that holds up to that scrutiny needs three checkpoints: verified image intake, build-time enforcement, and runtime admission control in Kubernetes. Each checkpoint blocks images that don't meet policy and leaves evidence you can show. This article explains what each layer catches, what proof it produces, and how the three combine into a chain of custody for the images you run.

Where a single security checkpoint leaves gaps

Many organizations rely on one control: a vulnerability scan in CI. That scan is useful, but it only covers images that pass through CI. Several common paths skip it:

• Direct deployments. An engineer runs kubectl or applies a Helm chart that references a public image. The image never touches your pipeline.
• Third-party images. Databases, load balancers, and vendor images often go straight from a public registry into the cluster.
• Post-scan changes. A registry tag can point to a different image after the scan runs, and the original scan report won't reflect the swap.
• New upstream code. A base image pulled the day a new version ships brings in code nobody has evaluated yet. A clean scan means no known CVEs, which says nothing about code published that morning.

A scan report also describes an image's contents at one moment. It doesn't establish origin, build process, or integrity, which are the things auditors ask about.

What auditors and customers ask you to prove

Security questionnaires and audits increasingly ask about software supply chain controls, e.g. FedRAMP, NIST SP 800-53, DISA STIGs,FIPS 140-3, etc . The questions come down to five:

• Where did this image come from?
• Was it built by an approved pipeline?
• Has it changed since it was built?
• What software does it contain?
• Can anything unapproved run in your clusters?

A vulnerability scan answers part of the question about contents. The rest require cryptographic evidence that travels with the image: signatures that prove origin and integrity, provenance attestations that record how and where the image was built, software bills of materials (SBOMs) that list its contents, and admission policies that show what the cluster will run.

The layered model below produces this evidence during normal operation. Your team doesn't assemble it by hand before an audit, because the pipeline and the cluster generate it each time an image moves through them.

How three layers close the gaps

Layer 1: Verify images at intake

The platform team curates base and third-party images from RapidFort instead of public registries, ensuring they are free of malware, pre-scanned, and have near-zero CVEs.

Images are verified with Cosign, customized with standard layers, signed, attested, and stored in an internal registry as the sole approved source. For a detailed walkthrough of this stage, read more about image intake in Container image governance without slowing developers.

Layer 2: Enforce trusted sources at build time

Development teams build application images on top of the approved base images. Their CI pipelines enforce this with a Dockerfile linter such as Hadolint, configured to reject any FROM instruction that references a registry outside the approved list. A build that starts from python:3.14 on a public registry fails on line one.

The pipeline scans images that pass linting to generate an SBOM and identify known vulnerabilities and Security Technical Implementation Guide (STIG) findings. It then attests the image's provenance, signs it, and pushes it to the registry. Each application image leaves the pipeline with a signature, a provenance attestation, an SBOM, and scan results attached.

Layer 3: Admit only verified images at runtime

Build-time controls don't cover images that bypass CI, so the cluster needs its own check. A Kubernetes admission controller such as Kyverno or Gatekeeper evaluates each Pod request before the cluster accepts it.

A registry policy denies any Pod whose containers, init containers, or ephemeral containers reference an image outside the internal registry. That closes the kubectl and Helm gap. Kyverno can also verify image signatures and require valid attestations, checked against trusted authorities or CI identities. An image that's unsigned, tampered with, or built outside an approved pipeline doesn't run, and policy reports record what the controller allowed and denied.

How the layers form a chain of custody

Each layer covers gaps the others can't. Intake controls what enters the organization, build-time checks control what developers produce, and admission control stops anything that went around the first two. Together, they give you a record for each image from source to runtime.

When an auditor asks where an image came from, you point to its signature and provenance attestation. When a new CVE is published, the SBOMs show which images include the affected package. When a customer asks whether anything unapproved can run in production, the admission policy and its reports answer the question.

For more on how RapidFort supports compliance programs, see RapidFort compliance solutions.