At a Glance

• Provenance answers one question: did this artifact come from the source and pipeline I expect?
• SLSA defines maturity levels (L0-L3) for build and source integrity.
• in-toto attestations package provenance as machine-readable metadata signed with Sigstore/cosign.
• Tekton plus cosign generate and sign provenance automatically inside CI.
• Admission controllers (Kyverno, OPA/Gatekeeper) can block images without valid provenance.
• Provenance closes the build-integrity gap that SBOMs and scanning alone leave open.

Container image provenance is the verifiable record of how an image was built: its source code, build environment, dependencies, and the steps that produced it. With provenance, you can prove what you ship is exactly what you built, instead of trusting a tag or digest you never audited.

What is container image provenance?

Provenance is the chain of evidence that connects a running image back to the exact commit, builder, and inputs that created it. A digest tells you the bytes are unchanged; provenance tells you those bytes were produced by a trustworthy process.

The core elements of a provenance record are:

• Subject: the artifact identity, usually a container image digest (sha256:...).
• Predicate: the claim about how it was built (builder ID, build config, materials).
• Build metadata: source repo, commit SHA, trigger, and build invocation.
• Dependencies: base images, packages, and supply-chain inputs (often tied to an SBOM).
• Signature: a cryptographic signature over the attestation, proving who issued it.

Without provenance, a perfectly scanned image can still be a malicious build from a compromised CI runner. Scanning proves what is in the image; provenance proves where it came from.

How do SLSA levels measure build integrity?

SLSA (Supply-chain Levels for Software Artifacts) is a framework that grades how resistant a build is to tampering. It gives you a shared vocabulary for "how much can we trust this artifact?"

Most teams start at SLSA L2 or L3: produce signed provenance from a hosted CI system. L4 requires a strongly isolated, reproducible build service. You do not need L4 on day one; producing any signed provenance is a large step up from trusting tags.

What is an in-toto attestation?

in-toto is a framework for authenticating the steps of a software supply chain. An in-toto attestation bundles a predicate (the provenance claim) with a subject (the artifact) and signs it. The most common predicate type for images is the SLSA Provenance predicate.

A provenance attestation is typically:

• Generated by the build service at image push time.
• Signed with a key or Sigstore (keyless, via an OIDC identity).
• Stored alongside the image in the registry or an OCI artifact.
• Verified later by humans, scanners, or admission controllers.

The practical value is that the attestation is machine-readable and policy-enforceable. You can ask "was this image built by our pipeline from commit X?" and get a signed yes-or-no.

How do you generate provenance with Tekton and cosign in CI?

Tekton is a Kubernetes-native CI/CD system whose pipelines run as pods, which makes build identity and isolation straightforward. cosign (part of Sigstore) can sign images and generate SLSA provenance, often via the cosign generate and attest commands or the Tekton Chains component.

A typical flow:

1. A git push triggers a Tekton PipelineRun.
2. The pipeline builds the image and pushes it to the registry.
3. Tekton Chains captures the build inputs and emits a SLSA provenance attestation.
4. cosign signs the image and the attestation using a Sigstore keyless identity (OIDC) or a held key. Alternatively, you can use kimia to build, attest and sign the image.
5. The signed attestation is attached to the image as an OCI artifact.

Example attestation command using cosign:

cosign attest \
  --type slsaprovenance \
  --predicate provenance.json \
  --yes \
  registry.example.com/app:latest

And to sign the image itself:

cosign sign --yes registry.example.com/app:latest

Example image creation, attestation and signing command using Kimia:

# Pass these arguments to the Kimia build container
kimia \
  --context=https://github.com/myorg/myapp.git \
  --destination=://example.com \
  --attestation=max \
  --sign \
  --cosign-key=/secrets/cosign.key \
  --cosign-password-env=COSIGN_PASSWORD

