An air gap is a physical isolation of a computer system or network from unsecured networks, including the public internet. Air-gapped systems have no wired or wireless connections to external networks; data transfer requires physical movement of approved storage media or one-way data transfer devices. Air gaps are the most fundamental security control for the most sensitive classified information systems: no amount of software security can compensate for a physical network connection when the threat model includes nation-state adversaries with sophisticated offensive cyber capabilities.
Deploying and maintaining modern software on air-gapped systems requires a fundamentally different engineering approach from internet-connected deployments. The convenience features that development teams rely on — automated package managers that pull dependencies from public repositories, container images pulled from Docker Hub or public registries, CI/CD pipelines that reach external SaaS services, configuration management tools that communicate with cloud control planes — all fail in air-gapped environments. The software must work without any of these connections, and the development and operations process must be designed to support this from the start.
What Air-Gap Means and Where It Is Required
Air gaps are required wherever the classification or sensitivity of the data being processed or the systems being controlled warrants physical network isolation. In military contexts:
Sensitive Compartmented Information Facilities (SCIFs) are physically secured rooms or buildings where classified information above SECRET — particularly SCI (Sensitive Compartmented Information) — can be processed and discussed. Computing systems within a SCIF handling SCI-level data must be air-gapped from networks that are not accredited to the same classification level. The physical security of the SCIF (controlled access, sound masking, electromagnetic shielding in some cases) combined with the air gap creates the security boundary.
Classified operational networks — SECRET or higher — are air-gapped from unclassified networks. Data transfer between classification levels requires a Cross-Domain Solution (CDS): a hardware-software system that enforces information transfer rules (content inspection, format validation, one-way transfer enforcement) between the two network levels. The CDS itself is a specialized security product that must be evaluated and approved by a national security authority.
Weapon system controllers and embedded systems — fire control computers, navigation systems, radar and sensor controllers — are air-gapped from operational networks as part of their security architecture. Software updates to these systems are delivered via the platform's maintenance interface, using approved media, following a documented and tested procedure.
Software Deployment Without Internet: Artifact Registries and Package Mirrors
In an air-gapped environment, every software dependency that an application needs must be present in the environment before deployment. Nothing can be pulled from the internet at deployment time. This requires building out an internal artifact ecosystem that mirrors the external resources the application would otherwise rely on.
Harbor is the CNCF-graduated open-source container registry, and it is the standard choice for internal container image registries in air-gapped defense environments. Harbor provides: image storage and replication (to distribute images to multiple air-gapped environments from a single source), image vulnerability scanning (via Trivy), content trust (digital signature verification for images), and role-based access controls. Populating the Harbor registry requires a process to import pre-approved, pre-scanned container images from outside the air gap via approved media.
Offline package mirrors replicate public package repositories for use inside the air gap. For Python, an internal PyPI mirror (using tools like bandersnatch or devpi) serves pip requests from inside the environment. For npm, an Nexus or Artifactory instance (or the open-source Verdaccio) serves npm requests. For container base images, a process syncs approved images from the external registry to the internal Harbor instance. The package mirror must be populated and kept current through the approved media transfer process.
The dependency management process must be explicit: before beginning development on a feature that will be deployed to an air-gapped environment, the developer must explicitly identify all dependencies (including transitive dependencies) and verify that they are present in the internal mirror. Adding a new dependency requires a media transfer request and approval process — typically involving security review of the new package before it is admitted to the air-gapped environment. This process slows down development and must be budgeted into sprint planning.
Patch Management: Tested Bundles and Change Control
Patch management in air-gapped environments cannot use automated patch management systems that pull updates from vendor cloud services. Instead, patch management requires a defined, documented process for bringing patches from outside the air gap to inside it, testing them in a representative environment, and applying them in a controlled manner.
Patch bundle preparation begins outside the air gap: the patch management team identifies required patches (from vendor security bulletins, CISA Known Exploited Vulnerabilities catalog, and STIG updates), downloads them from vendor sources, verifies their authenticity (checksum and digital signature verification), and packages them for transfer. The bundle is reviewed by the security team and approved for transfer through the approved media workflow.
Transfer via approved removable media is the standard mechanism for moving patches across the air gap. Approved media procedures typically involve: using only organization-managed media (not personally-owned USB drives), virus scanning media on both sides of the air gap, using write-once media (optical discs) for irreversible audit trails, documenting every transfer with the contents, date, approver, and handler, and destroying media that has crossed from a higher to a lower classification environment according to classification destruction procedures.
Staged testing is non-negotiable for air-gapped operational systems: patches must be tested in a staging environment that mirrors the production configuration before they are applied to production. A patch that destabilizes an air-gapped production system cannot be rolled back by simply pulling the previous version from an internet source — the rollback mechanism must also be pre-staged in the environment.
Secret Rotation in Air-Gapped Environments
Secrets — TLS certificates, database credentials, API keys — expire and must be rotated. In internet-connected environments, secret rotation is increasingly automated: HashiCorp Vault dynamically generates and rotates credentials; certificate management tools (cert-manager in Kubernetes) automatically renew TLS certificates via ACME. None of these automated mechanisms work in air-gapped environments because they rely on network connectivity to certificate authorities and secret management APIs that are not accessible from inside the air gap.
Hardware Security Modules (HSMs) provide the root of trust for cryptographic operations in air-gapped classified environments. An HSM (such as a Thales Luna or nCipher nShield device) stores private keys in tamper-resistant hardware, performs cryptographic operations without exposing key material, and provides FIPS 140-2 Level 3 or Level 4 validated security — meeting the requirements for classified system cryptographic modules under CNSSP No. 15.
Offline vault and key ceremony procedures define how secrets are rotated without automated tooling. A key ceremony is a formal, documented procedure — with multiple authorized personnel present — for generating, loading, or rotating cryptographic keys. The ceremony is recorded in detail (who was present, what actions were taken, in what order) to provide an audit trail. For TLS certificate rotation, the ceremony involves generating a new certificate request, signing it with the offline CA's key (stored in the HSM), and distributing the new certificate to consuming systems via approved media.
CI/CD for Air-Gapped Environments
Continuous integration and deployment pipelines can operate in air-gapped environments with the right tooling choices. The pipeline infrastructure must be entirely self-contained within the air gap, with no cloud service dependencies.
GitLab Community Edition deployed on-premises is the standard self-hosted git and CI/CD platform for air-gapped environments. GitLab CE provides git repository hosting, merge request workflows, CI/CD pipeline execution (using GitLab Runners deployed in the same environment), package registry (for artifacts), and container registry (for Docker images). No cloud connectivity is required — all GitLab functionality is self-contained.
GitLab Runners must be configured with access to the internal package mirrors (internal PyPI, npm, Maven mirrors) rather than external package repositories. Pipeline stages that would normally call external services (container vulnerability scanning via cloud APIs, SAST tools that require license validation, notification webhooks) must be reconfigured to use internal equivalents or disabled.
Key insight: The most expensive mistake in air-gapped defense software programs is designing the software for internet-connected deployment and attempting to retrofit it for air-gapped operation late in the development cycle. Air-gap compatibility must be a design requirement from day one: no cloud service dependencies in the core application, all dependencies explicitly catalogued and available in internal mirrors, and the deployment and operations process designed around the transfer workflow from the beginning.