Security / software supply chain / build systems · 2026-10-21

Artifact provenance: what a signed build attestation proves—and what it cannot

A release artifact can be accompanied by a signed statement describing where and how it was built. This is provenance: evidence connecting an output to a source revision, build process, and builder identity. It helps answer “what produced these bytes?” It does not, by itself, answer “were those bytes built safely?” Understanding that distinction keeps signature checks useful instead of magical.

Three separate claims often get collapsed

Integrity: a digest identifies these exact bytes, so substitution is detectable.
Authenticity: a trusted identity signed or issued a statement about the bytes.
Build trust: the source, builder, dependencies, and process satisfy policy.

A cryptographic signature can support the first two claims when keys and identity roots are properly managed. The third is a policy conclusion that depends on evidence and the trustworthiness of the build environment. A compromised release workflow can create perfectly valid signatures for malicious output.

What an attestation contains

In an in-toto-style statement, a subject names an artifact digest and a predicate carries claims about the process. SLSA provenance uses that structure to describe build definition, invocation, and materials. A verifier should bind the artifact digest to the statement, validate the signature and issuer identity, and then check that repository, revision, workflow, builder, and parameters meet explicit policy.

artifact bytes ──hash──▶ subject digest
                             │
trusted build identity ─sign─▶ provenance statement
                             │
verifier checks identity + source + builder + policy

Never treat a human-readable build URL or a package name as the binding. The binding is the digest. If the downloaded artifact has a different digest from the statement subject, the statement does not describe that file.

Threat model: the trusted builder is part of the supply chain

Suppose CI checks out the expected commit, then runs a compromised dependency or action with access to the publishing token. The pipeline may publish an altered package and attest that it came from the expected workflow. The provenance can be authentic yet faithfully describe a compromised process. Similarly, a builder with broad credentials can be tricked into signing outputs from an attacker-controlled branch.

Therefore provenance is strongest when paired with isolated, tightly scoped builders; protected workflow definitions; pinned dependencies; short-lived identity; reviewable build parameters; and independent policy enforcement. Reproducible builds add another check: an independent builder can attempt to produce identical bytes from declared inputs. Reproducibility is valuable, but it does not prove source code is benign.

Reproducible verification lab

Use a disposable public repository and a release built by a workflow that emits a Sigstore/SLSA attestation. Download the artifact and its attestation. First verify the signature and expected issuer using the project’s documented verifier, for example Cosign attestation verification. Then deliberately test failures: change one byte in a copy of the artifact; expect digest verification to fail. Verify against an unexpected repository or workflow identity; expect the identity policy to reject it. Finally inspect the predicate and record which claims your policy actually checks. Do not run verification against production credentials or install the test artifact.

# Illustrative only: use the exact command documented by the project
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp 'expected-workflow-identity' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  IMAGE@sha256:EXPECTED_DIGEST

The example is intentionally a shape, not a copy-paste recipe: verifier flags and identity formats vary by attestation format and deployment. Pin tool versions and consult current project documentation.

Operational checklist

Verify the artifact digest against the attestation subject.
Constrain signer identity to the expected repository and workflow, not a broad organization wildcard.
Evaluate source revision, builder identity, materials, and invocation against policy.
Protect workflow files and publishing permissions as production code.
Keep builder credentials short-lived and separate build from release approval where possible.
Log both accepted and rejected verification decisions; monitor unexpected issuers and workflow changes.

Takeaway

Provenance makes a software release more inspectable by linking a digest to build claims. Its value depends on checking the exact artifact, narrowing the expected signer identity, and deciding which build properties are trustworthy. Treat the builder as a security-critical dependency, not a neutral witness.