Secure software delivery into air-gapped networks: the transfer pipeline

An air-gapped network has no path to a package registry, no route to an update server, and no way to phone home to a certificate authority. Every byte of software that enters it must be deliberately introduced, accounted for, and proven trustworthy before it runs. The mechanism that does this – packaging an update on the connected side, moving it across the physical boundary, and verifying it on the isolated side – is the transfer pipeline. This article examines how to build one that is fast enough to keep an enclave patched and rigorous enough to satisfy a high-assurance accreditation: signed bundles, transfer guards, verification on import, reproducible builds, and the offline mirror that ties it all together.

Why air-gapped delivery is a different problem

On a connected network, software delivery is a solved convenience: a host pulls from a registry, validates a signature against an online trust chain, and installs. None of that is available across an air gap. The isolated network is physically severed from the internet – and frequently from every other network – precisely so that an attacker cannot reach it remotely. That same isolation removes every assumption a normal update pipeline relies on. There is no online revocation check, no live dependency resolution, no telemetry channel, and often no return path at all.

The consequence is that the entire trust decision must be made with information that travels inside the bundle itself. The bundle has to carry its own proof of authenticity, its own complete dependency set, and its own provenance metadata. The high side cannot ask anyone a question; it can only verify what it already holds against what just arrived. This shifts the engineering burden from the moment of install – where it lives on a connected system – to the moment of packaging and the moment of import. Get those two boundaries right and the air gap becomes a controllable channel rather than an operational dead end. This is closely related to the broader engineering discipline of air-gapped deployment for defense software, which covers the standing environment that the pipeline feeds.

Signed bundles: the unit of transfer

The atomic unit that crosses the boundary is a signed bundle. A bundle is a single archive containing everything the update needs – application binaries, container images, OS packages, configuration manifests, migration scripts, and a software bill of materials (SBOM) – accompanied by a manifest that lists every file with its cryptographic hash. The manifest is then signed with a private key held by the release authority, ideally in a hardware security module or an offline key store that never touches a connected machine.

The signature does one specific job: it proves that the bundle was produced by the legitimate release pipeline and has not been altered since. On import, the air-gapped side verifies the signature against a public key or certificate that was provisioned into the enclave ahead of time, out of band. Because the verification key is already inside the enclave, no online lookup is needed. This is the inversion that makes air-gapped trust work – the trust anchor is pre-positioned, and the bundle is checked against it locally.

What goes in the manifest

A robust manifest is more than a file list. It records the bundle version, the previous version it is intended to follow, the build identifier, the SBOM digest, and a per-file hash table. Recording the predecessor version lets the high side reject an out-of-order or replayed bundle: an enclave running version 14 should refuse a bundle that declares itself a successor to version 11, because that ordering is either a mistake or a downgrade attack. Treating the version chain as part of the signed payload – not as loose metadata – closes a class of rollback attacks that pure signature checking misses.

Reproducible builds and dependency vendoring

A signature proves who built an artifact. It does not prove that the artifact corresponds to the source code that was reviewed and approved. Reproducible builds close that gap. A reproducible build produces byte-for-byte identical output every time the same source is compiled with the same pinned toolchain, which means an independent second builder can rebuild the release and confirm the resulting artifact hash matches the signed bundle. When two unrelated builders arrive at the same hash, you have strong evidence that the bundle reflects exactly the reviewed source and nothing was injected during compilation.

Reproducibility is only achievable if every input is pinned. That is where dependency vendoring comes in. On a connected build, dependencies are resolved live from upstream repositories – an option that simply does not exist downstream of the air gap. So the build must resolve, download, and pin every dependency by digest on the connected side: language packages, OS packages, and container base images all referenced by their content hash rather than a mutable version tag. Pinning by digest rather than tag is the difference between a bundle that builds identically forever and one that silently drifts as upstream tags move.

The vendored dependency set then travels inside the bundle, so the high side never needs to fetch anything. The SBOM enumerates every one of these inputs, giving the import-side reviewer a complete, verifiable inventory. This same SBOM is what makes supply-chain auditing possible inside an environment that can never run an online vulnerability scanner against a live network.

