Architecture Air-Gapped

How air-gapped fleets stay current on CVEs

July 16, 2026·11 min read·Chris Boker, Founder, CVEasy AI
A rust-outlined trust boundary on the right holds a small vertical pipeline of nodes for verify, import, and validate, while on the left a teal stack of feed sources funnels into a signed bundle envelope with a gold cosign seal, and a bold rust one-way diode arrow crosses the boundary carrying the bundle inward

In a defense integrator's operations center, the security team runs a Tuesday ritual. Someone builds a bundle of vulnerability intelligence on the internet side, signs it, walks a laptop through a locked door, and imports the bundle into the enclave that scans the classified fleet. The gap holds; the intelligence the gap depends on changes every day. Every serious air-gapped operator runs a version of this ritual, and most cannot cleanly answer three questions about it: who built the bundle, from what sources, and how would we roll back if the wrong file made it in. This piece is the deep dive on the one problem our recent local-first CTEM reference architecture left explicitly open, which is staying current without egress.

The freshness math changed in 2026

Two shifts in the last eighteen months make the old habits dangerous. NIST deprecated the legacy NVD data feeds in December 2023 and fully retired them on August 20, 2025, so any team still running a nightly wget of the JSON dumps needed a new plan by the end of last summer. Bulk mirroring now means paging the NVD API 2.0 or leaning on community reconstructions like fkie-cad/nvd-json-data-feeds. The more consequential shift arrived this April: NIST announced that most backlogged pre-March-2026 CVEs would be marked "Not Scheduled," with active enrichment reserved for KEV records, federal-mission-critical software, and CNA-supplied CVSS the NVD now defers to. A mirrored NVD without CISA Vulnrichment or ADP supplements is increasingly sparse. And the April 2025 funding scare, when the MITRE CVE contract lapsed on the 16th and CISA extended it about seventeen hours later before the CVE Foundation was announced that same week, is the plain-language argument for locally owned, mirrored, signed vulnerability intelligence.

The prior art we adopt rather than reinvent

Every piece needed to build this pipeline already exists in production, and honest credit belongs first. The Update Framework (TUF) is a CNCF-graduated specification for signed update metadata with rollback protection, threshold signing, and expiry, which is the right primitive for the metadata layer. Sigstore's cosign supports fully offline verification through protobuf bundles with stapled Rekor inclusion proofs and a locally provisioned trusted root, so the artifact layer has a working answer too. FIRST publishes EPSS scores as daily CSV downloads that need no live API, and CISA maintains a CC0 GitHub mirror of KEV. Tenable ships an offline plugin update workflow for Nessus, Filigran's OpenCTI 6.0.10 diode import pattern shows a working shape for one-way threat intelligence ingestion, and Dragos has shipped weekly knowledge packs to disconnected OT sites for years as the closest existing precedent in spirit. Each of these solves one slice; none is the whole pipeline.

Where the open ground actually sits

Look across those bodies of work and the gap is obvious. No published, feed-agnostic reference pipeline composes aggregation, normalization, TUF metadata signing, Sigstore artifact signing, one-way transfer, verified import, freshness attestation, and rollback into a single design a security team could adopt whole. Freshness versus air-gap latency is not written up as a real per-feed budget, so most teams over-refresh cheap feeds and under-refresh the ones the SLA depends on. STIX and TAXII have no offline profile. Post-2026 NVD degradation is not something offline consumers can inherit from mirroring alone. Those four items are where a new contribution is honest.

The wrong pattern that keeps happening

An analyst downloads a zip on the internet side, sticks it on a USB drive, and hands it to whoever is walking through the boundary today. Nobody records what version of what feed was pulled, nothing is signed, and if a bad file gets in there is no rollback because there is no known-good baseline. The auditor asks who built the bundle, from what sources, at what time, and against what schema, and the answer is a shrug about "the usual places, in the usual format." That is an air gap with a laundered breach path attached, and it persists because nothing between "informal" and "buy a commercial cross-domain solution" is documented well enough to just build.

An eight-step pipeline that stays defensible

