A software signature needs an identity, an artifact, and an acceptance policy

The documented foundation

SLSA describes provenance as verifiable information about where, when, and how an artifact was produced. Its verification guidance includes checking signatures, matching the artifact digest, and comparing builder and build parameters with expectations.

Sigstore's Cosign documentation shows identity-based verification using an expected certificate identity and OpenID Connect issuer. It also describes checking that a container signature's digest matches the image. These checks connect a claim to an artifact and an identity; they do not replace a decision about whether that software should be used.

Source: SLSA v1.2: Provenance · SLSA v1.2: Verifying artifacts · Sigstore: Verifying signatures

Analysis: Authenticity is a question with an object

The statement that something is signed leaves several useful questions unanswered. Which exact object was signed? Which identity made the statement? Which authority or key establishes that identity? What does the statement claim? A review becomes clearer when those questions are answered separately.

Imagine a hypothetical organization expecting a release from a particular project. A valid signature from an unrelated identity would not meet that expectation. A valid signature over a different artifact would not establish the authenticity of the file about to be installed. Even a correctly matched release could contain an ordinary programming error. The usefulness of a signature therefore comes from its role in a specific verification decision, rather than from the presence of a badge.

Provenance adds a production story

A production record can let a consumer compare how an artifact was built with the process they expected. SLSA's guidance calls for expectations about the builder, canonical source repository, build type, and external parameters. Those expectations give the record something meaningful to be checked against.

For a practical thought experiment, suppose a project normally publishes from one approved source location. A record identifying a different location would deserve review even if the artifact carried a valid signature. The issue would be a mismatch with the expected process. This illustrates why collecting more metadata is not the same as using it: the consumer needs a policy that can turn a relevant difference into a decision.

Source: SLSA v1.2: Verifying artifacts

Analysis: Protect the expectations too

A verification policy can become the most important document in the process because it defines what counts as acceptable evidence. If the expected identity or source can be changed without appropriate review, a technically correct verifier might faithfully enforce the wrong expectation.

A useful governance pattern would assign ownership to the policy, record why changes are made, and preserve the policy version used for a release decision. This is a proposed operating practice, not a claim about a particular service. It makes later analysis more precise: a team can ask whether the artifact violated the intended policy, whether the policy was changed, or whether the policy omitted a condition that mattered.

Plan for missing or failed verification

A workflow needs a defined outcome when evidence is absent, invalid, or inconsistent. Otherwise, verification can become an informational step that nobody knows how to act on. SLSA explicitly notes that detecting failures has limited benefit unless a person or system responds.

An illustrative rollout could begin by observing failures and classifying their causes before enforcing a policy for a defined set of releases. The important requirement is that an exception be visible and owned. An emergency process should describe the scope and duration of the exception, plus the evidence needed to close it. This prevents an unresolved operational difficulty from quietly becoming permanent acceptance of missing information.

Source: SLSA v1.2: Verifying artifacts

What signing cannot promise

Signing and provenance support particular claims about identity, integrity, and production. They do not prove that the source code is free of defects or that a trusted build platform can never be compromised. SLSA's guidance keeps trust in the platform as an explicit assumption.

For a reader assessing a software-supply-chain claim, the useful question is what was verified before use. A clear answer names the artifact, trusted identity, relevant production expectations, and the consequence of a mismatch. That account is more informative than a claim that a pipeline is secure because it emits signatures. It makes the controls inspectable and leaves the remaining responsibilities, including code quality and platform trust, visible.

Keep the verification record alongside the release decision so later reviews can reconstruct its basis.

Source: SLSA v1.2: Verifying artifacts