They can feed different content at different verification steps. If the registry returns one manifest for signature checking and another for the final pull or mutation, the policy validates one image while the cluster runs another. That breaks the assumption that the verified artifact is the one actually deployed, which can expose pods, service account tokens, and API access.
Why signed image policies are only as strong as the registry and proxy path
Signed image policies assume the thing being verified is the same thing that will be pulled, mutated, and executed. A malicious registry or proxy can violate that assumption by serving different content at different stages, which turns signature validation into a check on one artifact while the cluster later consumes another. That is a registry integrity problem, not just an image trust problem.
This matters because the policy decision is made against registry responses, not against an abstract image name. If the registry or an intermediary can alter manifests, layers, or metadata between verification and pull, the signature may still be valid for the verified object while the runtime workload receives attacker-chosen content. The policy becomes a control over a representation, not over the deployed binary.
That gap is especially dangerous in platforms where image admission is meant to prevent untrusted code from reaching production. Once the verified artifact is no longer the deployed artifact, downstream controls such as runtime isolation, service account scoping, and network segmentation are forced to absorb a failure that should have been stopped earlier.
- Registry-to-runtime consistency is the key security property, not signature presence alone.
- Any mutation layer between policy evaluation and image pull expands the trust boundary.
- Digest pinning helps only when the entire retrieval path preserves artifact integrity end to end.
How registry and proxy manipulation breaks the verification model
There are a few common failure modes. A registry can present one manifest during policy evaluation and another during the final pull, or it can rewrite referenced layers after a signature check has already passed. A proxy can also cache, transform, or redirect content in ways that preserve the appearance of a valid image reference while changing what is actually delivered. For container supply chains, NIST SP 800-190 Container Security is a useful reference for the image, registry, orchestrator, and runtime trust boundary, and SLSA reinforces the need for provenance and integrity across the build and delivery chain.
The practical issue is that signed image policies usually validate a descriptor, digest, or artifact relationship at one point in time. If the registry path is not trusted to remain stable, the policy can validate the wrong view of the image. That creates a classic time-of-check to time-of-use problem, but with software supply-chain consequences rather than a simple race condition.
When this happens, the cluster may launch code that was never part of the trusted verification event. In the worst case, that code can be crafted to expose pod tokens, abuse mounted credentials, or pivot into APIs that the workload was never supposed to reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS — Data Security | Signed image trust depends on preserving artifact integrity across the delivery path. |
| PR.AC — Access Control | Image retrieval and deployment trust should be constrained so only approved paths can influence runtime artifacts. | |
| DE.CM — Continuous Monitoring | Detecting registry or proxy tampering requires monitoring for content drift between verification and pull. | |
| Recommendation — Protect image artifacts and digests so the verified object remains unchanged from policy check to runtime pull. Limit who and what can modify registry content, proxy behavior, and deployment inputs. Monitor for digest, manifest, and runtime-content mismatches in the image delivery chain. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Image and registry mutation risk is reduced by enforcing trusted, immutable software delivery paths. |
| 15 — Service Provider Management | A malicious registry or proxy is a third-party trust dependency that must be controlled. | |
| Recommendation — Enforce immutable image sources and restrict intermediary rewriting in software deployment paths. Assess and monitor registry and proxy providers as trusted delivery dependencies. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The attack abuses trusted delivery infrastructure to replace or alter software before execution. |
| Recommendation — Model the registry or proxy as a supply-chain compromise path and hunt for altered delivery artifacts. | ||
Practitioner Guidance
What to verify: Treat registry and proxy integrity as part of the control, not an external assumption. Validate that the exact digest, manifest, and referenced layers seen by the policy engine are the same objects the runtime later fetches, and require that path to be resistant to mutation, rewriting, or content negotiation.
What practitioners underestimate: Many teams overfocus on signature verification and underfocus on transport and intermediary behavior. A signed image policy can still be bypassed operationally if the delivery path can swap artifacts after verification or present different content to different consumers.
Decision rule: If you cannot prove end-to-end artifact consistency from verification to pull, treat the registry or proxy as part of the attack surface and do not rely on signature policy alone for deployment trust.
Practitioner takeaway: Signed image policies only deliver real assurance when the registry path is integrity-preserving; otherwise, the policy protects a claim about an image, not the image that actually runs.
Related resources from NHI Mgmt Group
- Why do malicious packages in developer workflows create such high risk?
- Why do malicious open source dependencies create such a high-risk failure mode for application security teams?
- Why do malicious commits and poisoned dependencies create such high risk in modern DevSecOps environments?
- Why do malicious Parquet files create such a high-risk attack path in analytics and ML environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
