Your CI/CD pipeline scanned a container image. It passed. The same image is now running in production with a configuration change that was not in the scanned version. You do not know this happened.
Mutable artifacts are the integrity gap that most container security programs ignore.
The Mutable Artifact Problem
Container image tags are mutable by default. The tag app:latest today points to one image digest. After a push, the same tag points to a different image. If you scanned app:latest this morning and deployed app:latest this afternoon, you may have deployed an image that has never been scanned.
This is not a theoretical risk. It is a routine operational gap in organizations that do not enforce immutable artifact policies.
“A scan result is evidence of what was in the image at the time of scanning. If the image changes between scan and deployment, the scan result is evidence about a different image.”
Where Artifact Integrity Can Break?
Registry Tag Overwrites
Any user with registry write permissions can push a new image to an existing tag. If your deployment pipeline pulls by tag, it may deploy an image that was not the scanned artifact. This happens accidentally during hotfixes and deliberately in supply chain attacks.
Build-to-Deploy Transit
Between your CI system and your registry, and between your registry and your deployment target, an image transits several systems. Each transit is an opportunity for modification. Digest verification at each stage confirms the image has not changed.
Hardening Pipeline Output Substitution
If your pipeline includes an automated hardening step, the output of that step must be cryptographically verified before it is deployed. An attacker who can substitute the post-hardening artifact has bypassed both the scan and the hardening.
Third-Party Image Pulls
When your pipeline pulls a base image or sidecar from a public registry, you are trusting that the image content matches the image you expect. Public registry tags are mutable. Without digest pinning, your build uses whatever content the tag currently points to.
Building Tamper-Evident Artifact Pipelines
Immutable Digests as the Reference
Every container image has a content-addressed digest (SHA256 of the manifest). This digest changes when the image content changes. Use digests, not tags, as your deployment references.
Your pipeline should:
- Build image, record digest
- Scan by digest, not by tag
- Sign the digest if it passes policy
- Deploy by digest, not by tag
If the digest changes between scan and deploy, the pipeline detects it and stops.
Image Signing and Attestation
Container image security frameworks like Sigstore/Cosign allow you to cryptographically sign images and attach attestations. After your scan passes, sign the image. After hardening completes, attach a hardening attestation with the CVE reduction record.
Your admission controller can verify both the signature and the hardening attestation before allowing a pod to start. An image that has not been scanned, hardened, and signed by your pipeline cannot run in your cluster.
Attestation Chain for the Full Pipeline
Build a chain of attestations from source to deployment:
- SBOM attestation: What components are in this image
- Scan attestation: CVE assessment results and timestamp
- Hardening attestation: What was removed and why
- Signature: Cryptographic identity of the signing authority
This chain creates a verifiable record of every security action that was performed on the image. Software supply chain security at this level means you can answer, for any running container: who built this image, when was it scanned, what was hardened out, and has it changed since signing?
Runtime BOM Comparison
Even with signing and attestation, a compromised node could modify an image’s filesystem at runtime. Runtime behavioral monitoring that compares observed execution against the expected execution profile from build time detects these modifications.
If a container begins executing code that was not in its runtime profile, that is a signal worth investigating — either the image was modified or the application’s behavior has changed unexpectedly.
Frequently Asked Questions
What is container artifact integrity and why does it matter in CI/CD?
Container artifact integrity means that the image running in production is cryptographically verified to be identical to the image that was scanned and approved in your CI/CD pipeline. Without integrity enforcement, a tag overwrite, a build-to-deploy transit modification, or a supply chain injection can substitute an unscanned image while your pipeline believes the scanned version is deployed. The gap between “image was scanned” and “scanned image is running” is where most artifact integrity failures occur.
How do you ensure container artifact integrity across CI/CD stages?
Use content-addressed digests (SHA256) rather than mutable tags as your deployment reference at every pipeline stage: build the image, record its digest, scan by that digest, sign it if it passes, and deploy by digest rather than tag. Attach SBOM, scan, and hardening attestations to the signed image so your admission controller can verify the full chain of custody before any pod starts. If the digest changes between scan and deploy, the pipeline detects the discrepancy and stops.
What is the difference between image signing and image attestation?
Image signing cryptographically binds a public key identity to an image digest, proving the image was produced by your CI pipeline and has not been modified since signing. Attestations are structured records attached to a signed image that document what was done to it — SBOM contents, CVE scan results, hardening actions taken. Signing proves the image is authentic; attestations prove it has undergone the required security processes. Admission controllers can verify both before allowing a pod to run.
How can you detect if a container image was tampered with after the build?
Runtime BOM comparison detects in-production tampering by comparing the container’s observed execution behavior against the expected execution profile established at build time. If a container begins executing code not present in its build-time runtime profile — unexpected system calls, file access patterns, or network connections — that deviation is a signal either the image was modified after signing or application behavior has changed unexpectedly.
Practical Implementation Steps
- Enable digest pinning in all Dockerfiles and deployment manifests. Replace tag references with digest references.
- Integrate image signing into your CI/CD pipeline. Sign every image that passes your security gate. Reject unsigned images at admission control.
- Attach scan and hardening attestations to signed images. Store attestations in your registry alongside the image.
- Configure admission controllers to verify signatures and required attestations before pod creation.
- Implement runtime baseline monitoring to detect deviation from expected execution profiles.
The mutable artifact problem is solvable with available tools. The cost of not solving it is deploying unverified images to production while believing they are secure.
