> Documentation version: 3. [HTML page](artifact-verification.html)

<a id="verify-released-artifacts"></a>

# Verify released artifacts

Use an immutable content hash as the identity of every released compiler,
package, platform, native library, tool, or other binary input consumed by
builds and tests. Record that hash in reviewed source, a lock file, or another
version-controlled manifest together with the artifact URL and release identity.

<a id="risk-artifact-admission"></a>

## 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.

<a id="separate-admission-from-routine-use"></a>

## 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](software-bill-of-materials.md#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.

<a id="routine-ci-policy"></a>

## 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.

<a id="appropriate-attestation-use"></a>

## 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.

<a id="review-checklist"></a>

## 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](linker-input-releases.md#review-and-merge-the-adoption).