Service meshes sit exactly where supply-chain policy wants to be enforced: between workload identity and network data plane, after admission but before any byte moves. Istio 1.24, Linkerd 2.16, and Cilium 1.16's service mesh each expose primitives that let you bind a workload's cryptographic identity to its artifact provenance and enforce rules at the L7 proxy. That combination is more powerful than traditional NetworkPolicy because it carries identity across connections and gives you request-scoped authorization. The catch is that most mesh deployments stop at mTLS and L7 authorization, leaving provenance-aware policy (for example, "only workloads built from signed artifacts on attested builders may talk to this service") on the table. This post walks through how to close that gap, using SPIFFE IDs as the identity fabric, Sigstore as the provenance root, and the mesh as the enforcement point.
How do service meshes produce workload identity today?
Via SPIFFE-compatible workload identities minted per pod. Istio 1.24 uses Citadel/istiod to issue SPIFFE X.509 SVIDs with URIs like spiffe://cluster.local/ns/payments/sa/checkout. Linkerd 2.16 issues mesh-internal identities through its linkerd-identity component, also using SPIFFE IDs since 2.12. Cilium's mesh uses SPIFFE IDs through SPIRE 1.10 when the spiffe.enabled flag is set. The identity is rooted in the ServiceAccount plus namespace, validated via the Kubernetes TokenRequest API with bound tokens (Kubernetes 1.24+), and issued as a short-lived certificate (typically 1 to 24 hours). The identity itself does not encode provenance; it says "this pod is running as service account X in namespace Y." The missing link is tying that identity to the artifact it is actually running.
What does provenance-aware policy actually require?
A chain from running workload back to signed artifact and attested builder. The building blocks: admission controllers like Kyverno 1.12 or Gatekeeper 3.17 verify image signatures and attestations at pod creation via cosign 2.4 and Rekor; workload identity is issued only to pods that passed admission; and mesh policy uses that identity as an authorization principal. In practice, a CUE or Rego policy at admission requires the pod's image references to have a valid Sigstore signature and an SLSA v1.0 provenance attestation whose builder.id matches an allowlist. Once admitted, the mesh attaches the SPIFFE ID and L7 policies can reference it. The chain is brittle at the edges: if a pod is admitted then its image is mutated at runtime (e.g., via exec into the container), the mesh identity still binds to the pod identity, not to the live contents. This is where eBPF runtime sensors complement the mesh.
How do you express this as mesh policy?
With AuthorizationPolicy in Istio, Server/ServerAuthorization in Linkerd, and CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy in Cilium. An Istio AuthorizationPolicy targeting the payments-checkout service can restrict source identities to spiffe://cluster.local/ns/payments/sa/orders and further constrain by custom claims if using RequestAuthentication with JWT carrying provenance claims. Linkerd 2.16 added ServerAuthorization CRDs tied to MeshTLSAuthentication that similarly accept SPIFFE identities as principals. Cilium's L7 policy at the http.headers level can enforce presence of a signed JWT minted at admission carrying the attestation digest. The layering that works in production: admission gate enforces artifact signing and provenance, mesh policy enforces L7 traffic between identities, runtime eBPF enforces process-level expected-binary policies.
What real mesh CVEs and failure modes should you plan for?
The mesh itself is a supply-chain concern. Istio has had several CVEs in the Envoy data plane: CVE-2023-44487 (HTTP/2 Rapid Reset) affected Envoy 1.26-1.27 and cascaded into Istio 1.17-1.18. Envoy 1.29's CVE-2024-27919 was an HTTP/2 flood issue. Linkerd's Rust-based proxy (linkerd2-proxy) has had smaller CVE volume but is not immune; tokio and rustls CVEs flow through. Cilium, being eBPF-heavy, depends on kernel version compatibility; upgrading the mesh without upgrading node kernels has caused policy-compilation failures. Operationally, certificate rotation is the most common failure mode: Istio's root CA rotations (particularly when moving from self-signed to cert-manager issuers) have caused production outages, and Linkerd's identity issuer expiration is a known operational hazard. Run chaos tests on expiry paths.
Where does the mesh specifically shine for supply chain?
For enforcing workload-to-workload policy that CI/CD controls cannot see. A compromised image that passed admission (because the signature was valid at admission time but the source key was later revoked) can be contained by updating mesh AuthorizationPolicy to deny that service's identity without redeploying every consumer. Conversely, revoking trust in a SPIFFE ID or rotating a mesh CA bounds blast radius in minutes, not hours. Mesh telemetry (Prometheus + Jaeger + OTel) gives per-request identity labels that feed into anomaly detection much better than raw NetworkPolicy logs. Service meshes also handle the transitive identity problem: if service A uses service B which uses service C, the mesh can enforce that C only accepts requests whose call chain started at an allowlisted entry point, using OPA's ext_authz integration in Envoy 1.31.
How Safeguard Helps
Safeguard integrates with admission controllers and mesh policy stores to provide the artifact-level trust decisions the mesh enforces. When a Kyverno or Gatekeeper policy asks "is this image signed and attested per tenant policy," Safeguard's verification API answers in single-digit milliseconds, caching Rekor inclusion proofs locally for offline resilience. Provenance changes propagate to mesh policy reference data so that a revoked attestation quickly surfaces as a policy-gate failure for new pod creations and as a finding for running workloads. The audit trail binds SPIFFE IDs, image digests, and attestation identifiers so incident responders can replay decisions without stitching logs by hand.