# What Is a Software Supply Chain Attestation?

Source: https://www.testifysec.com/blog/what-is-a-supply-chain-attestation/

Author: Cole Kennedy

Published: 2021-10-20

Updated: 2026-10-06

A statement about an artifact is useful when its producer, scope, and verification rules are explicit.

Editorial update · October 6, 2026

Revised by TestifySec Editorial to remove unsupported outcome claims and explain the current product and trust boundaries. The original publication date and URL are preserved.

- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

An attestation is a statement about an artifact or an event. In a software supply chain, it might describe a build, a test result, or the inputs used by a tool. A signed attestation lets a verifier check who signed the statement and whether it has changed.

 

It is not a certificate that the software is safe. A signed false claim remains false.

 

## Why provide attestations for software?

 

A consumer needs more than an artifact name to decide whether a release meets its requirements. Evidence can identify the exact artifact, the producer, and the results the consumer’s policy expects. The [in-toto statement format](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md) gives these claims a structured representation using subjects, digests, and typed predicates.

 

## What can I do with an attestation?

 

You can compare recorded evidence with a defined policy: require a scan of the exact artifact, accept only an expected producer, or reject a missing result. The policy must run at the decision point that depends on it.

 

The verifier also needs a trust model. If the actor doing the work controls the observer and signing authority, it may fabricate a convincing record. Producer isolation and authenticated identity matter independently of the format.

 

## What should the evidence describe?

 **Materials** identify the inputs observed by a step. **Products** identify its observed outputs. **Process information** can describe the invoked command and its result. **Environment observations** provide relevant context within the collector’s scope. 

These are useful categories, not a rule that exactly four attestations prove every build. A digest identifies content; it is not an authenticated workload identity. Environment metadata is not automatically remote attestation of an entire machine.

 

## Example: a compiler invocation

 

A record can bind a source digest, a configured compiler invocation, and the output digest. That gives a reviewer a specific claim to evaluate. It does not prove reproducibility, capture every hidden input, or establish that the compiler was uncompromised.

 

## Example: a security scan

 

Bind the result to the exact source or artifact scanned. Retain the scanner version, relevant configuration, and result where available. A clean report supports the test’s defined scope; it does not establish that the artifact has no vulnerabilities.

 

## What is the difference between an SBOM and an attestation?

 

An SBOM describes software components. An attestation makes a claim about a subject and may carry an SBOM as its predicate or refer to one. An SBOM can exist without a signature or an attestation. These are related but distinct concepts.

 

## How do I create attestations?

 

For open-source Witness workflows, use the [Witness documentation](https://witness.dev/). For TestifySec’s enterprise workflow, start with [CI/lock](https://www.testifysec.com/docs/cilock/getting-started/first-attestation). Pushgate checks the push, and the platform manages multiple gates and technical control evidence. Read the [trust model](https://www.testifysec.com/docs/cilock/trust) before deciding which producer a gate should accept.