Provenance Attestation vs SBOM: What Each Proves at Deploy Time

An SBOM tells a verifier what an artefact claims to contain, a provenance attestation tells it how and where the artefact was built, and a deployment gate that checks only one of them will admit software the other would have stopped. This guide is about the moment of verification: what a policy engine at a registry, an installer or a Kubernetes admission controller can actually check with each artefact, how to bind both to the same digest, and how to combine them into one decision. It does not repeat how to generate either artefact: production of provenance and the SLSA levels are in the SLSA and Build Provenance Guide, and SBOM formats and generation are in the SBOM Guide and SBOM vs SCA. It is for platform security engineers, release engineers and the people who write admission policy. Specification details reflect SLSA v1.2 and the in-toto Attestation Framework predicate list, checked on 14 November 2026.

Key takeaways

• Different questions: provenance answers "was this built by the builder I trust, from the source I expect, with parameters I recognise?"; an SBOM answers "which components and versions are inside, and are any of them banned or vulnerable?".
• Neither is evidence until it is signed and bound to the digest. An unsigned SBOM in a release folder is a claim. Wrap both as in-toto attestations whose subject is the artefact digest, signed by an identity you pin at verification.
• Provenance catches build tampering an SBOM cannot see. An injected payload in a tampered build leaves the component list unchanged; only a check of builder identity, source and parameters, ideally with an independent rebuild, has a chance of noticing.
• An SBOM catches risk that perfect provenance happily certifies. A cleanly built image that contains a known-exploited library passes every provenance check.
• Fail closed on absence. Attackers can hide attestations as easily as forge them; a gate that only rejects bad attestations, and admits images with none, verifies nothing.

What a verifier can check with each