Tools like Syft (for SBOM generation) and Trivy (for vulnerability scanning) or RapidFort Analyzer (for SBOM and vulnerability scanning) slot in at build time so the attestation can reference the bill of materials and scan status. Tying an SBOM to provenance means you can later ask not just "where did this come from?" but "what known components does it contain?"

How do you verify provenance at admission?

Generating provenance only matters if something enforces it. Kubernetes admission controllers intercept pod creation and can reject workloads whose images lack valid provenance.

Common enforcement options:

• Kyverno: policy engine with native verify-image rules that check cosign signatures and attestations.
• OPA/Gatekeeper: Rego-based policies that call out to a verifier before admitting a pod.
• Sigstore policy controller: validates signatures and attestations against defined policies.

A Kyverno verify-images policy can require that any image from registry.example.com carries a valid cosign signature and a SLSA provenance attestation built by your Tekton service. If either check fails, the pod is rejected before it schedules.

Example check:

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp ".*tekton-chains.*" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  registry.example.com/app:latest

Enforcing at admission turns provenance from a report into a control. Combined with runtime tools like Falco or eBPF-based monitoring, you get both build-time assurance and runtime detection.

Why does provenance close the build-integrity gap?

SBOMs and vulnerability scanners answer "what is in this image and is it vulnerable?" They do not answer "did a trusted pipeline produce this?" An attacker who compromises a CI runner can ship a clean-looking image that was never built from your code.

Provenance fills that gap by binding the artifact to its build. The three controls work together:

• SBOM (CycloneDX/SPDX): enumerates components (Syft or RapidFort Analyzer, for example).
• Scanning (Trivy, Grype, RapidFort Analyzer): finds known vulnerabilities and maps them to EPSS/KEV risk.
• Provenance (SLSA/in-toto/cosign/kimia): proves the artifact's origin and build path.

NIST SP 800-190 and CIS Benchmarks both point toward verifying image origin and integrity as part of container hardening. Provenance is the mechanism that makes "verify origin" enforceable rather than aspirational.

RapidFort approach fits alongside these controls: RapidFort Analyzer builds a software build of materials (SBOM), RapidFort Profiler builds a runtime bill of materials (RBOM®) from actual execution, RapidFort Optimizer auto-hardens images by removing unused components, and the curated, near-zero-CVE image library ships images you can baseline from. Provenance tells you the base image came from a trusted source; hardening reduces what that image can do.

For teams adopting this incrementally: start by generating SLSA L2 provenance in CI, verify it manually, then enforce it at admission with Kyverno. Raise to L3 as your build service matures.

Container Image Provenance FAQ

What is the difference between an SBOM and provenance?

An SBOM is a list of components inside an image; provenance is a signed record of how the image was built. You need the SBOM to know what is inside, and provenance to know the artifact truly came from your pipeline. They are complementary and are often referenced together in an attestation.

Is keyless signing with Sigstore safe for production?

Yes, for most teams. Sigstore issues short-lived certificates based on an OIDC identity (your CI provider), so there are no long-lived private keys to leak. The signing certificate is logged in a transparency log. The trade-off is a dependency on the Sigstore signing service and your OIDC provider's availability.

Can I add provenance to images built outside Tekton?

Yes. cosign can attest any OCI image regardless of how it was built, as long as you can capture the build inputs. Alternatively, you can use kimia to build, attest, and sign an image. GitLab, GitHub Actions, and Jenkins all have integrations or scripts that produce SLSA provenance. Tekton is one convenient path, not the only one.

Does provenance slow down CI significantly?

Usually not. Generating the attestation is a fast step after the build, and signing with keyless Sigstore avoids key management overhead. The main cost is wiring your pipeline to emit build metadata correctly. Once configured, it adds seconds, not minutes.

How do I start if I have no provenance today?

Begin with SLSA L2: produce a signed provenance attestation in your existing CI using cosign or kimia, even if the build is not fully hermetic. Store and verify it manually first. Then adopt Kyverno or OPA/Gatekeeper to block images without valid attestations at admission. Move toward L3 as your build environment hardens.