Checksums, Signatures, and Provenance Solve Different Problems

Publishing a SHA-256 value beside a download is often described as “securing the artifact.” That statement skips the decisive question: how does the user know the expected digest came from a trusted source? If an attacker can replace both the file and the web page, the replacement can include a matching checksum.

Checksums, signatures, and provenance address different threats. A useful release process combines them under an explicit verification policy instead of treating any one as a universal authenticity label.

Start with the asset and attacker

The protected asset is the exact release artifact a maintainer intended to publish. Relevant threats include accidental corruption, mirror damage, unauthorized replacement, compromised build workers, stolen signing credentials, and misleading metadata.

Define the trust boundaries:

• where source becomes build input;
• where the build produces bytes;
• where a statement about those bytes is signed;
• how the artifact and statement reach the download service;
• how verifiers obtain trusted identities, keys, roots, or policy.

No control can be evaluated without this map. A signature generated on a compromised builder may faithfully authenticate a compromised artifact. A reproducible build may reproduce malicious source exactly. The residual risk belongs in the release design.

Use checksums to identify exact bytes

A cryptographic digest maps artifact bytes to a fixed-size value. Recomputing the digest after download can detect corruption or substitution relative to the expected value. It also provides a compact artifact identifier for release records.

The trust problem lies in the expected digest. Improve distribution by placing the digest in an authenticated release statement, signed manifest, or separately controlled channel. Avoid presenting a digest copied from the same mutable storage location as independent proof.

Compute digests only after the final artifact is complete. Repacking, code signing, compression, or metadata changes alter the bytes and therefore require a new digest. Name the algorithm and artifact unambiguously; do not publish one unlabeled hash beside several files.

Use the digest algorithm required by the current platform policy and ecosystem, and keep the manifest format capable of an algorithm migration. The verifier should reject an unlabeled or unsupported digest rather than guessing how it was produced.

Use signatures to authenticate a statement

A digital signature binds a statement to a signing key or identity under a verification system. The statement must identify what was signed: raw artifact bytes, a digest manifest, a container identity, or an attestation. Verifying “a signature” without checking the expected signer and artifact identity is incomplete.

For example, Sigstore's verification guidance requires verifiers to supply identity expectations such as the certificate identity and issuer in keyless workflows. That illustrates a general rule: cryptographic validity is only one part of policy validity.

A release policy should define:

• accepted signer identities or keys;
• permitted certificate issuer or trust root;
• artifact name, repository, and release context;
• signature and certificate time constraints;
• revocation or compromise response;
• threshold or separation requirements for high-risk releases.

Protect long-lived private keys with minimal access and auditable use. Keyless systems change credential management but still depend on identity providers, transparency or certificate services, and correct verifier policy.

Use provenance to describe how the artifact was built

Build provenance is structured metadata connecting output artifacts to source, dependencies or parameters, and builder information. The SLSA provenance specification defines a model for communicating that relationship.

Provenance can help answer:

• Which source repository and revision were used?
• Which builder produced the artifact?
• What build type and parameters were declared?
• Which output digests does the statement cover?
• Was the statement generated by the build service or added later?

The verifier must still authenticate the attestation and evaluate whether the builder and process meet policy. Provenance is not automatically truthful because it is well-formed. Minimize sensitive fields: do not put credentials, private URLs, personal data, or unnecessary internal topology into a public attestation.

Layer verification in the consumer's order

A practical verification sequence is:

1. Obtain the artifact and its signed statement or attestation.
2. Verify the signature against an explicit trusted identity and issuer or key policy.
3. Confirm the statement names the intended project, version, artifact, and source context.
4. Recompute the artifact digest and compare it with the authenticated statement.
5. Evaluate provenance fields against approved source and builder requirements.
6. When supported, reproduce the build independently and compare output bytes.

Fail closed for automated deployment when a required statement is missing, malformed, expired under policy, signed by an unexpected identity, or refers to different bytes. Provide a diagnostic that identifies the failed condition without printing secrets or accepting an unauthenticated fallback.

Offline verification needs a defined trust bundle and freshness policy. Caching a root or key indefinitely can ignore revocation; requiring a live service can make emergency deployment unavailable. Decide the trade-off before an incident.

Design recovery before key compromise

A credible system assumes signing credentials or identity infrastructure can fail. Document how to stop publication, revoke or distrust the affected identity, rotate trust material, reissue statements, identify impacted releases, and notify consumers.

Do not delete old evidence silently. Preserve the incident timeline and mark superseded or untrusted artifacts clearly. A new signature on old bytes may restore distribution, but it does not prove that the original build was uncompromised.

The final release claim should be narrow: exact bytes matched an authenticated statement, the signer matched policy, and the declared provenance satisfied defined checks at a recorded time. That is more useful than saying the download is simply “verified,” because readers can see which threats were addressed and which remain.