Air-gapped deployments are a packaging problem first#
Air-gapped environments create a blunt constraint: you cannot “just pull” what you forgot. That turns normal cloud-native deployment habits into operational risk. Every missing container image, Helm chart, or supporting file becomes a new trip across a boundary, plus more chances to make mistakes.
In OpenSSF’s “What’s in the SOSS?” podcast episode published May 5, 2026, host Sally Cooper speaks with Brandt Keller (Defense Unicorns) about Zarf, an OpenSSF Sandbox project designed around that constraint. Keller frames the core problem in plain terms: software comes from many places, and teams need a reliable and repeatable way to package everything required to run an application—especially when there is no internet connectivity to fetch dependencies on demand.
That framing matters because it’s easy to treat air-gapping as a special network topology. In practice, it forces you to be explicit about your artifacts, your sources, and your handoffs. The “deployment tool” becomes a “distribution tool,” and the distribution process is where supply chain controls either happen or don’t.
What Zarf is (as described in the episode)#
Keller describes Zarf’s origin as a tool built for “the most critical environments” that are air-gapped: environments that cannot reach upstream registries, chart repositories, or external package sources. The goal is to package the disparate pieces needed to run software—container images, Helm charts, and other files—into a single transferable archive.
A few specific themes from the conversation:
- Reliability and repeatability are the baseline requirement. If you can’t reproduce the bundle, you can’t trust what you deployed.
- Transparency is part of the point. You should be able to see what you’re moving into the environment.
- The air-gapped constraint drives discipline. In connected environments, missing artifacts can be fetched at runtime. In an air-gapped environment, missing artifacts become outages, delays, or policy exceptions.
The episode also notes that Zarf has evolved beyond a niche air-gap helper into a more agnostic distribution workflow, with integration points into GitOps-style operations. The high-level idea: keep the inputs declarative and the process consistent, so the same package can be moved and applied predictably.
Security gates and “one workflow” pressure#
One of the more relevant claims in the podcast is not “Zarf makes you secure.” It’s closer to “Zarf is a place to put security controls that teams otherwise bolt on inconsistently.” Keller describes Zarf’s current role as introducing security gates, improving transparency, and consolidating “various management and SBOM tools” into a single declarative workflow.
There are two important implications here:
First, if security checks exist but are scattered across scripts, CI jobs, and tribal knowledge, they are easy to skip under time pressure. A packaging step that is mandatory for the environment becomes a natural choke point for policy enforcement.
Second, consolidation cuts operator cognitive load. In air-gapped settings, teams already juggle transfer processes, approvals, and artifact custody. If the packaging tool can reduce the number of bespoke steps and hand-curated lists, it may reduce the chance of human error. That is a security gain even when no new cryptography is introduced.
The episode’s description also suggests Zarf is trying to make “what’s included” and “what’s expected” explicit in a declarative manifest. That matters for audits and incident response: when you can’t easily reconstruct what was moved and why, you end up arguing from memory.
Why maintainers and integrators care (beyond air-gaps)#
Even if you never deploy into a fully disconnected network, the problems Zarf targets show up in less extreme forms:
- Regulated environments that require controlled ingress of software artifacts.
- Production networks that restrict outbound access (intentionally or in practice).
- Disaster recovery plans where you cannot assume upstream availability.
- Organizations trying to reduce “build it live from the internet” behavior.
Keller also connects the tool’s declarative model to open source maintainership: the claim is that packaging and manifests can reduce the cognitive burden on maintainers and give integrators more confidence in upstream artifacts.
Treat that as an intended outcome, not a guaranteed property. A declarative spec helps, but confidence ultimately depends on what the spec includes, how artifacts are sourced, and whether consumers verify what they receive. Still, the direction is sensible: fewer implicit steps and fewer “it worked on my cluster” assumptions.
Practical takeaways: what to look for in any air-gap packaging approach#
The episode is an introduction, not a full technical deep dive, but it points to evaluation criteria that travel well:
🧩 Packaging completeness
If your deployment depends on Kubernetes artifacts, container images, charts, and configuration, your bundling process should be able to capture all of them in a predictable way. The “we forgot one image tag” failure mode is not rare.
🔎 Transparency of contents
You want to answer: What exactly is inside the bundle? Where did each artifact come from? Can you produce an inventory that humans can review and systems can validate?
🧱 Declarative manifests over ad hoc scripts
A declarative model can make deployments more repeatable and reviewable. It also makes it easier to diff changes between releases.
🚧 A natural place for security gates
If your environment already forces a packaging step, that step is a pragmatic insertion point for checks (SBOM generation/validation, policy checks, provenance expectations). The key question is whether the workflow makes checks easier to apply consistently.
🔁 Fit with how teams actually operate
Keller mentions GitOps integration as part of Zarf’s evolution. In practice, packaging tools succeed when they align with existing delivery patterns (CI/CD, GitOps, change control) instead of requiring a parallel universe of process.
What not to overclaim from this source#
This source is a podcast episode and an accompanying write-up. It describes intent, evolution, and positioning, but it does not provide quantitative outcomes or independent verification.
Specifically, the episode summary does not establish:
- that Zarf prevents specific classes of supply chain attacks
- measured reductions in incidents or deployment failures
- which SBOM tools are consolidated, how, or with what guarantees
- adoption numbers, performance characteristics, or maturity claims beyond “OpenSSF Sandbox Project” status
If you are evaluating Zarf (or any similar tool), you should treat the podcast as a starting point for questions, not a decision memo.
What readers can check next#
If this problem space is yours, the next useful steps are concrete:
-
Review Zarf’s documentation and manifest model (the episode references zarf.dev) and see what artifacts it can package and how it represents them.
-
Map your current air-gap (or restricted-egress) workflow end-to-end: where artifacts originate, how they are transferred, where they are stored, and where verification happens.
-
Identify your “security gate” candidates. If you already run SBOM generation, signature verification, or policy checks, decide which should happen at packaging time, transfer time, or deploy time.
-
Validate operational ergonomics. A tool that is theoretically safer but operationally painful often gets bypassed.
Air-gapped environments make mistakes expensive. Tools like Zarf are interesting because they treat packaging and transfer as first-class deployment concerns—and because they offer a place to make supply chain controls routine rather than exceptional.