The in-toto Attestation Framework lists both as vetted predicate types: SLSA Provenance, CycloneDX (type URI https://cyclonedx.org/bom) and SPDX 2 and 3 (https://spdx.dev/Document/v3 for SPDX 3), alongside a SLSA Verification Summary (https://slsa.dev/verification_summary/v1), vulnerability scan results and test results. That shared envelope is what makes a single verification step possible. Envelope and statement anatomy is covered in the in-toto Attestations Guide.

Threat model: what each one stops and misses

Provenance

• Stops: artefacts built on a developer laptop or an unapproved runner and pushed straight to a registry; builds from a fork or an unexpected branch; builds with injected parameters; artefacts substituted after the build (the digest no longer matches).
• Misses: malicious code that was committed to the expected repository, a compromised dependency the build legitimately pulled in, and tampering inside a trusted builder that can still sign. The SolarWinds build compromise is the reference case: the attackers injected code during the build without changing the source repository, and the result went through the normal signing process. See SolarWinds Supply Chain Compromise. Provenance from a hardened, isolated builder narrows that window and makes independent rebuilds comparable; it does not make a compromised builder honest.
• ATT&CK: T1195.002 Compromise Software Supply Chain and T1554 Compromise Host Software Binary describe the behaviours provenance verification is meant to make detectable.

SBOM

• Stops: deployment of artefacts containing components on a deny list, components with known-exploited vulnerabilities above your threshold, unapproved licences, or end-of-life runtimes.
• Misses: anything the generator did not see (vendored code, statically linked binaries, files added by build scripts) and anything malicious that is not a known component. The XZ Utils backdoor is instructive: the payload sat in release tarballs rather than the git source, inside a build macro and test files. An SBOM correctly listing "xz 5.6.1" told nobody it was malicious until disclosure, but once disclosed it let teams find every affected artefact quickly. See XZ Utils Backdoor 2024. Provenance that pins the source to a repository revision, rather than a tarball, would at least have shown the inputs differed from the reviewed source.

How verification works for provenance

SLSA v1.2 "Verifying artifacts" sets out the procedure. A deploy gate should implement it as follows.

1. Verify the envelope against configured roots of trust, confirm the statement subject matches the artefact digest and that predicateType is SLSA provenance v1.
2. Look up the builder. Match builder.id and its signing identity against your list of trusted builders and the maximum level you accept from each. SLSA says an unmatched builder defaults to Build L1, so set your policy to reject below your required level.
3. Compare to expectations. Expected builder, canonical source repository, buildType and externalParameters. SLSA says unrecognised externalParameters should cause verification to fail.
4. Decide how expectations are set. SLSA describes three models: trust on first use, expectations defined by the producer over an authenticated channel, and expectations defined in the source repository. For internal software, store expectations per package in a protected policy repository with change review.
5. Treat dependencies as best effort. Recursive checking of resolvedDependencies is optional in SLSA, and some transitive dependencies will be Build L0, so you need an exception mechanism.
6. Record the result. A Verification Summary Attestation lets a later gate rely on an earlier verification instead of repeating it.

SLSA recommends verifying at package ecosystem upload where possible, with consumer-side verification before installation or deployment, and monitors that publish results. Keyless signing shifts trust to the builder's workload identity: pin the OIDC issuer and the exact workflow or service identity, never a broad pattern. The identity controls behind that are covered in the Sigstore Guide.

How verification works for SBOMs

1. Require the SBOM as an attestation, with the artefact digest as subject and a signer you recognise. A detached SBOM file matched by name or tag can describe a different build.
2. Check who signed it. An SBOM signed by the build identity is a build-time inventory; one signed by a scanner identity after the build is an analysed inventory. Both are useful, but policy should know which it is relying on.
3. Validate structure and completeness: format and specification version, presence of component identifiers (package URL or CPE), versions and supplier, and a minimum component count for the artefact type so an empty SBOM fails.
4. Evaluate content policy: deny lists, licence rules, end-of-life components, and vulnerability thresholds, applying VEX statements so that components shown as not affected do not block. The pipeline for that is in SBOM operations.
5. Re-evaluate after deployment. Provenance is fixed at build time; SBOM risk changes daily as vulnerabilities are disclosed. Keep the attestations indexed by digest so a new advisory can be matched to running workloads.

Using both in one admission decision

The practical pattern is one policy that requires several attestations on the same digest. In Kubernetes, the Sigstore policy-controller is one example of how this is expressed: a ClusterImagePolicy matches images by glob, defines authorities (for example keyless, with an issuer and subject to pin), and lists attestations by predicateType with an optional CUE or Rego policy. Its documentation notes that an attestation listed without a policy is only checked for existence, that an image must pass every matching policy, and that images matching no policy are rejected by default, with a no-match-policy setting of warn, allow or deny. Equivalent controls exist in other admission and registry tools; the logic below applies whatever you use.

The Sigstore documentation on attestations quotes the design principle directly: systems that verify attestations must work correctly if an attacker can delete or hide attestations, so they should fail closed rather than open.

Failure modes

1. Verifying the signature, not the content. A valid signature from any identity on the public Sigstore instance proves only that someone signed. Pin issuer and subject.
2. Tags instead of digests. Policy evaluated against a tag can admit a different image than the one that runs. Resolve to digests at admission.
3. SBOM not bound to the artefact. Teams attach the release-level SBOM to every image built that week; the gate passes, but the inventory describes another build.
4. Existence checks only. Requiring an SBOM attestation without evaluating it rewards producing any SBOM, including an empty one.
5. Warn mode forever. Audit-only policies generate dashboards nobody acts on. Set a date to enforce per namespace.
6. Exemptions that never expire. Base images, sidecars and vendor operators get blanket exceptions that become the bypass.

Decision criteria

What regulators and buyers ask for

• EU Cyber Resilience Act (Regulation (EU) 2024/2847): Annex I Part II point 1 requires manufacturers to identify and document components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. Annex VII point 8 covers providing the SBOM to a market surveillance authority on reasoned request. Under Article 71 the Regulation applies from 11 December 2027, with Article 14 reporting obligations from 11 September 2026. Build provenance is not an explicit requirement, though it supports the integrity obligations. See the EU Cyber Resilience Act Guide.
• US Executive Order 14028: section 4(e) lists both maintaining data on the provenance of software code or components and providing a purchaser an SBOM for each product, plus attesting to the integrity and provenance of open source software to the extent practicable.
• OMB M-26-05 (23 January 2026): rescinds M-22-18 and M-23-16, makes the Secure Software Development Attestation Form an optional resource, and lets agencies require a current SBOM on request through contract terms. It does not mention provenance. See the CISA Secure Software Attestation Form Guide.

This section summarises the cited texts as checked on 14 November 2026 and is not legal advice.

AI models: the same split

Models raise the same two questions. An AI-BOM or model card describes contents: base model, datasets, licences (see SBOM vs AIBOM). Provenance and signing describe origin and integrity. The OpenSSF model signing project signs models with Sigstore or traditional keys, producing a Sigstore bundle containing a DSSE envelope and an in-toto statement whose subjects are file paths and digests, with predicate type https://model_signing/signature/v1.0. Verification recomputes every file hash and compares it with the signed values, and signing events are recorded in a transparency log that signers should monitor for their identity. At deploy time, apply the same rule as for containers: require a signature from a pinned identity on the exact model files, plus an inventory document evaluated against policy. See the AI Model Provenance and Watermarking Guide.

Worked scenario: a payments platform tightening admission

A payments company runs 300 services on Kubernetes. Images are built on a hosted CI platform that emits SLSA provenance, and a scanner generates CycloneDX SBOMs, which until now were uploaded to a portal as files.

• Month 1: the scanner step is changed to publish the SBOM as an in-toto attestation on the image digest, signed by the pipeline's workload identity. Admission policy in warn mode requires provenance from the two approved builder identities and a CycloneDX attestation.
• Findings: 14 images had no provenance because a team pushed hotfixes from a self-hosted runner; 9 images carried SBOMs for the wrong digest because the old portal workflow attached one SBOM per release; two vendor operators had neither.
• Month 2: enforcement turned on for the payments namespaces. Vendor operators got 60-day exceptions recorded with an owner, conditional on the vendor supplying signed SBOMs.
• Payoff: when a critical library advisory landed, the team queried SBOM attestations by digest and had the affected running workloads within an hour, while provenance confirmed every rebuilt image came from the hardened builder.

Implementation path

1. Inventory what exists: which pipelines emit provenance, which emit SBOMs, and whether either is bound to digests and signed.
2. Standardise the envelope: in-toto statements, DSSE, stored next to the image in the registry or in a transparency log.
3. Define trust roots: the builder identities and SBOM signer identities you accept, kept in a reviewed policy repository.
4. Deploy in warn mode per namespace for two to four weeks; fix producers, not the policy.
5. Enforce progressively: production namespaces first, then the rest; set no-match behaviour to deny once coverage is complete.
6. Roll back safely: switch the affected policy to warn, never delete it, and record why.

Detection and measurement

• Attestation coverage: share of running images with both a valid provenance and a bound SBOM attestation.
• Admission denials by reason: missing provenance, untrusted builder, source mismatch, missing SBOM, content policy.
• Exception age: count and median age of active exemptions; any past expiry should alert.
• Time to affected-workload list: minutes from a new advisory to a list of running digests containing the component.
• Signer anomalies: signing events for your builder identities in the transparency log that do not match a pipeline run.

Framework mapping

Practitioner checklist

• Require provenance and SBOM as signed in-toto attestations on the artefact digest.
• Pin builder and SBOM signer identities (issuer and subject), not just "signed by Sigstore".
• Store expectations (builder, repository, build type, parameters) per package under change control.
• Fail on unrecognised build parameters and on missing attestations.
• Evaluate SBOM content, not just presence, and apply VEX.
• Resolve tags to digests at admission.
• Give every exception an owner and an expiry date.
• Index attestations by digest so new advisories map to running workloads.
• Apply the same rule to AI models: pinned signature plus evaluated inventory.

Standards and references

• OpenSSF SLSA: Verifying Artifacts (v1.2)
• in-toto: Attestation Predicates
• Sigstore: In-Toto Attestations
• Sigstore: Policy Controller Overview
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
• Federal Register: Executive Order 14028, Improving the Nation's Cybersecurity
• OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
• OpenSSF: Model Transparency (model signing)

Related NHI Mgmt Group resources: Securing the SBOM management platform itself · npm Trusted Publishing and Provenance Guide · AI Supply Chain and AI-BOM Guide · Supplier SBOM Request Template