Software supply chain security for defense: SLSA, provenance, signing

A fielded defense binary is the end of a long chain of trust. It began as source code written by a developer, passed through dozens of open source dependencies, was compiled on a build server, packaged, signed, and promoted to a release registry before it ever reached an operational network. Every link in that chain is a target. Nation-state adversaries have repeatedly demonstrated that the cheapest way into a hardened defense network is not the front door – it is the build system or a trusted dependency, compromised upstream so that the malicious code is delivered, signed and blessed, by the victim's own pipeline. Software supply chain security is the discipline of making every link in that chain verifiable, so a fielded artifact can be cryptographically traced back to reviewed source through a tamper-evident build.

The defense supply chain threat model

Commercial supply chain security and defense supply chain security share the same vocabulary but a different adversary. A commercial team worries about a vulnerable dependency or an accidental secret leak. A defense team must assume a well-resourced actor who will spend months pre-positioning an implant: poisoning a popular open source package, compromising a build runner, or substituting a tampered compiler. The SolarWinds intrusion – where a build-system implant inserted a backdoor into a legitimately signed product update – is the canonical example, and it reshaped how defense procurement treats software origin.

The threat surface breaks down into four zones. The source zone covers the version control system and the people with commit access. The dependencies zone covers every third-party package pulled into the build, direct and transitive. The build zone covers the build service, its runners, and the toolchain. The distribution zone covers signing, the release registry, and deployment. A defense supply chain control framework has to address all four – hardening one while leaving another open simply moves the adversary's entry point.

What makes this harder for defense than for commercial software is the consequence model. A compromised commercial SaaS update can be rolled back; a compromised firmware load on a fielded radio or an electronic warfare payload may be unreachable, persistent, and operationally catastrophic. The cost of a single tampered artifact is asymmetric, which is why the framework has to be preventive rather than reactive – the goal is to make a malicious artifact unable to pass the pipeline at all, not to detect it after deployment. The controls below are sequenced from source to fielding precisely so that each zone is closed before the next one inherits its outputs.

SLSA: a maturity model for build integrity

SLSA – Supply-chain Levels for Software Artifacts – is the most widely adopted framework for reasoning about build integrity. It is deliberately incremental, defining progressive levels so an organization can measure where it stands and what the next concrete improvement is.

Level 1 requires only that the build process produces provenance: a description of how the artifact was made. This alone catches mistakes and provides a baseline for analysis, but the provenance is not yet protected against tampering.

Level 2 requires a hosted build service that generates and signs provenance. Because a service rather than a developer workstation produces the attestation, tampering by a compromised individual machine becomes detectable.

Level 3 hardens the build platform itself: provenance becomes unforgeable, and builds run in isolated, ephemeral environments that carry no state between runs. This is the level at which a compromised dependency or a malicious build script can no longer silently rewrite what the provenance reports. For mission software, SLSA Level 3 should be treated as the baseline, not the aspiration.

The highest-assurance posture – historically described as Level 4 and now expressed through additional track requirements – adds two-person review of every change and hermetic, reproducible builds. A reproducible build lets an independent party rebuild the same source and confirm, bit for bit, that they get the same artifact. For weapons-adjacent or cryptographic components, reproducibility is the strongest available defense against a tampered toolchain.

Build provenance: how the artifact was made

Provenance is the heart of supply chain assurance, and it is frequently confused with signing. A signature on a binary proves who released it and that it has not changed since the signature was applied. It says nothing about whether the build that produced the binary was trustworthy. If an adversary compromises the build runner, they can produce a malicious artifact that is then signed perfectly legitimately – the signature is valid, the artifact is poisoned.

Provenance closes that gap. A provenance attestation is a signed, machine-readable record describing the source commit, the builder identity, the build parameters, and the cryptographic digests of every input and output. The widely used format is the in-toto attestation, which captures this as a structured statement that the build platform – not the developer – signs. When a verifier later checks the artifact, it confirms not only the signature but that the provenance names the expected source repository, the expected builder, and a commit that passed review.

What a verifier checks

