Before accepting a signed container image, verify its exact digest, the expected signing identity and issuer, the authenticity and subject of any required provenance, and the build properties your policy requires. Then apply the separate release checks for vulnerabilities, compatibility, and deployment approval.
A cryptographically valid signature can fail your policy. The signer may be real but unauthorized for this release, the provenance may describe another artifact, or the build may come from a source repository you do not accept.
Define the acceptance policy before looking at the signature
Suppose a fictional service accepts images only when they are produced from its canonical source repository by its approved release workflow. The deployment team records a reviewed source revision and the digest of the candidate image. A developer's personal test build is not an authorized release, even if that developer can sign it correctly.
Write the expected facts before evaluating the candidate:
| Check | Expected evidence | What it does not establish |
|---|---|---|
| Artifact identity | Exact image manifest or index digest selected for deployment | Who produced the image or whether its contents are safe |
| Signature | Valid signature under configured trust roots | Whether the signer is an approved publisher |
| Signer identity | Expected identity and issuer, or expected trusted key | Which source and build inputs were used |
| Provenance | Verified statement bound to the same artifact | Whether every claimed build property meets local policy |
| Build expectations | Accepted builder, source, build type and parameters | Absence of vulnerabilities or application defects |
The policy belongs to the consumer. A signature, certificate, or attestation supplied alongside the image is evidence to verify against that policy, not a source from which to copy a new trust rule.
Select an immutable artifact and retain that identity
A mutable tag is convenient for discovery but insufficient as the identity of the candidate being reviewed. Resolve and record the digest, then carry that reference through verification and deployment. Otherwise, verifying a tag and deploying it later can select different bytes.
Be precise about what the digest identifies. A multi-platform image index and one platform-specific manifest are different objects. Decide which level the policy covers and how the deployed platform relates to it. Do not quietly compare the digest of one level with an attestation for another.
The distinction also matters in reproducible container builds. Repeatable inputs, matching outputs, and authenticated release origin are related controls, but none is a substitute for the others.
Preserve the candidate digest with the verification output, policy version, and release decision. If the image changes, it is a new candidate requiring the relevant checks again.
Verify the signer you actually expect
For identity-based verification, Sigstore's Cosign documentation shows both certificate identity and OIDC issuer as verification inputs. Its normal container verification also checks the image digest carried in the signature payload. These checks answer different questions: the issuer identifies the identity provider, while the certificate identity identifies the signer within that relationship.
A command shape might look like this:
cosign verify IMAGE_BY_DIGEST \
--certificate-identity=EXPECTED_RELEASE_IDENTITY \
--certificate-oidc-issuer=EXPECTED_ISSUERThe uppercase values are placeholders, not a runnable verification record. The expected identity depends on the signing arrangement; a CI workload identity is not necessarily a person's email address. Obtain the exact values from the release system's trusted configuration and the provider's documentation.
Do not broaden an identity pattern merely to get a green result. A pattern that admits any repository or branch may accept a correctly signed image produced by the wrong workflow. If the workflow legitimately changes, review and version the policy change.
Record the verifier version and trust configuration as well. This article uses documentation checked on October 28, 2026; no Cosign command was run, no registry image was downloaded, and no certificate chain was tested.
Authenticate provenance, then evaluate its contents
Provenance describes how an artifact was produced. A JSON file containing plausible build fields is only a claim until the consumer verifies its envelope, issuer or signing authority, and relationship to the artifact.
SLSA 1.2's artifact-verification guidance separates this trust assessment from checking expected build properties. It calls for checking the statement's subject digest and provenance type, then evaluating the trusted builder, canonical source, build type, and external parameters. Trust in a build level comes from the verifier's configured assessment of the builder, not a number the statement assigns itself.
Apply those expectations to the release's own build contract. If a build parameter can select an arbitrary source or inject an additional build step, accepting every possible value defeats the purpose of checking provenance. Unknown parameters need review rather than silent acceptance.
Consider these fictional candidates. The “valid signature” column assumes cryptographic verification already succeeded; the table is policy analysis, not executed cryptography.
| Candidate | Valid signature | Remaining evidence | Decision under the example policy |
|---|---|---|---|
| Approved release workflow | Yes | Expected source, revision, builder and digest | Continue to remaining release checks |
| Personal test workflow | Yes | Wrong signing identity | Reject as an unapproved publisher |
| Approved signer, different source fork | Yes | Provenance identifies the wrong source | Reject |
| Approved signer, unrelated attestation | Yes | Provenance subject differs from candidate digest | Reject |
| Approved signer, new build parameter | Yes | Parameter has no reviewed meaning in policy | Hold for review |
That last row preserves uncertainty. The parameter may be benign, but a verifier cannot treat an unexplained change as equivalent to a known build.
Know what verification leaves unanswered
Sigstore's threat model states that a signature does not establish that the signer should have signed the artifact or that the artifact is good. Its guarantees also depend on the identity system and Sigstore's trust components. A compromised legitimate identity is different from a forged signature.
Review the release workflow and its credentials accordingly. GitHub Actions permissions are part of that upstream boundary: an attacker-controlled job should not inherit the identity or authority used to publish an accepted release.
Keep vulnerability assessment, application tests, configuration review, and operational approval visible as separate results. Signing an image containing a known vulnerable package does not remove that vulnerability. An accurate build record can faithfully describe an unsafe build.
When required evidence is missing or verification cannot complete, use an explicit failure or exception path. A registry outage is not a reason to treat an unverified image as verified. An emergency exception should identify the digest, responsible authority, reason, duration, and follow-up checks.
The acceptance result should say which artifact met which policy using which evidence. Carry that same artifact into deployment, and retain the record so a later policy change or compromised identity can be traced to the releases that depended on it.
Sources checked October 28, 2026; SLSA coverage is explicitly version 1.2. All candidates and command placeholders are illustrative. No signing, signature verification, provenance validation, registry access, or deployment was executed.
