Verify released artifacts§

Risks and controls for artifact admission§

A download or cache can substitute bytes, and retrieving a fresh attestation can accidentally become a fallback for a failed reviewed hash. Separate trust admission from storage verification. Review producer evidence when adopting an input, record its identity, and compare every subsequent download/cache hit locally before extraction or execution. Negative tests include mismatched hashes and unsafe archive entries. A valid hash identifies admitted bytes; it does not prove those bytes are benign. Network provenance services have an explicit admission/audit role rather than becoming an ordinary build dependency.

Separate admission from routine use§

An attestation answers who or which workflow produced an artifact and from which source context. A content hash answers whether the bytes being consumed are the exact bytes that were reviewed. These checks belong at different stages:

1. Publish: produce the artifact, checksum, provenance attestation, SBOM, and immutable release metadata.

2. Adopt: review the release, verify its attestation and source identity, test the artifact, admit its subject-bound SBOM, and commit its content hash and URL in a reviewed change.

3. Consume: download or load the artifact, calculate its hash locally, and compare it with the reviewed pin before extraction or execution.

4. Reuse: recheck cached bytes against the same pin. A cache is storage, not a source of trust.

5. Update: repeat admission only when intentionally adopting different bytes.

After adoption, the reviewed hash authorizes the bytes used in ordinary builds. Attestation does not replace that check, and repeating a remote lookup does not strengthen the identity of already pinned bytes. A changed URL or digest requires fresh dependency review.

The SBOM records component composition and relationships; provenance records the producer and build context. Neither replaces the other or the artifact’s content hash. Follow Publish and consume software bills of materials for generation, exact-artifact scope, validation, distribution and corrections. The shared publisher verifies the files it transfers, not the accuracy of an SBOM’s component inventory.

Routine CI policy§

Routine CI and local builds must not call a remote signing, transparency, or attestation service when a reviewed content hash is available. This avoids making builds depend on service availability, rate limits, authentication, or a network response for evidence already evaluated during adoption.

A routine consumer should:

• reject a missing or malformed content hash;

• verify a newly downloaded file before moving it into a shared cache;

• verify a cached file again before using it;

• validate the archive inventory, internal manifests, target metadata, and release identity where those exist;

• extract into a temporary directory before replacing working inputs; and

• record the URL, release, and content hash in generated provenance without implying that a runtime attestation check occurred.

If the digest does not match, fail without extracting, executing, or installing the artifact. Do not fall back to a floating URL, a newly discovered release, or a remote attestation lookup.

Appropriate attestation use§

Use an attestation service during release publication, explicit lock adoption, security investigation, periodic provenance audit, or manual verification by a downstream user. Export attestation bundles with releases when practical so that provenance can be checked offline and retained independently of the service.

If policy requires provenance verification on every run despite a reviewed content hash, make that exceptional network dependency explicit and separate it from the ordinary validation path. Document its availability and credential requirements and do not describe it as content-integrity verification.

Review checklist§

Before adopting a released artifact, record evidence that:

• the release and tag are immutable and identify the intended source revision;

• the producing workflow and runner policy are acceptable;

• the attestation subject digest equals the downloaded artifact digest;

• the SBOM describes that exact artifact and target, identifies its component relationships and records any coverage gaps;

• the artifact passed its consumer-facing tests;

• the reviewed lock contains the exact URL, filename, release, and SHA-256; and

• routine CI verifies that SHA-256 without contacting the attestation service.

For a same-repository PR release, merging the reviewed generated lock is the adoption event. Follow the linker-input review and merge procedure.