Skip to content

Base Image Provenance Attestation

Provenance attestation — instantiates Substrate Lineage Risk Audit

Verifies and records where a base image actually came from — who built it, from what sources, by what process — so the layer everyone builds on is a checked origin rather than assumed-clean background.

Almost every service is built FROM some base image nobody on the team assembled, and that image is treated as trusted background precisely because it sits underneath everything. Base Image Provenance Attestation refuses that free pass: it attaches a signed statement of origin to the base image — the source repository, the builder, the commit, the parent it derived from — and verifies that statement when the image is consumed, so an assumed-clean layer becomes a checked one. Its defining move is that origin is attested by the producer and verified by the consumer, cryptographically, rather than inferred after the fact from a name and a tag. The output is not "this image is safe" but "this image demonstrably came from here, and here is how much we can trust that claim."

Example

A team's dozen services all build FROM company/base:latest, an image no one currently on the team has ever built. The attestation approach requires that base image to ship a signed provenance record stating its source Dockerfile repo, the CI builder that produced it, the git commit, and the upstream image it derived from. On every pull, the build pipeline verifies the signature and checks the recorded origin against an allowlist of trusted builders. The first run is the revealing one: base:latest turns out to have been last rebuilt from a personal fork nobody recognizes, by a CI job that no longer exists — signature present, but builder not on the allowlist. Provenance confidence: low. That single finding, produced before any code is scanned, reroutes every downstream service onto an attested base.

How it works

The mechanism operates at two moments and produces a graded claim, not a binary:

  • Attest at build time. The producer emits a signed statement binding the image digest to its origin: source, builder identity, build inputs, parent image.
  • Verify at consumption time. The consumer checks the signature and matches the recorded origin against a policy (trusted builders, expected sources) at pull, CI, or admission.
  • Score the confidence. A signed record from a known builder off a known source rates high; an unsigned latest from an unknown origin rates low — the score reflects how complete and trusted the chain is, not how clean the contents are.

Tuning parameters

  • Attestation strength — from an unsigned label to a cryptographically signed, keyless attestation; stronger raises assurance but demands build-system buy-in.
  • Verification strictness — how tight the trusted-builder/source allowlist is; a narrow allowlist blocks unknown origins but can stall builds on legitimate new sources.
  • Fields attested — just the parent image, or the full build inputs (source commit, build args, base-of-base); more fields deepen the origin profile at a tooling cost.
  • Enforcement point — warn versus hard-fail, and whether the gate sits at pull, CI, or admission; where you gate trades friction against coverage.
  • Attestation freshness — accept any signed record, or require re-attestation within a set window so a stale record can't stand in forever.

When it helps, and when it misleads

Its strength is turning "we think this base is fine" into a claim that is checked on every build, and it is unusually good at catching the silent base swap — a substituted image, an unknown rebuilder, a tag that quietly moved.

Its central trap is confusing provenance with safety. A perfectly attested image can be packed with known-vulnerable packages; the attestation proves where it came from, not that what came is good.[1] Reading a green attestation as a clean bill of health is the classic misuse — closely followed by running it backwards, signing whatever you already shipped so the check passes. The discipline that keeps it honest is to pair provenance with a contents-and-freshness read and to treat the confidence score as one input to the audit, never its verdict.

How it implements the components

Base Image Provenance Attestation fills the origin-verification slice of the archetype — the part that establishes where the substrate came from and how far to trust that account:

  • origin_condition_profile — records the conditions of the image's origin: source repo, builder, commit, build inputs, and parent lineage.
  • provenance_confidence_score — grades the trustworthiness of that recorded origin, from signed-and-known-builder down to unsigned-and-unknown.

It does not enumerate what the image contains or whether those contents are vulnerable — the inventory is Software Bill of Materials with Lineage's job and the vulnerability read is Transitive Vulnerability Scan's — nor does it track whether the base is still supported; that belongs to End-of-Life and Maintainer Activity Check.

Notes

Attestation fixes origin at a point in time — the moment the image was built and signed. It says nothing about what changed after the image was pulled and deployed, so it composes with Configuration Baseline Diff, which watches for drift away from that attested starting point. A green attestation and a clean diff answer two different questions; neither substitutes for the other.

References

[1] SLSA (Supply-chain Levels for Software Artifacts) is a framework for build-provenance attestations that record how and from what an artifact was produced. It is deliberately about origin and build integrity, not the absence of vulnerabilities — a high SLSA level tells you the image is what its builder says it is, not that what the builder shipped is safe. ↩