Airgapped DevSecOps: a working pipeline with zero internet access
A fully airgapped DevSecOps pipeline is not a compromise; done right, it is often better than connected setups: single-binary scanners in CI, signed vulnerability-data bundles imported on your schedule, deterministic gates, and a dashboard inside the perimeter. The design principles are offline-first tooling, verifiable data transfer, and reproducibility everywhere.
Conventional wisdom says DevSecOps needs the cloud: SaaS scanners, live vulnerability feeds, tools that update themselves. Then there are the networks where none of that is allowed, running some of the most critical software in existence. Here is how a complete, modern security pipeline works with zero internet access, based on how airgapped environments actually operate.
The architecture in one paragraph
Every scanner is a static binary that runs offline. Vulnerability and detection data arrives as a cryptographically signed bundle, carried across the boundary through your existing controlled-media process and verified on import. Findings flow to a dashboard that lives inside the perimeter. Nothing in the pipeline has, or wants, a route out.
Piece 1: scanners that do not phone home
The foundational requirement is tooling with no runtime network dependency: no license callbacks, no cloud analysis, no auto-update. This is a real filter; a surprising amount of commercial tooling fails it quietly, degrading or refusing to run without connectivity.
What passes the filter looks like the SecuNexa engines: single static binaries, no runtime to install, invoked as ordinary CI steps. A pipeline stage that runs secusast analyze ./src and reads an exit code works identically in a connected datacenter and a sealed enclave.
Piece 2: vulnerability data as a supply chain you control
The standard objection to airgapped scanning is data staleness. The answer is to treat vulnerability data as a deliberate, verifiable supply chain:
- On a connected system, download the signed data bundle.
- Verify its signature there.
- Transfer it across the boundary through your media-control process.
- The platform verifies the Ed25519 signature again on import, and every report thereafter records which bundle version it was evaluated against.
That last detail converts a perceived weakness into an audit strength: connected tools using live feeds can rarely tell you exactly what data a last-month scan used. An airgapped pipeline with versioned bundles always can, which makes results reproducible and evidence defensible.
Piece 3: gates that work without asking anyone
Build gates in an airgap must be self-contained: threshold evaluation happens in the engine, expressed as exit codes. “Fail on new critical findings or known-exploited vulnerabilities” executes locally in milliseconds.
Determinism matters double here. When the same input always produces the same result, a gate failure means the code changed, and any result can be re-verified on another machine inside or outside the enclave. In high-assurance environments, that reproducibility is often what security review boards actually approve.
Piece 4: the dashboard inside the wall
Findings need a home with memory: one queue across all engines, prioritization, SLA tracking, and an audit trail, deployed as an ordinary application on your infrastructure with your database. The SecuNexa dashboard runs precisely this way; there is no cloud control plane to miss because none exists.
The workflow, end to end
A developer merges code. CI runs the engines as local steps: static analysis, dependency resolution against the imported bundle, secrets, container and IaC checks. New criticals fail the merge with the evidence attached. Everything else lands in the dashboard, ranked. Monthly, or on your cadence, a new signed bundle crosses the boundary, the platform re-evaluates stored inventories, and anything newly disclosed against already-shipped builds surfaces without a rescan.
No step in that loop touches the internet. No step is weaker for it.
The mindset shift
Teams coming from connected environments expect the airgap to be a list of sacrifices. In practice, the constraints force properties that connected teams often lack: verifiable data provenance, reproducible results, and tooling that cannot silently change under you. Design offline-first and you do not get a degraded pipeline; you get a more defensible one. If you want to see the whole loop run, we will show it live, in a network that looks like yours.