What it means
Build provenance attestation is verifiable metadata describing what produced an artifact, from which inputs, under what process, and in which build environment.
Why it matters
Provenance lets consumers trace an artifact to source and detect builds that bypass approved repositories, workflows, or protected infrastructure.
Practical focus
- Define the system boundary, accountable owner, approved purpose, material risks, and decision authority for Build Provenance Attestation
- Generate signed attestations in the trusted build service, bind them to artifact digests, record source revision and dependencies, and verify policy before promotion.
- Collect and protect this evidence: attestations, signatures, transparency records, source references, builder identity, verification results, and policy failures.
- Exercise this failure scenario as a planned test: a validly signed package was built from an unreviewed fork, but consumers cannot tell because only the artifact was signed.
Common mistakes
- Using the label Build Provenance Attestation without defining the exact systems, data, people, decisions, and time period in scope
- Treating a policy statement or tool demonstration as proof that Build Provenance Attestation operates consistently in production
- Failing to retain attestations, signatures, transparency records, source references, builder identity, verification results, and policy failures in a form that lets an independent reviewer reconstruct decisions and changes
- Testing only the normal path and never rehearsing what happens when a validly signed package was built from an unreviewed fork, but consumers cannot tell because only the artifact was signed.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: