TL;DR: Your zero trust architecture authenticates users, devices, and North-South traffic. It does not authenticate the code running inside your cluster. Third-party dependencies, vendor containers, and open-source libraries enter with full privileges, because supply chain artifacts have no verifiable identity. Extending zero trust to the build pipeline requires workload identity, signed attestations, admission controllers, and service mesh mTLS.

Key Takeaways: - Zero trust's "never trust, always verify" principle was designed for users and devices, not binaries. - An SBOM is an inventory list, not a verification mechanism. It does not prove a binary matches what was declared. - Workload identity (SPIFFE/SPIRE) and admission controllers (Kyverno, OPA, Sigstore) extend verification from users to artifacts to running pods. - Continuous attestation at deploy time and on every service call beats annual vendor questionnaires.

You rolled out MFA, identity-aware proxies, and microsegmentation. You run a textbook zero trust architecture.

Then last quarter, a malicious dependency in a vendor's npm package executed inside your production cluster. It ran with the same privileges as your own services, because supply chain code does not authenticate through your IdP.

Zero trust rollouts typically cover North-South traffic. That means users, devices, and APIs crossing the network boundary. Every one of those subjects presents an identity, gets challenged, and receives a short-lived token.

Third-party code runs East-West inside the perimeter. It has full privileges. And it has no identity of its own.

A compromised dependency bypasses every MFA challenge and identity-aware proxy you have deployed. The malicious call does not come from outside the trust zone.

It originates from inside, on a pod your scheduler started. The pod uses a service account your own controller plane created. From the perspective of your zero trust controls, that pod is a trusted citizen.

You do have an SBOM, right? You vet your vendors. So where exactly is the gap?

Zero trust was designed around user and device identity, not artifact or build identity. North-South controls have no native concept of a verified binary.

Your identity-aware proxy can validate a JWT, check device posture, and enforce conditional access. It cannot tell you whether the container image behind a service mesh sidecar was built from the source it claims.

An SBOM is an inventory document, not a verification mechanism. It tells you what is in your software. It does not tell you whether the running binary matches what was declared.

Two builds from the same source can produce different binaries. The result depends on toolchain versions, environment variables, or a tampered base image. The SBOM stays the same while the artifact drifts.

Annual vendor questionnaires are point-in-time snapshots. They cannot survive a single rebuild, a tampered mirror, or a compromised maintainer account.

By the time your security team reviews the questionnaire next year, the binary you deployed last month has been rebuilt. The rebuild happens across a CI pipeline you do not control. Your cloud security posture dashboard shows a green checkmark. The artifact has changed since the assessment.

Zero trust answers the question "who is asking?" with cryptographic identity. The supply chain problem is "what is running?" with no equivalent mechanism.

So the obvious fix is to sign everything and verify on admission. Here is where the mechanism actually has to engage.

Every artifact in your build pipeline needs a cryptographic identity that is independent of the developer who pushed it. A stolen CI credential cannot impersonate a trusted image if the image's identity is bound to a signing key held in a hardware root of trust, not a human account.

This is the principle behind Sigstore's keyless signing with OIDC, and behind the SLSA framework's provenance requirements.

SPIFFE/SPIRE-style workload identity binds a running process to a verified build provenance. Every service gets a short-lived, attestable identity encoded as a SPIFFE Verifiable Identity Document (SVID).

The SVID is derived from the binary's signed attestation, not from the pod's service account token. If a workload cannot present an SVID that traces back to a trusted build, it cannot authenticate to its peers.

SLSA-style provenance and signed SBOMs let you answer "where did this binary come from?" with cryptographic certainty, not a PDF from a vendor. The provenance is an attestation signed by the build platform.

The SBOM is an OCI artifact attached to the image, signed with cosign. Verification is automated, reproducible, and does not require trusting a human answer.

A verifiable artifact in a registry is not the same as a verified workload in your cluster. The next layer is where most teams stall, because cloud workload identity requires plumbing admission controllers, policy engines, and a trust root. Your platform team has to own and operate that root.

Kubernetes admission controllers are the natural enforcement point. Kyverno, OPA Gatekeeper, and the Sigstore Policy Controller intercept every API request to create or mutate a workload.

They run before the scheduler, before the container starts, before any network policy can apply. This is the chokepoint where you reject unsigned, unverifiable, or untrusted artifacts.

Policies should reject pods whose container images lack a valid signature. They should also reject pods whose SBOM fails policy, or whose workload identity cannot be verified against the trust root.

The enforcement is declarative, version-controlled, and auditable. There is no human in the loop to forget, get phished, or approve under pressure.

A policy like this turns your cluster into a gate. Only images with valid signatures, verified provenance, and a signed SBOM attached as an OCI artifact get admitted. Everything else is rejected at the API server, before any workload starts.

For more on mTLS-only enforcement tradeoffs, see our analysis of mesh mTLS backdoors. It explains why admission-time checks are a necessary complement to mesh controls.

Admitting verified workloads is half the architecture. The other half is making sure those workloads can only talk to other verified workloads, continuously, not at deploy time.

Point-in-time vendor audits cannot keep up with rebuilds. A container image signed at 9:00 AM can be rebuilt at 9:05 AM.

A malicious patch and a re-signed manifest can land there if the signing key leaks. Continuous attestation means verify at every deploy, on every service call, not once a year. The trust decision is a function of the current state, not a snapshot from last quarter.

mTLS inside a service mesh extends workload identity from the perimeter to every East-West call. A pod presents its SPIFFE SVID when initiating a connection.

The peer validates the identity against the mesh's trust root. A compromised pod cannot impersonate a legitimate peer, because it cannot forge an SVID bound to a different service's attested build.

DevOps teams get policy as code. Security teams get provable, observable posture.

Neither side blocks the other at release time. Verification is automated and fast enough to stay out of the deploy path. The system is durable, and these controls outlive any individual deployment.

Our deeper dive on service mesh and mTLS enforcement covers the failure modes where mesh-only thinking leaks.

That is the full mechanism. Here is what actually changes in your security posture when you ship it.

Blast radius shrinks. A compromised dependency can only execute inside a verified, policy-allowed context. Lateral movement across services is blocked by mTLS identity checks.

A malicious pod cannot reach a database it was not authorized to talk to. Even sharing a node, namespace, or node pool with a legitimate service does not give it access.

Incident response accelerates. You can trace any running workload back to a signed build, a commit, and a verified SBOM. The trace is a chain of cryptographic evidence, with no log archaeology required.

For teams running Istio, our piece on mTLS data leaks shows where trace chains break down and how to harden them.

Start with one critical workload and one cluster, then scale. Federal mandates now include supply chain security as a core requirement for zero trust programs.

The recommended path is incremental: one signed image pipeline, one admission policy, one mesh namespace in strict mode. Expand as observability and operational maturity grow.

The scalability tradeoff in complex supply chains is real, which is why a one-cluster pilot is the right starting point.

The supply chain is the identity-less backdoor in your zero trust model. Closing it means giving every artifact, every build, and every running workload a cryptographic identity your platform can verify.

Verification runs continuously, automatically, and without waiting for next year's questionnaire. Teams that build this layer treat it as production infrastructure, not a security checkbox.

Mapping this rollout against your own platform? Levitation helps engineering teams design workload identity, admission, and mesh enforcement for a verified supply chain layer.

Q: How does zero trust apply to supply chain security?

A: Zero trust extends the "never trust, always verify" principle from users and devices to software artifacts, build pipelines, and running workloads. Every dependency, image, and binary must present cryptographic evidence of provenance and identity before it is admitted into your environment.

Q: Is an SBOM enough for zero trust supply chain security?

A: An SBOM is an inventory of what is in your software. It does not verify integrity, authenticity, or that a binary was built from the declared sources. Zero trust requires signed SBOMs, build attestations, and runtime admission checks on top of an SBOM.

Q: What role do admission controllers play in a zero trust architecture?

A: Admission controllers intercept every API request to create or modify a workload in Kubernetes. In a zero trust model, they enforce policy. They reject pods whose images are unsigned, whose SBOMs fail checks, or whose workload identity cannot be verified against the trust root.

Q: What is cloud workload identity?

A: Cloud workload identity is a cryptographic identity assigned to a running process or service rather than a human user. Standards like SPIFFE issue short-lived, attestable identities. They tie a running workload back to a verified build, enabling zero trust verification at the service-to-service level.

Q: How long does it take to extend zero trust to the software supply chain?

A: Most organizations start with a single critical workload or cluster and scale outward. The recommended approach is incremental. Begin with one signed image pipeline and one admission policy, then expand coverage as observability and operational maturity grow.

Research and references cited in this article:

• Software Supply Chain Implications for Zero Trust - MergeBase
• Zero Trust Architecture in 2026: Components, Process & Examples
• Zero Trust Security (The 8 Key Pillars To Secure Cloud Assets)
• Zero Trust as a Defence Against Supply Chain Attacks | UpGuard
• Zero Trust - The Essential Guide - Industrial Cyber
• Craig Petronella's Post - LinkedIn
• Zero Trust model explained: Why “never trust, always verify” matters more than ever
• What is zero trust?
• Zero-trust identity in 2026: What security leaders need - TrustCloud
• Use Case: Zero Trust for Non-Human Workloads - Aembit
• Securing the Links:Zero Trust as the New Standard in Supply Chain ...
• Zero-Trust Supply Chains: A New Standard for Cybersecurity