Zero trust in the Department of Defense is often discussed as a networking problem. The pillars read like a network architecture diagram: users, devices, networks, applications, workloads, data, visibility, automation. What gets less attention in public conversation but more attention inside the program offices is the software dimension. Applications and workloads only earn trust if the code running in them can be reasoned about. That requirement reaches back through the build systems, the source repositories, the dependencies, the signing infrastructure, and the people who touch them. A zero trust architecture without a zero trust view of software is incomplete, and the DoD's own guidance increasingly reflects that.
The Core Documents
The DoD Zero Trust Reference Architecture, published by the DoD Chief Information Officer with significant contribution from the National Security Agency and the Defense Information Systems Agency, defines the target. Version 2.0 laid out seven pillars and a set of capabilities that map to those pillars. The DoD Zero Trust Strategy and the accompanying Zero Trust Capability Execution Roadmap then translate the architecture into a program of 91 capabilities that services and agencies are expected to achieve by fiscal year 2027, with advanced capabilities extending further.
Within that framework, the software supply chain shows up most directly under the Applications and Workloads pillar, but it threads through Visibility and Analytics, Automation and Orchestration, and Data as well. The DoD Enterprise DevSecOps Reference Design, maintained by the Chief Information Officer and the service DevSecOps teams, provides concrete guidance on how to implement secure software factories. The Software Modernization Strategy issued by the Department in 2022 set the overall direction, and NSA's Enduring Security Framework guidance on developer security adds detail for specific practices.
What Zero Trust Demands of Software
A zero-trust posture assumes that no component is inherently trusted. Every workload, every service, every request must authenticate, be authorized, and be continuously evaluated. That model only holds if the software running inside those workloads is itself trustworthy. A signed container that runs untrusted code is not better than an unsigned container. So the software supply chain has to produce components whose provenance can be verified, whose contents can be enumerated, and whose behavior can be attested before and during execution.
This pushes concretely toward a short list of capabilities. Identities for build systems and for every artifact they produce, backed by cryptographic signatures. SBOMs that accompany artifacts across the lifecycle and can be machine-read by downstream systems. Attestation frameworks like SLSA and in-toto that tie build environments to outputs. Policy engines that evaluate those attestations before deployment. Runtime workload identity that ties the running instance back to an authenticated build lineage. Each of these capabilities is work, and each one ties into a control in the Zero Trust Reference Architecture.
The Software Factory as the Unit of Zero Trust
The DoD's software factories, including Platform One, Kessel Run, and several service-level variants, have become the primary vehicle for applying zero trust to software. A software factory in DoD usage is more than a CI/CD pipeline. It is a curated collection of tools, accreditation artifacts, and approved patterns that allow programs to deliver software with less heroic accreditation effort per release. The factories aim to make zero trust the default: every pipeline ships SBOMs, every artifact is signed, every deployment is policy-evaluated, and every runtime is observable.
The practical results vary widely. Mature programs inside Platform One run pipelines with SLSA-aligned provenance, cosign signatures, and SBOM generation on every build. Less mature programs are still stitching together open source tools and fighting with the authorization boundary. The DoD's Continuous Authorization to Operate, or cATO, model is intended to reward the mature practices by replacing the three-year ATO cycle with continuous evidence of compliance. That model only works if the software supply chain produces usable, machine-readable evidence continuously.
NSA's ESF Contribution
The Enduring Security Framework, co-led by NSA with CISA and ODNI, has published a series of guidance documents for developers, suppliers, and customers. The Securing the Software Supply Chain series defines practices for each role and has been adopted as a reference by several DoD programs. The developer guidance covers source control hygiene, build environment hardening, artifact signing, and vulnerability management. The supplier guidance covers SBOM production, vulnerability disclosure, and customer notification. The customer guidance covers procurement, ingestion, and ongoing monitoring.
Inside DoD, these documents often appear as appendices to program-specific supply chain risk management plans. Acquisition professionals use them to shape statements of work. Security engineers use them to build reference pipelines. Assessors use them as benchmarks when evaluating program submissions for cATO or for platform accreditation.
The SBOM as Zero Trust Evidence
A SBOM is not, on its own, a zero trust artifact. A zero trust evaluation needs to verify the SBOM came from the expected build, matches the artifact being evaluated, and covers the components actually executing. That requires signed SBOMs, attestations that bind SBOMs to artifacts, and runtime mechanisms that can detect divergence. The work to produce those linked artifacts is where the most interesting engineering in DoD DevSecOps is happening right now.
Program offices have started asking their integrators not just for SBOMs but for the signed provenance documents that prove the SBOM came from the expected environment. Several programs now require SLSA Level 3 provenance for high-criticality software and SLSA Level 2 for lower-criticality work. When a vulnerability is disclosed in a widely used library, the program can answer not just whether the library is in the product but whether the shipped artifact actually contains it based on the signed SBOM.
Workload Identity and Runtime Assurance
Zero trust at runtime pushes toward workload identity, often implemented through SPIFFE and SPIRE. A workload gets a cryptographic identity tied to its image, its namespace, and its orchestration context. That identity is used for service-to-service authentication, for accessing data stores, and for participating in a mesh. The connection back to the software supply chain comes through the ability to tie the workload identity to the signed artifact and through policy gates that refuse to start workloads whose identity does not match an approved, attested build.
Several DoD environments have begun requiring workload identity for new applications on Kubernetes platforms, and the platform teams are building the glue that links it to artifact signatures and SBOMs. When fully wired up, this gives a zero trust system the ability to verify at runtime that the code executing matches the code that was attested at build time, and to deny network access to workloads whose lineage does not check out.
Cultural and Contractual Change
The harder part of DoD zero trust for software is not technical. It is contractual and cultural. Program managers have to ask for attestations in their RFPs. Contracting officers have to be comfortable evaluating them. Integrators have to treat them as deliverables rather than as side artifacts. The Defense Acquisition University has been updating its curriculum to cover software supply chain concepts, and the DoD acquisition workforce is slowly getting more comfortable with what a SLSA provenance looks like and what to do with a CycloneDX file.
At the same time, mission partners and allies are watching closely. Five Eyes members have overlapping but not identical requirements, and several NATO members have been aligning their software supply chain expectations with DoD practices. Interoperability at the attestation level is becoming a real concern for joint programs.
How Safeguard Helps
Safeguard produces the software supply chain evidence that a zero trust architecture needs. We generate signed SBOMs and SLSA-aligned provenance from builds, tie those artifacts to workload identities at deployment, and enforce policy gates that block unattested code from reaching production. Program offices use Safeguard to meet the evidence requirements of the DoD Zero Trust Capability Execution Roadmap and to support continuous authorization through machine-readable artifacts. When a zero-day hits a library in use, our customers map exposure across the software factory and respond at the speed that zero trust expects.