A US defense prime contractor supporting a DoD mission system operating at Impact Level 7 (IL7) had a deployment challenge that no commercial SaaS security tool could address. The mission system processed classified information in an air-gapped environment accredited under the DoD's most stringent cybersecurity baseline. The contracting officer's latest requirements update mandated supply chain security controls — including continuous SBOM generation, signed build attestation, and reachability-aware vulnerability management — to be operational inside the IL7 enclave. No outbound network path. No cloud connectivity. No telemetry egress. This is an illustrative walkthrough of how Safeguard.sh deploys into air-gapped, classified environments to support exactly these mission requirements.
Why Can't Commercial SaaS Security Tools Operate in IL7?
They cannot operate in IL7 because the environment is fundamentally incompatible with a SaaS operational model. IL7 systems run behind physical isolation or comparable cryptographic separation. Software running inside the enclave cannot call outbound services, cannot send telemetry, cannot check licenses against a cloud-hosted authority, and cannot receive updates except through carefully controlled manual transfer procedures. Any tool whose operational model assumes a connection to its vendor's infrastructure simply cannot function.
The defense prime's Chief Engineer for the mission system described the constraint this way: "Every piece of software that runs in this environment must be fully functional without making a single packet leave this room. That is the bar. Most security vendors cannot cross it." The evaluation team had already ruled out several commercial alternatives before engaging with Safeguard.sh.
What Does an Air-Gapped Safeguard Deployment Look Like?
An air-gapped Safeguard deployment consists of a self-contained instance of the platform running on infrastructure inside the enclave, with a documented procedure for offline updates. The platform includes an embedded vulnerability database, an embedded signature verification authority chain, and embedded language toolchain support for reachability analysis. Nothing the platform does in normal operation requires an outbound call.
Updates — new vulnerability data, new platform versions, new language analyzers — arrive through a controlled offline transfer process. The defense prime's security team used a government-operated one-way data diode for bringing signed update bundles into the enclave from a less restricted environment. Safeguard's update bundles are cryptographically signed and include manifest files that allow the enclave's administrators to verify integrity before installation.
The initial deployment ran on a hardened Linux environment that had already been accredited for other mission-critical tooling. No new hardware accreditation was required. The installation itself took six hours across two maintenance windows.
How Did the Platform Handle Classified Source Code?
The platform handled classified source code by staying entirely inside the enclave. Source repositories hosted on the enclave's internal GitLab instance connected to Safeguard through the enclave's internal network. No source code touched any system outside the classification boundary. SBOM generation ran on build agents co-located with the source repositories, and the resulting SBOMs remained inside the enclave's storage.
Reachability analysis operated entirely on the classified artifacts. Safeguard's static analyzers, which can operate on both source and binary forms, were configured to run on the enclave's build infrastructure with results feeding into the platform's internal graph. No portion of the source code — or any representation of it — left the enclave. This was a precondition for the mission system's authorizing official to approve the platform for use.
The Chief Engineer noted in a post-deployment review that Safeguard's threat model for classified environments reflected a level of federal experience that was rare among commercial vendors. "They did not try to convince us to change our operational constraints. They designed the product to work inside them."
What Mission Requirements Did the Deployment Satisfy?
The deployment satisfied four specific mission requirements that had been added to the program's cybersecurity baseline in the prior year. First, continuous SBOM generation for every deployable mission artifact, with the SBOMs available for operational use inside the enclave. Second, signed build attestation for every artifact, with verification logs retained for audit. Third, reachability-aware vulnerability management, with prioritization feeding into the program's remediation workflow. Fourth, continuous control evidence collection mapped to the relevant NIST 800-53 controls in the system's authorization package.
Each requirement was tracked against a specific Safeguard capability, and the traceability matrix produced during the deployment was included as an appendix to the program's control implementation statement. The authorizing official's staff reviewed the matrix before accrediting the platform for use.
How Did the Platform Integrate With the Program's Existing DevSecOps Pipeline?
The program's existing DevSecOps pipeline ran on internally hosted tooling — GitLab, Harbor, a Nexus artifact repository, and internally operated Kubernetes clusters. Safeguard integrated through standard APIs exposed by each of these tools. The integration was read-pull rather than push-pull, which meant the enclave's network security team could satisfy itself that the integration did not create new outbound paths.
Build events in GitLab triggered Safeguard's SBOM generation and analysis. Container pushes to Harbor triggered image composition analysis. Artifact uploads to Nexus triggered binary composition analysis. Results flowed into the platform's central graph and were queryable through the platform's UI or API.
The program's lead DevSecOps engineer reported that the integration footprint was smaller than anticipated. Other security tools deployed in the same enclave had required significantly more integration work and had produced more operational friction. Safeguard's pull-based integration model, designed around the realities of restricted networks, was a material differentiator.
What Operational Practices Changed for the Program's Engineering Teams?
Operational practices changed in ways that mirrored commercial rollouts, with some classified-environment specifics. Engineers began seeing reachability-aware vulnerability findings on pull requests, which meant the old pattern of shipping code with a long list of dismissable SCA findings was no longer acceptable. SBOMs became artifacts that engineers actually used — for tracking component updates, for coordinating with the program's supply chain risk management function, and for documenting changes at release gates.
Release artifact signing and attestation verification became hard gates in the deployment pipeline. An artifact without a valid Safeguard-generated attestation could not be deployed to mission environments. The program's release engineering team initially flagged this as a potential velocity risk. In practice, after a two-week adjustment period, the signing and verification steps added less than 90 seconds to the end-to-end release process and produced no sustained velocity impact.
What Was the Hardest Part of the Deployment?
The hardest part was producing and updating the vulnerability data that the platform needed to function. In a connected environment, vulnerability data updates flow continuously from upstream sources. In an air-gapped environment, these updates arrive only through the controlled transfer process, and the transfer cadence is limited by operational realities. The program initially set a weekly update cadence, with emergency transfer procedures for zero-day disclosures that required faster ingestion.
Safeguard's operational tooling for vulnerability data updates, including the integrity verification tooling on the receiving end of the transfer, made this workflow predictable. The program's operations team reported that the update workflow became routine within the first month and did not require specialist involvement after initial training.
How Safeguard.sh Helps
Safeguard.sh operates a mission-aligned deployment model for defense, intelligence community, and federal customers requiring software supply chain security inside classified or otherwise restricted environments. The platform supports IL4 through IL7 deployment patterns, air-gapped installation with offline update workflows, and full feature parity with commercial deployments for SBOM generation, build attestation, reachability analysis, and continuous evidence collection. For defense primes supporting DoD mission systems, Safeguard provides traceability matrices mapped to NIST 800-53 and DoD-specific control baselines, and the platform's operational model is designed around the real constraints that classified environments impose rather than around the assumption of unrestricted connectivity.