Container image provenance is verifiable information about where an image came from, which source and build process produced it, who or what signed it, and whether the artifact arriving at deployment is the same artifact that left the trusted build. Provenance is stronger than a registry tag because tags can move; cryptographic digests and attestations bind evidence to a specific image.
Within Security Engineering, provenance is the bridge between CI/CD trust and runtime admission. Sigstore Cosign can sign container images and attach in-toto attestations. SLSA defines what provenance should prove at increasing build levels and how consumers should verify artifacts against trusted expectations.
The existing supply-chain risk article provides the broader governance context.
Digest is the artifact identity that should be verified
OCI images have content digests that uniquely identify the image manifest and content graph. Deployment policy should verify the digest associated with trusted provenance, not rely only on mutable tags such as latest or prod.
A release tag can still be useful for humans, but the provenance subject should bind to the artifact digest.
This prevents a valid tag name from being repointed to a different unverified image after approval.
A signature proves integrity and signer identity under a trust policy
Cosign can sign container images using key-based or keyless workflows. Sigstore’s keyless model uses short-lived certificates tied to an identity and records signing evidence through its transparency infrastructure.
Verification must check the identity and issuer the organization expects—not merely whether “some signature” exists.
A valid signature from an untrusted personal identity should not satisfy a production policy intended to trust one CI workload identity.
Attestations carry claims beyond the signature
A signature can show who signed an artifact. An attestation can include structured claims such as build provenance, SBOM, vulnerability results, or custom policy evidence.
Cosign supports in-toto attestations and predicate types including SLSA provenance, SPDX, CycloneDX, vulnerability, and custom formats.
Admission policy can therefore ask not only “is this signed?” but “does the image have the required provenance and does that provenance meet expectations?”
SLSA provenance records how the artifact was built
SLSA 1.2 defines build provenance as verifiable information about where, when, and how an artifact was produced. Higher build levels increase integrity guarantees around provenance generation and build isolation.
SLSA Supply Chain Levels explains Build L1 through L3 and the newer Source track separately.
Provenance should include enough information to compare the observed build against what the producer considers a valid build.
Verification requires expectations
Provenance does nothing if nobody verifies it. SLSA verification guidance recommends checking builder identity, signature authenticity, canonical source, build type, and external parameters against expected values.
Those expectations should be stored in policy rather than decided manually during every deployment.
For example, production images may be required to come from one repository and one approved hosted builder with no unrecognized build parameters.
Registry storage should preserve related security artifacts
Modern OCI registries can store signatures, SBOMs, and attestations alongside images through OCI artifact/referrer mechanisms.
The release process should ensure the evidence is replicated or retained with the image when artifacts move between registries or environments.
An air-gapped deployment that copies only the image and leaves all provenance behind loses the verification material at the point it matters most.
Admission should reject untrusted images before runtime
Kubernetes or another deployment platform can verify signatures and attestations before accepting an image.
Sigstore policy-controller and other admission systems can express rules about signer identity and required attestations.
Policy should fail closed for production-critical trust requirements unless an emergency exception process is explicitly designed.
Rebuilds should produce new provenance even from identical source
A rebuilt image may use a different base image, dependency resolution, build platform, compiler, timestamp, or configuration even if the application source commit is unchanged.
Each output digest should therefore have its own provenance.
Reproducibility can provide additional confidence, but provenance should not be copied mechanically from one build to another.
Base images and dependencies extend the trust chain
Application provenance proves how the application image was built, but the build still consumes base images, packages, and dependencies.
SBOMs and recursive provenance can help identify those dependencies, while SLSA’s broader direction aims to strengthen trust across the chain.
The production policy should define how much upstream evidence is required for critical images rather than assuming one signed top-level image proves every dependency is safe.
Revocation and compromised signer response should be rehearsed
If a CI workload identity, signing key, build platform, or registry is compromised, the organization needs a way to identify affected images and reject future use.
Transparency logs and short-lived signing certificates improve evidence, but incident response still needs an inventory of which artifacts were signed or built under the compromised identity.
Provenance becomes operationally valuable when it can answer “which releases should we distrust now?”
Image provenance is successful when deployment can prove origin automatically
The mature pipeline builds on an approved platform, generates provenance, signs or authenticates that provenance, stores it with the artifact, verifies it against producer expectations, and blocks deployment when the evidence does not match policy.
That moves supply-chain trust from “we recognize this registry tag” to verifiable statements about the artifact’s source and build.
Builder identity should be tied to a workload identity, not a shared signing credential copied into many pipelines. Keyless signing is attractive because the CI system proves its identity at signing time and receives short-lived signing material. This makes signer policy about the workload that built the image rather than possession of one long-lived private key.
Provenance should be generated by the build platform rather than written by the application build itself. If arbitrary build steps can create whatever provenance they want and sign it with the same privileged key, the attestation cannot provide strong evidence against a compromised or malicious build.
Verification policy should distinguish environments. Development may allow unsigned images for local testing, while staging requires a trusted builder and production requires both signed provenance and an approved source branch. Clear environment policy avoids training developers to bypass production controls just to iterate quickly.
Image promotion should preserve digest identity. Promoting from staging to production should move or reference the exact verified image digest rather than rebuild from the same source commit. Rebuilding creates a new artifact with new provenance and can introduce changed dependencies even when source code is unchanged.
SBOM and vulnerability attestations should be versioned separately from build provenance. A vulnerability scan can become stale as new CVEs are published even though build provenance remains valid forever for that artifact. Deployment policy may require fresh vulnerability evidence while still relying on the original immutable provenance.
Incident response should include provenance queries. When one build runner, base image, or dependency is compromised, teams should be able to search attestations and SBOMs for affected digests, block those artifacts, and trigger rebuilds from trusted infrastructure. Provenance is most valuable when it accelerates that scope determination.
Provenance policy should account for emergency builds. During an incident, teams may need to patch quickly, but the emergency path should still use an approved builder and generate attestations automatically. A “break glass” process that disables all verification can create a supply-chain opening exactly when attention is already divided.
Source references should be immutable. Provenance that says an image came from branch main is less useful than evidence tied to a specific commit digest. Verification expectations can still require that the commit belongs to an approved branch or tag, but the artifact should trace back to one immutable source revision.
Build parameters matter when they influence security. Feature flags, compiler options, dependency mirrors, base image references, target architecture, and release mode can all change the artifact even from the same source. SLSA external parameters help make those inputs visible to verifiers.
Registry permissions should separate artifact upload from provenance policy administration. A compromised publisher credential should not also be able to rewrite the trusted builder policy or disable admission verification. Distinct control planes reduce the chance one credential can both introduce and authorize an untrusted image.
Consumers should decide what happens when verification fails. Production may reject the image, quarantine it, or require a signed exception. Logging and alerting should include the failed expectation—wrong builder, unsigned provenance, unexpected source, or missing attestation—so teams can fix the actual trust break quickly.
Cross-architecture images need careful subject handling. Multi-platform image indexes can reference separate manifests for amd64, arm64, and other architectures. Verification policy should make clear whether provenance covers the index, each platform-specific image, or both.
Promotion across registries should verify evidence after copy. Registry replication tools can occasionally omit referrers, signatures, or attestations depending on implementation. A post-copy verification step proves the destination still contains the artifacts required by admission policy.
Security teams should also monitor signer identities over time. A release signed by a deprecated CI identity may still be valid historically but should not satisfy a new policy if that workflow is no longer approved. Trust policy evolves even when the old signature remains cryptographically correct.
Container provenance is mature when producers can generate evidence automatically and consumers can reject deviations automatically. Human review should focus on policy changes and exceptions, not on manually inspecting every ordinary release.
