Yes, but not with the built-in CEL policies alone. A ValidatingAdmissionPolicy evaluates the incoming object, and the pod spec does not contain an SBOM. To require one, you need a validating webhook that looks up the attestation for the image digest, or a pipeline step that records the result somewhere the policy can read.
What the built-in policy can see
The Kubernetes documentation describes validating admission policies as a declarative, in-process alternative to webhooks that uses the Common Expression Language. The expressions work on the request and optional parameters. A policy can say "every container image must come from this registry" or "must use a digest", because those facts are in the pod spec.
It cannot say "this digest has an SBOM attestation", because that fact lives in the registry, not in the object. This is a limitation of where the data is, not a bug.
Three ways to enforce
| Approach | How it works | Trade-off |
|---|---|---|
| Webhook checks the registry | Webhook receives the pod, resolves each image digest, looks for an attestation | Real time check, but adds a dependency and latency |
| Pipeline marks approved digests | CI verifies the SBOM, then labels or lists the digest | Simple, but admission trusts the list |
| Policy parameter list | Policy reads an approved digest list as a parameter | In-process and fast, needs list upkeep |
The dynamic admission documentation covers webhook configuration, including timeouts and failure policy. An external lookup makes both important, since a slow registry becomes a slow deploy.
What "has an SBOM" should mean
Presence alone is weak. A policy that only checks that some attestation exists will pass an empty file. Decide what you verify.
- The attestation is bound to the exact digest being deployed.
- It is signed by an identity you trust. See what an image signature proves.
- It parses and lists packages.
- It is recent enough for your policy.
How the artifacts are attached to images matters too. See attaching SBOMs through OCI referrers.
Should you gate on it at all
Many teams start by checking in CI, where failures are cheap, and add admission later for the images that are most sensitive. Admission enforcement catches things CI cannot, such as someone applying a manifest directly with an image that never went through the pipeline. That gap is the real argument for admission checks. See should a deploy gate require an SBOM or attestation.
Roll out in stages
- Audit mode first, so violations are logged without blocking.
- Fix the pipeline gaps the logs reveal.
- Enforce in a non-production cluster.
- Enforce in production with a break-glass route.
Before you enforce, plan for registry outages. Decide whether a lookup failure denies or allows, and write down why.
Where Safeguard fits
Safeguard generates SBOM and dependency data for images and supports policies and gates, so the evidence that an admission check looks for can exist in the first place. A free scan shows the SBOM output for an image.
Quick check
Can a ValidatingAdmissionPolicy read a registry?
Not by itself. It evaluates the request object and parameters. Anything that requires a registry lookup needs a webhook or a prior pipeline step.
Is checking in CI enough?
It covers the pipeline path. Admission also covers manifests applied outside the pipeline, which CI cannot see.
Sources
Last reviewed: 19 October 2026.
