Signed artifacts and build provenance: what a verifier checks

An artifact can carry a valid signature and still fail your release policy. It might come from a different builder, refer to an unexpected source repository, or have been produced with parameters your deployment process does not permit. “Signature verified” needs a precise meaning when it appears in documentation or a product claim.

Artifact provenance describes how an artifact was produced. Verification compares evidence against expectations for the package being consumed. The practical work is deciding what those expectations are, which component checks them, and what happens when the evidence fails to match.

The example here is a fictional release review. It contains no runnable policy or tested build pipeline. Its purpose is to make the decisions visible before a team chooses implementation details.

Separate the questions in the release check

Start with the artifact identity. The evidence should apply to the bytes you are about to use. A recognizable filename or image tag is too ambiguous for a review record if it can point to different content over time.

SLSA v1.2 verification guidance describes checking the artifact’s digest against the attestation subject, verifying the envelope, and applying configured trust in the builder. It then calls for comparison against expectations such as the source repository, build type, and external parameters.

Signature verification has its own scope. Sigstore’s Cosign documentation describes checks involving identity and issuer, as well as the image digest in the signature payload. The meaning of a successful command depends on its options and the verification policy around it.

For a reader, the useful distinction is between an observed fact and an accepted fact. “A signature from this identity is valid” records an observation. “This identity is permitted to publish our production package” depends on the consumer’s policy.

Write down the expectations first

Imagine a company deploys a fictional package called Example Collector. Its release owner maintains the following conceptual policy. These values illustrate a review method and are not configuration for any real product.

Check	Expected value or rule	Evidence to retain
Artifact	Digest of the approved release	Deployment manifest and digest
Attestation subject	Same artifact digest	Matched subject entry
Signing identity	Approved release workflow identity	Verified identity and issuer
Builder	Organization’s approved build service	Builder identity and trust configuration version
Source	Approved Example Collector repository	Canonical repository reference
Build configuration	Supported release build type and allowed inputs	Compared parameters and policy result
Decision	All mandatory checks pass	Verifier result, time, and policy version

The policy needs an owner because expectations change. Moving a build to a new service should require an intentional policy update, not an analyst clicking through an unfamiliar identity to unblock a deployment.

Record the policy version with the result. Otherwise, a later investigator may see that a release passed without knowing which expectations were active at the time.

Review the failure cases

Consider four releases presented to this fictional verifier.

Observation	Decision under the example policy	Why
Valid signature; attestation subject has a different digest	Reject	The evidence does not describe the artifact being deployed
Correct digest; recognized signer; unapproved builder	Reject pending investigation	Signing recognition does not satisfy the builder rule
Expected builder; source is an unapproved fork	Reject	Source expectations do not match
Required evidence matches; an unfamiliar build parameter appears	Hold for policy review	Its effect has not been assessed

These cases are useful acceptance criteria for a future implementation. A positive example proves little about policy enforcement unless the team also verifies the important rejection paths.

The unfamiliar parameter deserves a specific explanation. A verifier that compares only fields it recognizes can miss a new input that changes build behavior. The SLSA guidance recommends rejecting unrecognized external parameters, subject to explicitly approved exceptions. A consumer should know which fields its policy ignores and why.

Decide where the check has authority

A report generated after deployment has a different effect from a check that can stop deployment. Both can provide information, but product documentation should describe the actual response.

For Example Collector, suppose the deployment system evaluates the policy before admitting the artifact. A failed result prevents deployment and opens a review record for the release owner. That description identifies an enforcement point, an action, and an owner.

If the same tool merely sends a notification while deployment continues, write that instead. Phrases such as “ensures trusted releases” conceal this difference. An architectural diagram should show whether the verifier sits on the path that permits use or observes the result afterward.

The existing CI/CD security guide covers broader pipeline controls. Provenance verification belongs within that process alongside access control and separation of trusted and untrusted work.

Explain what the evidence leaves unresolved

An approved build can faithfully produce vulnerable software. A signature and provenance assessment do not answer every question about source behavior, malicious dependencies, or the security of a product’s design. Those questions require other evidence and controls.

Similarly, a consumer must decide which build platforms to trust. SLSA’s guidance distinguishes protection provided by a build level from compromise of the build platform itself. Avoid presenting the level as an unconditional guarantee about everyone with influence over the platform.

An SBOM adds component information to a release record. Keep the roles of inventory and provenance clear: one helps describe what is included; the other helps evaluate the production history under a defined trust policy.

Make the documentation testable

Before publishing a verification claim, ask the implementation owner for one accepted case and one rejected case for every mandatory rule. Record the product version and relevant configuration. If those examples have not been exercised, describe the intended policy without claiming tested enforcement.

A technical article can include the conceptual table above immediately. A command tutorial needs a separate implementation review: exact tool versions, successful verification output, expected failures, and cleanup instructions. The technical content review service applies that distinction when checking drafts so illustrative examples do not become unsupported operational promises.

Keep the final policy result alongside the artifact digest. A green status detached from the release it assessed cannot answer the next investigator’s first question: what was actually allowed to run?