KubeCon + CloudNativeCon North America 2025 in Atlanta drew the usual massive crowd, and the supply chain security track continued its multi-year expansion. What started a few years ago as a niche area inside SecurityCon co-located content is now a full track with packed rooms, serious tooling maturity, and a clear operational story for platform teams.
For anyone running Kubernetes at scale who is trying to translate the principles of software supply chain security into practice, KubeCon NA 2025 produced the most grounded set of sessions we have seen yet. Here is the analyst view of what mattered.
Where is the cloud-native supply chain story in 2025?
It is past the proof-of-concept phase and firmly into operational adoption. Three years ago, a talk on Sigstore at KubeCon was a curiosity. In 2025, Sigstore adoption was assumed — the more interesting sessions discussed what organizations were doing with attestations at scale, how they were integrating policy decisions into admission controllers, and where the current tooling was still rough.
The sessions in the co-located SupplyChainSecurityCon and the main KubeCon security track reflected that maturity. Talks covered production deployments of cosign and policy-controller, real-world experience with in-toto attestation layers, the operational burden of maintaining signing infrastructure, and the ongoing challenge of verifying provenance for third-party container images where the publisher may not have full SLSA compliance yet.
The dominant feeling in the hallways was pragmatic. Organizations are no longer asking whether they should adopt supply chain controls; they are asking which controls to start with, how to sequence the rollout, and how to handle the inevitable exceptions when a critical upstream image does not meet your policy.
What Sigstore and SLSA updates shaped the conversation?
Sigstore continues to be the foundation for cloud-native software attestation, and the project's continued stability was a quiet but important story at KubeCon. Cosign is effectively the default for OCI artifact signing in CNCF-adjacent projects. Rekor's public instance continues to grow. And Fulcio's integration with workload identity providers is becoming a standard pattern in mature pipelines.
The SLSA conversation was equally pragmatic. Several talks walked through concrete implementations of SLSA Level 3 build environments — what it actually takes, which CI platforms make it easy versus hard, and where the organizational cost lives. The honest picture that emerged is that SLSA adoption is easier for greenfield projects than for brownfield ones, and that the jump from Level 2 to Level 3 is where most teams stall. Level 3 requires isolated, hermetic builds, and retrofitting those properties into an existing CI estate is substantial work.
The complementary story is about consumption. Several sessions focused on the verification side — how to validate SLSA attestations and Sigstore signatures at admission time, how to handle images that lack attestations, and how to express policy in a way that is actually enforceable across a large platform. Tools like Kyverno, OPA/Gatekeeper, and the Sigstore policy-controller were all represented, with mature examples of production deployments.
How are platform teams approaching admission-time policy?
As a layered, gradually-enforced capability. The most common pattern described at KubeCon was "dry-run first, enforce later" — deploy admission policies in a monitoring mode, watch what they would have blocked, adjust policy and onboard exceptions, and only then move to hard enforcement.
The specific policies getting deployed reflected a consistent hierarchy. Signed images first: reject any image not signed by a known key. Attested provenance second: require that the image was built by a known pipeline, with documented source and build metadata. Vulnerability gates third: reject images with critical, reachable vulnerabilities. SBOM requirements fourth: require that images include embedded SBOMs for downstream consumption.
A notable operational theme across the sessions was exception handling. Every platform team has upstream images that do not meet the organization's preferred standard — vendor-provided images without signatures, community images with incomplete SBOMs, images that were acceptable yesterday but fail today's policy because a new CVE dropped. The speakers who had operated these programs for a year or more all described some form of structured exception workflow: a time-boxed waiver, a named owner, a re-evaluation trigger. The ones who had not built this workflow were the ones still struggling with operational friction.
What role did reachability and runtime context play?
A growing one. KubeCon NA 2025 featured several sessions on how to combine static dependency analysis with runtime data — eBPF-based observability, service mesh telemetry, runtime application self-protection — to reason about which vulnerabilities actually matter in the cluster.
The conversation has sharpened significantly. A year or two ago, "runtime context" was a vague pitch. In 2025, it has specific operational meaning: does this vulnerable function get called in production; does this container actually make network connections to the paths an attacker would need; is this privileged capability actually used. Several talks showed working pipelines where runtime data feeds back into the vulnerability triage process, automatically downgrading findings that are demonstrably not exploitable in the deployed environment.
This is particularly relevant in Kubernetes because the platform itself produces rich signal — what is scheduled where, what talks to what, which workloads hold which secrets — that can inform supply chain decisions. The teams that are investing in this integration are the ones whose security programs look most sustainable at scale.
Which open-source projects gained traction at the show?
A handful stood out. Sigstore tooling — cosign, policy-controller, and the broader ecosystem — continues to be the baseline. Kyverno's policy reporter and chainsaw got strong attention from platform teams formalizing their admission workflows. Kubernetes-native vulnerability scanners that integrate with image signing are becoming a standard part of the platform stack, with projects in this space visibly maturing.
On the attestation side, projects around in-toto layout verification, witness, and related CNCF sandbox/incubating work drew serious attention from teams implementing SLSA Level 3-ish controls. These projects are beyond the "early experimentation" phase but have not fully consolidated into a single dominant tool, and practitioners are still making judgment calls about which stack to invest in.
SBOM tooling continues to mature. Syft and Grype remain prominent in the CNCF ecosystem, with increasingly credible integration into build pipelines and admission controllers. The newer work around SBOM-to-VEX integration, and the ability to suppress vulnerability findings based on VEX statements attached to images, was one of the most operationally useful developments discussed at the conference.
What are the hardest remaining problems?
Three kept coming up in hallway conversations and panel Q&As.
First, third-party image hygiene. Platform teams can enforce their own build pipeline to any level of rigor they choose, but a large fraction of what runs in production is third-party. Vendor images, community images, and base images from upstream Linux distributions vary wildly in their attestation quality, SBOM completeness, and vulnerability response. Organizations are spending significant effort normalizing this — either by re-building upstream images from source, mirroring them into internal registries with additional metadata, or selectively accepting images from a short list of trusted publishers.
Second, the signer-identity question. Sigstore's keyless signing with Fulcio ties a signature to a workload identity, which is great — but only if the identity itself is trustworthy. Several sessions discussed the challenge of verifying that an image was signed by the pipeline you think it was, rather than by a pipeline that happens to have similar-looking identity claims. The operational answer is policy: encode your expectations about which identities should be able to sign which artifacts, and fail closed when reality does not match.
Third, policy fatigue. Every new control adds a new place where builds can break, and the cumulative effect is real. The teams that handle this best invest in developer experience: clear error messages, self-service exception workflows, and policies that explain why they triggered rather than just blocking.
How Safeguard.sh Helps
Safeguard.sh plugs directly into the cloud-native supply chain workflows that dominated KubeCon NA 2025. We ingest Sigstore signatures and in-toto attestations, verify them against policy you can define per image source, and surface clear, actionable reports when an image fails a control. Our reachability engine extends into the container image domain — understanding which vulnerable code paths are actually reachable from the entrypoint of the running workload — so your cluster's admission policies can be strict where it matters and tolerant where it does not. And because Safeguard treats SBOMs, VEX, and provenance as first-class inputs rather than afterthoughts, your platform team can move from ad-hoc scanning to a structured, auditable supply chain posture without asking every application team to build its own tooling.