A repeated manifest fetch creates a classic time of check to time of use flaw. The admission controller may verify a benign image, then receive a different manifest when it rewrites the pod spec. That opens a bait and switch path where an unsigned or malicious image is admitted even though signature verification appeared to succeed.
Why repeated manifest fetches break verification
Container image verification only stays trustworthy when the artifact being checked is the same artifact being admitted. If the manifest is fetched twice, the verifier can examine one version and then act on another, so the signature or digest check no longer binds the final image reference. The result is a classic race condition in supply-chain trust, not a cryptographic failure.
That failure is especially dangerous in admission workflows that rewrite pod specs, because the controller may validate a benign manifest first and then substitute a different one during the later use step. In practice, the security property you wanted, “the admitted image is exactly the one that was verified,” has been lost.
The underlying issue is that verification is supposed to be a single, stable observation of the artifact. Once the manifest is re-resolved, mutable tags, registry updates, or network and registry timing differences can create a bait-and-switch path. The control may still appear to succeed, but it is now checking a moving target.
For container trust boundaries, this is why digest pinning, immutable references, and one-time fetch semantics matter. The point is not merely to “verify images,” but to verify the exact object that will be deployed and to prevent any later lookup from changing that object’s identity.
Risk and Threat Considerations
Repeated manifest retrieval creates a control gap between verification and deployment, which can let a benign image be replaced by a different manifest after the security check has completed. That turns an integrity control into a timing-sensitive dependency, and attackers only need one successful race or registry mutation to exploit it.
Failure mechanism: The verifier checks one manifest, then the admission path resolves or rewrites the image reference again, allowing a mutable tag or changed registry response to bypass the original trust decision.
Impact: A cluster can admit an unsigned, altered, or otherwise unreviewed image even though signature verification appeared to succeed, expanding the blast radius from a single workload to the broader runtime environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Controls software integrity and secure delivery for container images. |
| Recommendation — Enforce immutable image references and verify artifact integrity before deployment. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Protects the integrity of software artifacts and deployed content. |
| PR.AC — Access Control | Admission paths must enforce the right artifact can be introduced into runtime. | |
| DE.CM — Continuous Monitoring | Repeated fetches create observable integrity and supply-chain control failures. | |
| Recommendation — Bind verification to the exact artifact that will be deployed. Restrict image admission so only approved immutable references are deployable. Monitor admission workflows for re-resolution of image manifests. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | A changed manifest after verification is a supply-chain integrity attack path. |
| T1606 — Forge Web Credentials | Repository or registry trust abuse can enable delivery of a different trusted-looking artifact. | |
| Recommendation — Detect and block artifact substitution paths in the software supply chain. Treat registry trust as part of the attack surface and validate artifact identity. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Secrets and Credential Management | Container supply chains often rely on tokens and keys for registry access. |
| Recommendation — Ensure registry credentials cannot be used to alter or substitute verified artifacts. | ||
Practitioner Guidance
What to verify: Confirm that admission controllers and policy engines fetch the image manifest once, then reuse the same resolved digest or immutable reference through the rest of the decision path. If the implementation re-queries the registry after policy evaluation, treat that as a design defect, not a minor efficiency issue.
Decision rule: If the platform cannot guarantee a single, consistent artifact identity from check to use, prefer digest-pinned deployment flows and reject tag-based workflows for protected workloads. For higher-assurance pipelines, the verification result should bind to the exact manifest content, not to a name that can later resolve differently.
Practitioner takeaway: The real control is artifact immutability across the entire admission path; once the manifest can change between verification and use, image signing no longer protects the object that actually runs.
Related resources from NHI Mgmt Group
- What breaks when security fixes require a new container image every time?
- What breaks when teams scan container code but not the built image?
- What breaks when container security stops at image scanning?
- What breaks when teams do not track where container image references live in code and infrastructure files?
