A container admission review that distinguishes image digests, signatures, build provenance, and SBOMs. It applies Sigstore and SLSA verification concepts to builder identity, source parameters, registry promotion, and explicit rejection cases.
At a glance
Key findings
- A digest identifies the artifact under review. It does not establish that the signer, builder, source, or contents meet deployment policy.
- Verify the expected signing identity and issuer as well as the provenance subject and approved build inputs. A valid signature from an unrelated identity is not approval.
- Check the artifact and its evidence at the destination registry. Successful build-time attestation generation does not prove promotion preserved it.
Name the artifact the cluster will actually pull
A release can pass a signature check and still leave a reviewer unable to say which artifact was approved. The build log names a tag, the registry tag later moves, and the deployment uses the same convenient label. Start with the digest and the intended destination registry. Approval should be attached to the artifact the cluster will resolve, not to a mutable name remembered from an earlier pipeline step.
Kubernetes documents the distinction between tags, which can move, and digests, which identify immutable image content. Its pull policy also has specific behavior: Always resolves the image name, but locally available layers can still be reused. Do not describe digest pinning as a vulnerability assessment or assume an Always policy downloads every layer on every start. Those are different questions. [1]
Record the reference used in the deployment, the resolved digest, the registry, and the release change that approved it. If the artifact is an image index, make that fact explicit rather than silently substituting an unrelated platform artifact in the review. Use the same approved subject throughout signing, provenance verification, promotion, and admission checks so each stage is evaluating a coherent release.
Separate four kinds of evidence
A signature, a provenance statement, and a software bill of materials are useful for different reasons. A signature can establish a cryptographic relationship to an accepted identity. Provenance describes a build and its inputs under a particular attestation format. An SBOM inventories components within its generation scope. None of these labels alone answers whether the artifact is acceptable for your production environment.
Write an acceptance rule for each evidence type rather than a single checkbox saying supply chain verified. For example, require the release digest to match the attestation subject, require an approved builder identity, and require the declared source location to match the intended project. Keep a separate requirement for vulnerability review if that is part of the release policy. The diagram provides a compact vocabulary for those independent decisions.
This separation also improves failure reporting. Missing provenance, an unexpected signer, a mismatched digest, and an incomplete inventory call for different repairs. A pipeline that reduces them all to verification failed makes exceptions harder to review. Preserve the failed predicate in sanitized output so the release owner can correct the evidence or request a specific, bounded exception.
Four artifacts answer four different questions
Identify the bytes, authenticate the release relationship, inspect the build, and review inventory scope as separate decisions.
Source. Kubernetes, Sigstore, SLSA v1.2, and Docker documentation [1][2][3][4][5].
Method. Original categorical comparison of documented evidence types. No trust score, inventory completeness percentage, or vulnerability measurement is implied.
Accessible table and figure data
| Evidence | Question answered | Still needs review |
|---|---|---|
| Image digest | Which bytes? | Whether those bytes are acceptable |
| Signature | Which identity signed? | Whether that signer is approved |
| Build provenance | How and where was it built? | Trusted builder and accepted inputs |
| SBOM | Which components were inventoried? | Coverage and vulnerability findings |
| Evidence | Question answered | Still needs review |
|---|---|---|
| Image digest | Which bytes? | Whether those bytes are acceptable |
| Signature | Which identity signed? | Whether that signer is approved |
| Build provenance | How and where was it built? | Trusted builder and accepted inputs |
| SBOM | Which components were inventoried? | Coverage and vulnerability findings |
Verify the expected signer and issuer
Cosign's verification guidance includes checking the certificate identity and OIDC issuer for keyless signatures. Its ordinary verification also checks the signed image digest claim. Disabling such checks changes what a successful verification means. Review the exact command or library configuration used by the pipeline, and compare it with the installed tool version instead of accepting a green log line without its predicates. [2]
The signer policy should name the release authority you intend to trust. A signature from another valid identity is not interchangeable with a signature from the approved release workflow. State how that identity can change, who reviews the change, and which environments may accept it. A development workflow and a production release workflow may share a repository while serving different authorization purposes.
Use a controlled negative case with an otherwise valid artifact signed by an unapproved test identity. The expected result is rejection for the identity condition, not a network error or a missing signature. Then check the approved case. This distinguishes a verifier that validates any available signature from a verifier that enforces the particular release relationship your organization intends to accept.
Check the build statement against an explicit policy
SLSA version 1.2 describes artifact verification using trusted roots, the attestation subject, and expectations for the build. Its guidance includes checking the builder, build type, source information, and relevant external parameters, rather than merely finding a provenance document. The root of trust and the accepted builder remain part of the policy; an attestation does not make an arbitrary build platform trustworthy. [3]
Turn those expectations into a small decision record. Name the artifact subject, approved builder, source repository, revision relationship, permitted build configuration, and external inputs that can change the output. For each field, state whether a mismatch rejects the release or requires an explicit exception. This makes it possible to review a policy change separately from a particular artifact that happens to pass it.
Be careful with parameters that can select alternate scripts, dependencies, or source locations. A trusted builder can faithfully execute an unintended build request. The review must therefore describe which inputs it accepts, not only who operated the builder. When the provenance format or build type changes, reassess those predicates instead of assuming an older field extraction still represents the same information.
Preserve evidence through the registry path
Docker documents build attestations attached through image indexes and describes exporter and image-store requirements. In particular, the classic Docker image store does not support the same attestation preservation path as a suitable containerd-backed store or supported export workflow. A locally successful build is therefore not sufficient evidence that the artifact and its attestations reached the registry used by deployment. [4]
Verify again at the destination after the normal promotion or copy operation. Record the destination reference, resolved subject, available attestations, and verification result. Use the real pipeline path in the acceptance fixture, including any intermediate registry or export step. A separate manual push that preserves the evidence does not establish that the ordinary release automation does the same.
SBOM coverage deserves its own check. Docker's SBOM guidance distinguishes the final stage from additional stages selected for scanning, and only stages that are actually built can contribute in that process. Record what the inventory covers and which build-stage inputs remain outside it. An inventory file's existence does not establish complete dependency coverage or the absence of known vulnerabilities. [5]
Make the admission decision explainable
Create a fixture with an accepted artifact and deliberate rejection cases for the wrong digest, unexpected signer, unapproved builder, disallowed source input, and missing destination evidence. Keep the cases harmless and separate from production releases. Each failure should name the predicate that rejected it, allowing a reviewer to distinguish an intentional boundary from a broken registry connection or unavailable verification dependency.
Define failure handling before admission depends on the verifier. Decide what happens when evidence cannot be fetched, a trusted identity is rotated, or the registry is temporarily unavailable. An exception should name the exact artifact, approver, reason, duration, and follow-up obligation. Avoid converting a temporary operational failure into an unbounded rule that accepts any signed image or skips provenance for an entire namespace.
Retain the accepted digest, evidence versions, policy revision, and result with the release. This creates a record another operator can inspect without replaying an opaque build log. Continue evaluating runtime configuration and vulnerability information under their own controls. Artifact provenance explains an approved production path; it does not certify that every component is harmless or that the application will be deployed safely.
Method and provenance
Primary documentation reviewed on August 28, 2026. The article combines the cited platform behavior with an original review procedure and visual explanation. Suggested acceptance cases are not reported experiments.
No registry, build platform, signer, or admission controller was tested. Verification predicates depend on the chosen tools and trust policy. An SBOM is not a vulnerability scan, and provenance does not prove the absence of malicious or vulnerable content.
AI assistance. AI assistance was used for source research, drafting, editorial checks, and figure preparation. No human technical review or production experiment is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Kubernetes container images and digest pinning Kubernetes. Accessed .
- Sigstore Cosign signature verification Sigstore. Accessed .
- SLSA v1.2 artifact verification SLSA. Accessed .
- Docker build attestations Docker. Accessed .
- Docker SBOM attestations Docker. Accessed .