Air gapped vulnerability management works by moving data instead of connections: vulnerability databases are mirrored into the disconnected environment on a fixed cadence, scanning runs entirely offline against that mirror, and results or SBOMs travel back out through controlled transfer points for reporting. The air gap removes live feeds, SaaS scanners, and automatic updates — it does not remove vulnerabilities, which enter the environment inside every piece of software you bring across the boundary. This guide covers the patterns that make disconnected vulnerability management actually function.
Why is air-gapped vulnerability management harder than the connected kind?
Because almost every modern tool assumes connectivity. Scanners phone home for fresh advisory data. Dependency tools query public registries. SaaS platforms are unreachable by definition. Meanwhile the environment itself is usually high-consequence — defense networks, industrial control systems, payment infrastructure, classified enclaves — so "we could not scan it" is not an acceptable answer.
Three specific gaps hurt most. Data freshness: the NVD and ecosystem advisories publish well over a hundred new CVE records on an average day, and a scanner with a three-month-old database will confidently report a clean system that is riddled with newer issues. Remediation logistics: you cannot apt upgrade from the internet; every patch and package must be staged, verified, and carried across the boundary. Tooling assumptions: many scanners degrade or refuse to run without update checks, license pings, or telemetry endpoints, so tool selection must filter for genuine offline operation.
How do you get vulnerability data across an air gap?
The standard pattern is a two-sided mirror with a controlled transfer:
- Connected side: a staging system downloads vulnerability databases on a schedule — NVD data, OSV, distro advisories (Ubuntu USN, RHEL/OVAL), and your scanner's own packaged database. Trivy and Grype, for example, both publish their databases as downloadable artifacts specifically to support offline use.
- Verification: the bundle is hashed and signed on the connected side, scanned for malware, and its provenance recorded.
- Transfer: the bundle crosses via your approved mechanism — data diode, one-way transfer appliance, or physically escorted media ("sneakernet"). One-way flow into the enclave is the norm; anything flowing out gets separate review.
- Disconnected side: an internal mirror serves the fresh database to all scanners inside the environment, so individual tools never need egress.
Cadence is a risk decision. Weekly transfers are a common floor; daily is achievable with diodes; anything slower than monthly means your scanners are systematically blind to the newest — and most actively exploited — vulnerabilities. Whatever the cadence, monitor database age inside the enclave and alert when it exceeds policy, because silent staleness is the most common failure of the whole model.
What does scanning look like inside the enclave?
Largely normal, once the data problem is solved. Container images, hosts, and application dependencies are scanned against the mirrored database by tools deployed inside the boundary. Two adaptations matter:
- SBOM-centric workflows shine here. Generating SBOMs inside the enclave and matching them against advisory data is cheap, repeatable, and decouples inventory from scanning — you can even carry SBOMs out (subject to review) and perform matching on the connected side, which lets a low-side team monitor high-side exposure without moving any code. This pattern also gives auditors clean evidence.
- Registries and repositories must be internal. An internal container registry and package mirror (for approved, verified packages brought across) is a prerequisite. Every artifact entering the environment should be scanned at the transfer point and again on its internal registry, because the transfer point is your one natural choke point — use it.
Self-hosted platforms matter for the management layer too: findings, ownership, SLAs, and reporting all need to live inside the boundary. Evaluate vendors on genuine offline operation, not a checkbox — pricing and deployment options differ substantially between SaaS-only tools and platforms that can run disconnected.
How do you remediate without internet access?
Patching is where air-gapped programs earn their keep. The working pattern is a staging-and-promotion pipeline: fixes are identified inside (from scan results), the corresponding packages or images are pulled and verified on the connected side, tested in a staging enclave that mirrors production, then promoted across the boundary on a scheduled or emergency cadence.
Prioritization becomes more aggressive than in connected environments, not less, because each transfer cycle has fixed cost. Rank by exploitability and exposure — KEV-listed and network-reachable issues ride the next transfer; low-severity findings batch monthly. The air gap itself is a real mitigating control for remotely exploitable issues and should be reflected in your risk scoring, but it is not immunity: Stuxnet crossed an air gap on removable media, and every USB stick, vendor laptop, and software delivery is a bridge. Insider-reachable and adjacent-network vectors keep their severity.
How do you prove the program works?
Air-gapped vulnerability management programs usually exist because a regulator or accreditor demands them, so evidence is half the job. Track and retain: database freshness at time of each scan, scan coverage (percentage of assets scanned within policy window), remediation SLA attainment by severity, and transfer logs pairing what crossed the boundary with its verification records. Structure findings and SBOMs in standard formats so evidence survives tool changes. A quarterly exercise that traces one CVE from publication, through mirror transfer, detection, prioritization, and patch promotion will find the broken link in the chain before an auditor or an adversary does. For teams building this capability from scratch, the Safeguard Academy covers SBOM formats and vulnerability data sources that underpin offline workflows.
FAQ
How often should vulnerability databases be updated in an air-gapped environment?
Weekly is a common minimum, daily is best practice where data diodes make it cheap. The key control is monitoring database age inside the enclave and alerting on staleness, so a broken transfer pipeline cannot silently blind your scanners.
Can SaaS vulnerability scanners work in air-gapped networks?
Not directly — by definition nothing inside can reach them. Options are self-hosted deployments of a platform inside the boundary, or an SBOM-export pattern where inventories generated inside are carried out and matched against advisories on the connected side.
Does an air gap reduce vulnerability severity?
It mitigates remote exploitation paths and can justify adjusted internal risk scores, but it does not eliminate risk: removable media, supply chain deliveries, and insiders all cross the boundary. Treat the gap as one strong compensating control, not a substitute for patching.
What tools support offline vulnerability scanning?
Open-source scanners like Trivy and Grype publish downloadable databases designed for offline operation, and several commercial platforms offer self-hosted, disconnected deployment modes. The selection test is simple: can the tool complete a scan, with current data, when every external endpoint is unreachable?