A provenance check at deployment time answers a precise question: was this exact artifact built from the source and process we expect? The verifier compares the artifact digest against the digest recorded in the provenance, confirms the provenance was signed by the trusted build platform's key, and asserts that the builder identity and source URI match an allowlist. A mismatch – an artifact whose provenance names an unknown builder, or whose digest does not match – is rejected before it reaches an operational environment. This is the control that would have flagged a SolarWinds-style substitution.

Provenance also enables incident response that would otherwise be impossible. When a new vulnerability is disclosed in a build tool or a dependency, an organization with complete provenance can query exactly which fielded artifacts were produced with the affected component, by which builder, and from which commit – turning a frantic estimate into a precise blast-radius answer. Provenance retained for the operational life of an artifact is therefore not just a pre-deployment gate but an audit asset that pays off for years after the build.

Artifact signing in defense pipelines

Signing remains essential; it is simply not sufficient on its own. The modern practice is keyless signing backed by a transparency log: an ephemeral key is issued against a verified workload identity, used to sign the artifact and its attestations, and the signing event is recorded in an append-only public or private transparency log. This removes the operational burden and risk of long-lived signing keys living on build servers.

For the highest-assurance components – cryptographic modules, bootloaders, anything tied to a hardware root of trust – defense programs use hardware-backed keys held in a hardware security module (HSM). The private key never leaves the HSM; signing operations are performed inside it. This pairs naturally with secure boot, where the device firmware verifies the signature of each stage before executing it, extending the supply chain's chain of trust all the way down to the silicon.

Dependency verification and the SBOM

The majority of code in any modern defense application is not written by the program – it is pulled in as open source dependencies. Verifying those dependencies is therefore the highest-leverage control in the entire chain. Several practices compound here.

Pinning and hashing. Every dependency is pinned to a specific version and a cryptographic hash, so the resolved dependency tree is deterministic. A build cannot silently drift onto a new, malicious version of a package because the hash would no longer match.

Internal mirroring. Approved packages are mirrored into an internal registry, and builds pull only from that mirror – never directly from a public registry at build time. This gives the program a controlled vetting checkpoint and breaks the build's dependence on internet reachability, which is mandatory for air-gapped and classified environments.

Vulnerability scanning. Each dependency is scanned against vulnerability data such as the OSV advisory database, and the results gate promotion. The output of enumerating every transitive component is a software bill of materials. For the procurement-driven requirements now attached to that artifact, see our analysis of the software bill of materials for defense. The SBOM is generated in a standard format – CycloneDX or SPDX – and attached to the artifact as a signed attestation so it travels with the binary.

Policy enforcement: the admission gate

None of these controls matter unless they block a non-compliant artifact from being fielded. The enforcement point is the admission gate – the moment immediately before an artifact is promoted to a release registry or deployed to an operational environment. At this gate a policy engine performs a set of mandatory checks: it verifies the artifact's signature, validates the provenance against the expected source and builder identities, checks the SBOM against vulnerability data and a prohibited-component list, and confirms the change passed the required two-person review.

The critical design rule is that policy must block, not merely flag. A common failure is to run scanners earlier in the pipeline that emit warnings, while the promotion step has no hard gate – so a flagged artifact still ships when an engineer overrides under deadline pressure. The admission gate must fail closed: if provenance cannot be verified, the artifact does not deploy. Embedding these gates as code, reviewed and version-controlled like any other pipeline stage, is the natural extension of a DevSecOps practice for defense, where security controls are part of every sprint rather than a pre-release audit.

Operating the chain in classified environments

In an air-gapped or classified enclave, the entire chain must run without internet access. Internal mirrors hold vetted dependencies, the build service and transparency log run inside the enclave, and verification keys are distributed through approved channels. Updates to the dependency mirror arrive through controlled cross-domain transfers, each carrying its own provenance so the enclave can re-verify origin before admitting a package. Designing the supply chain for offline operation from the first sprint – rather than retrofitting it – is what makes the difference between a control framework that survives accreditation and one that collapses on contact with a real classified deployment.