Provenance

Software provenance records where an artifact came from and how it was produced. It supports investigation and policy decisions by connecting an immutable output digest to source, material inputs, and an authorized build process.

The conceptual model follows SLSA v1.2 Provenance, which defines provenance as verifiable information describing where, when, and how an artifact was produced. A release record identifies the actual predicate type, schema version, builder identity, and verification policy used.

Questions provenance should answer

• What exact artifact was produced?
• Which source revision and declared inputs were used?
• Which authorized process or builder produced the artifact?
• When was it produced?
• Which attestations or verification policies apply?

Verification boundary

Provenance can demonstrate traceability and help detect substitution or unauthorized build paths. It does not prove that source code is vulnerability-free, that every input is trustworthy, or that the deployment environment is secure.

Public provenance should provide useful verification data while withholding credentials, private certificates, internal trust-topology details, runner access information, and other operationally sensitive data.

Immutable subject

Provenance and attestations should name the artifact digest as their subject. Consumers should verify that the subject matches the artifact they retrieved and that the attestation satisfies the release-specific trust policy.

For an OCI image index, manifest, and platform image, the release record must make clear which digest is the attestation subject. Evidence for one platform manifest does not automatically describe every platform in an index.