CNCF's Technical Advisory Group for Security (TAG Security) shipped the v2 Software Supply Chain Best Practices paper in 2025, with co-chair John Kjell presenting the highlights at Open Source Summit Europe in August. The paper is the successor to the original 2021 white paper that codified the "Secure Supply Chain" vocabulary now used across the CNCF ecosystem. v2 reflects four years of operational learning: SBOMs and attestations have moved from emerging tooling to mainstream practice, build-system attacks have produced concrete defense patterns, and the zero-trust workload identity model has matured to the point that it can be specified in a reference architecture rather than aspirationally. The paper is not a standard — TAG Security publishes guidance, not normative specifications — but it is the most influential reference architecture in cloud-native security and frames how CNCF projects implement supply-chain controls.
What does v2 say is different from 2021?
Three categories of change. First, the toolchain is mature: SBOMs are routinely generated, signed releases are routine via Sigstore, attestations following in-toto and SLSA are produced by all major CI platforms, and provenance verification is a common gate in admission control. Second, threat understanding has sharpened — v2 explicitly references events like SolarWinds, 3CX, MOVEit, Log4Shell, the XZ Utils backdoor, the Nx s1ngularity attack, and CDN-side compromises such as polyfill.io as case studies for specific defense patterns. Third, the workload-identity zero-trust narrative has crystallized: workloads have cryptographic identities (SPIFFE, signed OIDC tokens), the build system has a federated identity that signs provenance, the deploy system verifies signatures, and non-compliant workloads are denied identities rather than being permitted with a logged anomaly.
How does v2 frame SBOM use?
SBOMs are described as foundational rather than novel. The paper recommends generating SBOMs at build time from source code, using standardized formats (SPDX 3.x, CycloneDX 1.x, SWID), linking parent-SBOMs to component SBOMs, signing SBOMs, and storing them in a registry that supports retrieval and trust verification. The novelty in v2 is the explicit treatment of "SBOMs alone are insufficient" — SBOMs must be paired with vulnerability matching, attestations of build provenance, and policies that gate consumption. The paper's reference architecture diagrams place SBOM emission as one input among several to a central policy/observability plane, not as a standalone deliverable.
# CNCF v2 reference architecture: minimum attestation set per artifact
artifact_attestation_bundle:
artifact_digest: sha256:c1d2e3...
attestations:
- type: https://slsa.dev/provenance/v1
issuer: build-platform-identity
signed_by: sigstore-fulcio
- type: https://cyclonedx.org/bom/v1.6
issuer: build-platform-identity
signed_by: sigstore-fulcio
- type: https://in-toto.io/attestation/vulnerability/v0.1
issuer: vulnerability-scanner-identity
signed_by: sigstore-fulcio
- type: https://in-toto.io/attestation/test-results/v0.1
issuer: test-runner-identity
signed_by: sigstore-fulcio
verification_policy: org_baseline_v3.cue
What about zero trust and workload identity?
v2 commits to a zero-trust workload identity model as the foundation. Identities are short-lived and tied to specific workloads (SPIFFE IDs, Kubernetes ServiceAccount-backed OIDC, AWS IAM Roles for Service Accounts). Build systems sign with federated identities (Sigstore Fulcio with OIDC). Deployments verify signatures and provenance at admission (Kyverno, Sigstore policy-controller, OPA/Gatekeeper). Non-compliant workloads are denied identities — not detected and logged, but cryptographically prevented from acting. The paper is explicit that this model only works if every link is cryptographically enforced; a single fallback path that grants identity without verification undoes the entire chain.
What does v2 say about build-system isolation?
Build systems received an entire new section in v2 reflecting four years of build-system attack lessons. The paper recommends per-build ephemeral environments (no shared state between tenant builds), strictly scoped secrets (build secrets bound to the specific build, not available to other workflows), tenant isolation in cache layers (the GitHub Actions cache-poisoning class of 2025 is referenced as a concrete failure mode), and signed builder identities (the build platform itself must produce attestations under an identity bound to the platform, not to any tenant). The paper also takes a stance on self-hosted runners: they are acceptable for non-sensitive builds but should not be the default for production-bound artifacts because tenant runners have produced repeated compromise paths. The CNCF-aligned platforms (Tekton, Flux, ArgoCD) implement most of these recommendations natively, and the paper offers them as reference deployments rather than abstractions.
How does v2 handle dependency risk?
The paper expands the dependency-management section to address typosquatting, dependency confusion, malicious maintainer takeover, and registry compromise. It recommends a defense-in-depth pattern: package allowlists, signed-release requirements, registry mirroring with verification, and continuous reputation monitoring (OpenSSF Scorecard, Allstar). The OpenSSF Securing Software Repositories Working Group's guidance is cited explicitly for registry-operator practices. The paper notes that organizations should not rely on a single signal — "scorecard above 7" or "package signed" — but combine multiple weak signals into a policy decision.
What should engineering platforms ship next?
Six implementation items v2 elevates as priority for organizations not yet there. SBOM emission at build time in CycloneDX or SPDX. Build attestations under SLSA Build Level 2 minimum, Level 3 for production. Sigstore-signed releases for all internally-produced artifacts. A central attestation store (OCI registry plus a graph database like GUAC) for query and policy. Admission controllers that verify attestations against documented policy at deploy time. And continuous observability — dashboards that surface attestation freshness, signature failures, and policy denials, treated with the same operational seriousness as runtime alerts.
How does v2 integrate the public-sector software supply chain perspective?
CNCF's Public Sector Working Group published a complementary paper in late 2025 addressing public-sector adoption of cloud-native supply-chain security, and v2 references that work where relevant. The public-sector perspective adds considerations that enterprise-focused materials had underemphasized: procurement constraints, multi-agency interoperability, and the longer authorization cycles common in government acquisition. Public-sector adopters of v2 face additional complexity but have advantages in some areas: their procurement leverage can drive vendor adoption of attestation patterns, and their authorization frameworks (FedRAMP, FedRAMP 20x, DoD impact levels) increasingly require the evidence v2 recommends. The combined effect is that public-sector cloud-native deployments are becoming early adopters of the most mature supply-chain patterns rather than laggards, reversing a historic pattern where commercial deployments led and government followed.
What gaps does v2 explicitly leave open?
v2 is more candid than the original paper about what it does not cover. The paper acknowledges that human and organizational factors (developer training, security culture, executive buy-in) are critical to supply-chain security but are addressed by other CNCF working groups and other industry resources rather than by v2 itself. It acknowledges that the recommendations assume a level of platform-engineering maturity that small teams may not have, and points to lighter-weight starter materials (the Secure Software Factory reference architecture, the OpenSSF concise-guides series) for organizations not ready for the full reference architecture. It acknowledges that the model deployment side of cloud-native systems — service meshes, ingress controllers, secrets management — receives less detailed treatment than the build and registry side, and signals that future TAG Security work will address those areas. And it acknowledges that the AI/ML supply chain (model artifacts, training data, fine-tuning lineage) is in scope conceptually but receives less detailed treatment because the patterns are still solidifying. Future revisions will address each of these gaps; for now, organizations adopting v2 should be aware that gaps exist and plan to consult complementary resources where needed.
How Safeguard Helps
Safeguard implements the v2 reference architecture as platform features rather than aspirations. SBOM emission integrates with build systems to produce CycloneDX 1.7 and SPDX 3.x BOMs signed via Sigstore. Build attestations under SLSA v1.0 and v1.1 are produced and verified continuously. The central attestation store is Safeguard's component graph, with GUAC-compatible export. Admission gating is supported via webhook into Kubernetes admission controllers and CI/CD platforms, evaluating policy against attestation bundles per artifact. Workload identity verification is handled via integration with Sigstore, SPIFFE, and the major cloud OIDC providers. Griffin AI ties the v2 patterns to your actual posture, surfacing which CNCF-recommended controls are in place, which are partial, and which are missing, so platform teams adopting v2 have a structured maturity assessment rather than an open-ended best-practice document.