Transfer guards: moving bytes across the boundary

Once a bundle is built and signed, it must physically cross the air gap. There are two dominant mechanisms, and the choice between them shapes the whole pipeline.

Data diodes. A data diode is hardware that permits data flow in exactly one direction – typically low-to-high – and makes the reverse direction physically impossible, not merely policy-forbidden. A diode lets you push bundles continuously into the enclave with full auditability and no risk of data exfiltration through the same channel. The engineering cost is that a true one-way link has no acknowledgement path, so the transfer protocol must add forward error correction and redundant transmission to tolerate loss without a back-channel retransmit request. Diodes are the right answer when delivery cadence is high and the boundary must stay continuously available.

Removable media. The alternative is a manual sneakernet transfer: the bundle is written to write-once optical media or a dedicated, controlled USB device and physically carried across the boundary by an authorized person. This is procedurally simpler and needs no special hardware, but its security depends entirely on media-control discipline – unique media tracking, mandatory scanning on a sacrificial inspection host, and write-once media to prevent a device from carrying data back out. For tightly classified work, the formal handling of high-to-low and low-to-high transfers overlaps heavily with the discipline of a cross-domain solution, which adds inspection and filtering between classification levels.

Whichever mechanism is used, the guard must never become a bidirectional convenience. The most common failure in field deployments is an operator who, frustrated by one-way transfer, introduces a USB device that has touched a connected machine and then carries it back – quietly turning the air gap into a two-way bridge.

Verification on import: the moment of trust

Import is where the bundle earns the right to run. The high side performs a fixed, ordered sequence of checks, and a failure at any step stops the process – verification failures are security events to be logged and investigated, never retry conditions to be worked around.

First, the signature on the manifest is verified against the pre-provisioned public key, before a single file is extracted. Second, every file is unpacked into a quarantine area and its hash recomputed and compared to the manifest entry; any mismatch fails the bundle. Third, the declared predecessor version is checked against the currently installed version to enforce monotonic ordering and block downgrades. Fourth, the SBOM is reconciled against the extracted contents so the reviewer can confirm the inventory is complete and matches what was approved on the low side.

Only after all four checks pass do the artifacts move out of quarantine. Handling secrets that ride along with a release – signing certificates, service credentials, encryption keys – follows the same offline-first principle described in secrets management in defense CI/CD pipelines: nothing in plaintext, every key bound to an HSM or vault, rotation planned around the transfer cadence rather than around an always-online assumption.

The offline mirror and the deployment step

A single bundle patches a system once. Keeping an enclave maintained over years requires a standing offline mirror: a local container registry, a local OS package repository, and a local artifact store, all seeded exclusively from imported bundles. The mirror is what lets services inside the enclave deploy and scale using ordinary tooling – pulling images and packages from the local mirror as if it were upstream – without any of them needing network access. Each verified import adds to the mirror; nothing is ever fetched from outside.

Deployment itself must assume that a fix can fail in an environment where the next bundle might be days away. Every update is therefore deployed with a tested rollback path so a failed installation reverts to the prior known-good release using artifacts already resident in the mirror – never requiring a fresh transfer to recover. The full sequence, from build to running system, is recorded in an immutable audit log: build identifier, transfer record, verification result, deployment outcome. That unbroken chain is what an accreditation review reads to confirm the enclave only ever ran software whose provenance can be traced end to end.

Putting the pipeline together

A working air-gap delivery pipeline is the composition of five disciplines: reproducible builds with vendored dependencies on the low side, signed bundles as the unit of transfer, an auditable one-way transfer guard, an ordered verification gate on import, and an offline mirror feeding rollback-capable deployments. Each compensates for an assumption that the air gap removes. None of them is optional – a pipeline missing reproducibility cannot detect a tampered build, one missing version-chain enforcement is open to downgrade attacks, and one missing a return-path discipline is not really air-gapped at all. Built together, they turn an isolated network from a maintenance liability into a controllable, accountable channel that can be kept current without ever compromising the isolation that justifies it.