TL;DR: Container supply chain security still breaks when teams source images from public registries, build them in inconsistent CI pipelines, and rely on runtime checks too late, according to Rapidsort. The discipline has to start with curated images and end with admission control, or trust remains fragmented across the pipeline.
At a glance
What this is: This is a whitepaper on container supply chain security that argues for end-to-end control from curated image intake through build-time policy and Kubernetes admission enforcement.
Why it matters: It matters because identity and access decisions around image sources, registry trust, CI permissions, and runtime admission now shape whether workload artefacts are verifiable or merely assumed safe.
Context
Container supply chain security is the practice of controlling where images come from, how they are transformed, and what is allowed to run. When teams pull directly from public registries or allow each developer group to manage its own image sources, provenance becomes inconsistent and policy enforcement becomes fragmented. software supply chain security is the right baseline for that problem, but this paper narrows the lens to containers and Kubernetes.
The article frames a disciplined model that moves control from image intake to CI checks and then to runtime admission. That matters for identity governance because registry trust, pipeline signing, and admission decisions are all access-control problems in disguise, even when they are discussed as build or platform hygiene. The starting point is common in container programmes, but the end-to-end control model is still unevenly implemented.
Key questions
Q: What breaks when container teams rely on public registries without governance?
A: The main failure is provenance drift. Teams lose a verifiable chain from source image to deployed workload, so vulnerable or tampered artefacts can enter the pipeline without a shared approval record. Once that happens, later scanning helps, but it cannot fully restore trust in how the image was sourced, altered, and admitted.
Q: Why do CI controls matter if Kubernetes can block unapproved images at runtime?
A: CI controls reduce the number of bad artefacts that ever exist. Runtime admission is still necessary, but it only catches what reaches the cluster. If build pipelines can create non-compliant images freely, the organisation ends up using admission control as a late filter instead of a preventive governance layer.
Q: What are the signs that supply chain controls are too fragmented to trust?
A: Different teams describe the same attack in different ways, red-team scope is unclear, and coverage reports focus on tools rather than adversary behaviour. Those symptoms usually mean the organisation has policy controls without a shared reference model for attack paths.
Q: Who should own image provenance and registry policy in a container programme?
A: Ownership should sit with a platform or security function that can govern the full path from approved source image to internal registry to admission policy. Development teams should consume trusted images, not define trust boundaries individually, because provenance only works when one operating model spans sourcing, build, and runtime.
Technical breakdown
Why curated base images change the trust model
The first control point is image sourcing. Instead of letting every team consume arbitrary public images, the model centralises approved base and third-party images in an internal registry. That changes the trust model from opportunistic consumption to governed distribution. Verification at ingestion, image signing, and provenance attestations turn the base image into a controlled artefact rather than a convenience download. For identity security, the relevant question is who is authorised to publish trusted image artefacts and which controls prove they came from an approved pipeline.
Practical implication: Treat approved image publishing as a governed identity and provenance function, not a convenience step.
How build-time policy stops non-compliant images earlier
Build-time enforcement catches drift before a container is built and pushed. Tools like Hadolint can reject Dockerfiles that reference unapproved registries, while additional policy checks can validate SBOM generation, vulnerability scanning, and required attestations. This is important because once an image is built and distributed, later controls only reduce blast radius. The governance issue is not just code quality, but whether the CI pipeline is allowed to inherit trust from an approved base image and preserve that trust through the build process. See the CI/CD Pipeline Identity Security Guide.
Practical implication: Move registry allowlisting and attestation checks into CI so unapproved sources never become artefacts.
Why admission controllers are the final enforcement boundary
Runtime policy engines such as Kyverno or Gatekeeper act as the last gate before a workload is persisted into the cluster. They can validate image sources, signatures, SBOM attestations, and other metadata at admission time, including for init containers and ephemeral containers. That matters because a compliant build can still be bypassed if the cluster accepts unverified artefacts. Admission control turns runtime from passive observation into a policy decision point, which is essential when the cluster is the final place where trust is either accepted or denied.
Practical implication: Use admission control to block unsigned or unapproved workloads before they are admitted to the cluster.
Threat narrative
Attacker objective: To introduce compromised container artefacts into the software supply chain and convert that trust gap into runtime exposure.
- Entry occurs when teams consume container images from public or otherwise untrusted registries, introducing artefacts whose provenance is unclear.
- Credential or trust abuse follows when build and deployment pipelines accept those artefacts without strict registry, signature, or attestation checks.
- Impact occurs when vulnerable, tampered, or non-compliant images reach Kubernetes and become eligible for execution in production.
Breaches seen in the wild
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Container trust has to be governed as a lifecycle, not a point control. The article’s central lesson is that image security fails when organisations treat intake, build, and runtime as separate problems. A trusted registry, a signed build, and an admission policy only work when they are managed as one chain of custody. For practitioners, the real question is whether every handoff preserves provenance or quietly resets trust.
The named concept here is image trust fragmentation: the gap that appears when source approval, build validation, and runtime enforcement are owned by different teams with no shared policy model. That gap is where inconsistent posture enters. A base image can be approved upstream, then altered in CI, then admitted in Kubernetes without any single control proving the full path remained intact. The identity angle is direct: only authorised identities should be able to publish, sign, and admit trusted artefacts. Practitioners should treat this as a governance boundary, not a tooling preference.
Runtime enforcement is not a substitute for secure intake. Admission control is the final gate, but it should not be the first place trust is checked. If the build pipeline routinely accepts unapproved sources, the cluster becomes a cleanup layer rather than a control boundary. That weakens auditability and makes incident response harder because the provenance trail starts too late. Teams should design policies so the earliest possible stage blocks bad inputs and the cluster only verifies what upstream controls have already made trustworthy.
Container supply chain security increasingly overlaps with identity governance. The article shows that image publishing, registry access, signing identities, and CI attestations are all identity decisions. That is why controls such as repository allowlisting, pipeline identity restriction, and trusted publication permissions matter as much as scanning. The more container programmes scale, the more they need a governed identity model for artefact production and distribution.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Software Supply Chain Security Guide
What this signals
Image trust fragmentation: container programmes fail when provenance is split across intake, CI, and runtime ownership. That split creates policy drift, because each team can believe another stage is verifying trust. The next governance step is to unify source approval, signing, and admission around one artefact lifecycle.
The container security conversation is shifting from image scanning to trust enforcement. Teams that only measure vulnerability counts miss the more important question of whether the artefact itself came from an authorised path, and whether that path is still enforceable at scale.
SaaS-to-SaaS and OAuth app governance becomes relevant whenever third-party images or integrations are approved, because the same lifecycle problem appears there: decide who may publish, who may consume, and how revocation is enforced when trust changes.
For practitioners
- Centralise approved image sourcing Create a controlled internal registry for base and third-party images so teams stop pulling directly from arbitrary public sources.
- Enforce registry allowlisting in CI Reject Dockerfiles that reference unapproved registries and block builds before non-compliant images can be created.
- Require signing and provenance attestations Sign derived images on behalf of the organisation and attach attestations that record how each image was produced.
- Validate workload identity at admission Use Kubernetes policy to check image signatures, provenance metadata, and approved registries before the pod is admitted.
- Separate trusted publishing from developer consumption Limit who can publish trusted artefacts and make the internal registry the only approved source for downstream teams.
Key takeaways
- Container supply chain risk is now as much about provenance and authority as it is about vulnerabilities.
- The article’s model links image intake, CI policy, and Kubernetes admission into one enforcement chain.
- Practitioners should treat trusted image publishing and registry policy as governed controls, not developer convenience tasks.
Related NHI Mgmt Group resources: SaaS-to-SaaS and OAuth App Governance Guide · Software Supply Chain Security Guide · CI/CD Pipeline Identity Security Guide · Klue OAuth Supply Chain Breach
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party images and integrations create the same trust exposure pattern as vulnerable external NHIs. |
| NHI-05 — Overprivileged NHI | Build and registry identities should not have broad publish rights across the image supply chain. | |
| Recommendation — Govern third-party artefact access with approval, provenance, and revocation controls before allowing downstream use. Restrict publish and signing permissions to the minimum identities needed to create trusted artefacts. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0040 — Initial Access; Credential Access; Impact | The article describes untrusted artefacts entering the pipeline and reaching runtime impact. |
| Recommendation — Map untrusted image ingress to TA0001 and TA0006, then block runtime impact with admission controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Registry trust, CI permissions, and cluster admission are all entitlement decisions. |
| Recommendation — Apply PR.AA-05 to centralise and enforce who may publish, sign, and admit container artefacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The pipeline depends on tightly governed identities for publishing and deployment. |
| Recommendation — Use CIS-5 to manage the identities that can source, sign, and deploy container images. | ||
Key terms
- Mobile Supply Chain Security: Mobile supply chain security is the discipline of governing third-party SDKs, APIs, and embedded libraries that ship inside mobile applications. It focuses on what those dependencies can access, how they behave after deployment, and whether their authority stays within approved boundaries.
- Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
- Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
- Trusted registry: A controlled source of tool definitions that has been reviewed, curated, and tied to policy before a model is allowed to use it. In MCP environments, registry trust matters because the discovery path can be attacked before the execution path ever begins.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security and identity practitioners connect trust, provenance, and access control across modern delivery pipelines.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org