The pipeline shape that keeps holding up under review has eight steps, and every step is required to produce evidence a reviewer can point at.

  1. Collect. On the internet side, a build host pulls each source with the source's own protocol: NVD API 2.0, EPSS daily CSV, KEV JSON, vendor advisory feeds relevant to the deployed fleet, MITRE ATT&CK JSON, Vulnrichment and ADP supplements, and whatever exploit-maturity signals the program subscribes to. Record source URL, pull timestamp, HTTP status, byte count, and SHA-256 for each pull.
  2. Normalize. Convert each source into a canonical shape the local intel store understands, reject records that fail schema validation, and log the rejection. Do not guess missing fields on the way through.
  3. Sign. Produce a TUF-signed metadata layer over the canonical bundle, then sign the bundle artifact with cosign using a hardware-backed key and include the Rekor inclusion proof so the receiver can verify without ever reaching Rekor. The trusted root itself gets its own refresh path across the gap on a slower cadence.
  4. Transfer. A data diode is the strongest option, a manual review guard is the workable middle, and a scheduled sneakernet with two-person integrity is the honest floor. Any of the three is fine if the receiver verifies before importing.
  5. Verify. On the inside, a TUF client checks metadata, cosign verify --offline --trusted-root checks the artifact against the local trusted root, and the receiver rejects anything past its expiry window without ceremony.
  6. Import. Write into the local intel store atomically. The previous bundle stays in a rollback slot until the new one passes validation.
  7. Validate. Run cheap post-import checks that catch bundles which verified cryptographically but were built wrong: record counts within expected bounds, a small set of sample lookups that should always resolve, a diff of the priority queue against yesterday's with unexplained deletions flagged, and a KEV coverage sanity check.
  8. Roll back. If validation fails, restore the previous good bundle in one move and notify the pipeline owner. The rollback path is what lets the pipeline move quickly, because a bad bundle becomes a boring alert instead of an incident.

What belongs in the bundle, and what does not

The bundle carries CVE metadata pulled through the NVD API 2.0, EPSS scores, KEV, vendor advisories for products actually deployed inside the boundary, ADP or Vulnrichment supplements, exploit-maturity signals from sources the program has chosen to trust, and detection content the SOC will actually consume. What does not belong is arbitrary threat intelligence scraped from the open internet, community-supplied indicators of unknown provenance, and anything that cannot be traced back to a named trusted source. Bundle discipline is what makes the audit conversation short.

The provenance manifest, one shape

A single JSON file ships alongside the bundle and answers every question an auditor is going to ask in one place: builder identity keyed to a hardware certificate, each source with its canonical URL and schema version, per-source pull timestamps and SHA-256 hashes, bundle schema version, TUF signature reference, cosign bundle reference, and a link back to the pipeline commit that produced it. When the auditor asks who built this and from what, you point at one file and the conversation lasts about a minute.

Freshness budgets deserve their own SLA

Feeds age at very different rates and the pipeline SLA has to reflect that. KEV updates should land inside hours because federal BOD deadlines run in days, EPSS is a daily feed and a daily budget is appropriate, NVD metadata is daily, CPE dictionary churn is weekly, and detection content is typically weekly. Set an alarm per feed type that fires when the last verified import is older than the budget, and route it to whoever owns the pipeline. Freshness alarms are what prevents an air-gap program from silently drifting into staleness under an otherwise clean audit.

STIX and TAXII need an offline profile

The community standards for threat intelligence exchange, STIX and TAXII, assume TAXII clients that reach out to TAXII servers. There is no ratified offline profile, and the space where one would sit is exactly what this pipeline addresses. A modest proposal: a signed STIX bundle format that staples COSE or PKCS#7 signatures over a collection, a manifest listing source Collection URIs and time windows, and a transport-agnostic wrapper the community could ratify. Naming the profile matters even before adoption, because folk practice cannot be improved while it stays invisible in the standards conversation.

Scoring stays inside the boundary

The pipeline moves raw intelligence across the gap and stops there. Prioritization has to happen locally, because the input that makes prioritization meaningful is your asset inventory, and that inventory never crosses the boundary in a local-first design.

CVEasy uses this pipeline to keep customer enclaves current without asking any asset map to leave the boundary, and TRIS scores against the local exposure entity so scoring inherits the same locality guarantee.

Related Reading