Container image supply chain is one of those areas where the standards landscape has been in motion for six years and the rate of change has finally slowed. In 2026 there is a coherent story to tell, and most of the working parts are stable enough to bet production workloads on. Some parts are still in motion and if you commit to them now you will be rewriting something in eighteen months.
This is a grounded snapshot of where things are, what has settled, what is still contested, and what a competent platform team should deploy today.
What has stabilized in the last two years?
The OCI image format, the OCI distribution spec with artifacts and referrers support, Cosign signatures, Rekor transparency logs, and SLSA provenance attestation shape. These are the things you can build on without worrying that the format will shift under you.
The OCI image format itself stabilized years ago, but the extensions to support signatures, attestations, and SBOMs as co-located artifacts went through several iterations and only settled with the OCI 1.1 distribution spec and the referrers API. Every major registry — ECR, ACR, Artifactory, Harbor, GHCR, Docker Hub — supports it as of 2025, and the client tooling has caught up. You can push an image and have cosign sign and syft attest attach signatures and SBOMs to it, and you can fetch them back with the referrers API from any of those registries reliably.
Sigstore's public good infrastructure has graduated from a research project to a piece of production infrastructure that organizations actually depend on. Fulcio, Rekor, and the transparency log ecosystem have real uptime commitments and real incident response. Private Sigstore stacks using the sigstore/scaffolding project are deployable in a week by a team that has never touched the stack before. This was not true in 2023.
SLSA v1.0 has shipped and the provenance attestation schema is stable. Build systems produce provenance attestations natively — GitHub Actions does via its artifact attestation feature, GitLab does via its SLSA framework integration, Tekton Chains does in a first-class way. The attestation format has the shape it is going to have for the foreseeable future.
What is still in motion?
Attestation composition, VEX workflow, artifact reference conventions above OCI level, and AI-model-specific supply chain standards. If you commit to any of these today, plan for a migration.
Attestation composition is the problem of what happens when you have five attestations about the same image and a policy that wants to reason about them as a set. The current state is that each attestation is independent and policy engines have to correlate them. Work is underway to define composition semantics more rigorously, but nothing has shipped as a stable standard.
VEX (Vulnerability Exploitability eXchange) has momentum and the format is stable, but the workflow around producing, signing, distributing, and consuming VEX statements in a trust-preserving way is still being figured out. If you are generating VEX today, expect the plumbing to change. OpenVEX and CSAF both exist, and which one wins in practice is not fully decided.
Artifact references beyond OCI — how you refer to an SBOM that itself is an OCI artifact, or a VEX statement that refers to multiple SBOMs — is inconsistent across tooling. PURL (Package URL) works well for packages and poorly for composite artifacts. Expect churn.
AI model supply chain is its own emerging space with a different shape. Model cards, training data provenance, and weight integrity are being worked on in parallel to container supply chain, and the two spaces are converging slowly.
Which CNCF projects should a platform team actually deploy?
Cosign for signing, Sigstore Policy Controller or Kyverno for admission verification, in-toto for attestation format, SLSA for the provenance schema, and Tetragon for runtime. That is the working stack.
Deploy Cosign for image signing in CI, targeting whichever major registry your org uses. Keyless if you are in a cloud environment, keyed only if you are air-gapped.
Deploy Kyverno or the Sigstore Policy Controller for admission verification, as covered in a separate post. Kyverno if you are doing general policy work alongside signing, Policy Controller if you are doing only signing and attestation verification.
Generate SBOMs at build time with Syft or a registry-native tool, attach them as OCI referrer artifacts, and sign them as in-toto attestations. SPDX 3.0 is the format most tools target now, with CycloneDX as a common alternative. Either format is fine; do not let a format argument delay you.
Deploy SLSA provenance attestations from your build system. Most major CI tools produce them without configuration. Verify them in your admission controller.
Deploy Tetragon (or Falco) for runtime enforcement of the policies that the build-time and admission-time controls cannot enforce — behavioral policies like "no shell exec in application containers."
What about Notary v2 — is Notation still relevant?
Notation is still relevant for organizations that need an alternative to Sigstore's OIDC-based trust model, particularly enterprises with existing PKI investments. It is not dead, and in some sectors it is growing. For most teams, Cosign plus Sigstore is the easier path.
The Notary v2 project produced the Notation tool and the CNCF-hosted Notary Project governance. The trust model is X.509-based — you sign with a certificate rooted in a PKI you control, and verification is PKI-based without a transparency log requirement. This fits organizations that already have HSM-backed CAs and compliance regimes that want a chain of trust rooted in their PKI.
The operational cost of Notation is PKI operation. Cert rotation, CRL distribution, OCSP infrastructure — all the complexity of running a PKI you probably already have but perhaps have not integrated into your container pipeline. If you already run a PKI and want to extend it to containers, Notation makes sense. If you do not, Cosign is a shorter path to the same security property.
I have deployed both in different organizations. Cosign deployments take a couple of weeks. Notation deployments take a couple of months. Notation deployments are more defensible to a skeptical auditor who does not understand what a transparency log is.
How does all of this fit with the SLSA framework?
SLSA gives you a ladder of provenance-integrity levels to aim for, and the OCI/CNCF tooling is what you deploy to climb it. SLSA 1 is "your build produces a provenance attestation." SLSA 2 is "the attestation is signed and tamper-resistant." SLSA 3 is "the builder is hardened and the provenance is auditable." SLSA 4 is "the builder is reviewed and reproducible."
Most organizations realistically live at SLSA 2 or SLSA 3. The jump to SLSA 4 involves engineering work — hermetic builds, reproducibility — that most teams do not have budget for and most workloads do not require.
A working target for a mainstream platform in 2026: every production image has a signed SLSA 3 provenance attestation, signed by a hardened builder (GitHub Actions with OIDC, Tekton Chains with signed tasks, or equivalent), verified at admission, and the attestation is auditable for twelve months. That is achievable with the tooling we have and it is meaningfully more secure than what most organizations had in 2022.
How Safeguard.sh Helps
Safeguard.sh integrates with the full CNCF supply chain stack — Cosign, Sigstore, SLSA, in-toto, Tetragon — and layers reachability analysis on top so that "an image has a valid SLSA attestation" becomes "an image has a valid SLSA attestation and the reachable code paths match the attestation's claimed materials," which is what drives the 60 to 80 percent reduction in vulnerability noise. Griffin AI tracks the evolving CNCF standards and upgrades your attestation and verification tooling as formats stabilize, working from SBOMs with 100-level dependency depth and correlating across the attestation chain. TPRM covers the third-party images entering your environment and verifies their SLSA provenance where available, and container self-healing rebuilds and re-attests workloads when patches land upstream, keeping your supply chain posture current instead of static.