// Delivery for disconnected networks
Patched builds for air-gapped networks
OSSeva delivers patched, signed builds of end-of-life open source to your internal Artifactory or Nexus instance, so a production air-gapped environment needs no outbound internet access. Packages, tarballs, images and .NET Windows installers ship with a signature, a checksum, an SBOM and VEX statements, so a disconnected network can check what it receives before it installs.
- Lands in
- Your internal Artifactory, Nexus or Harbor
- Production internet access
- Not required
- Verify with
- GPG key B7C4E831, cosign, SHA-256
- Ships with each build
- SBOM, VEX statements, CVE record
- Patch window
- Critical 48 hours, High 7 days
- Compatibility
- Runtime and OS matrix included with Patch
Last reviewed
The delivery runbook, in the order the network sees it
Air-gapped software patching differs from connected patching in three ways. Software updates cannot be pulled on demand. Every update has to be verified before it enters the environment. And the transfer step adds delay. Five steps take a patched build from a contract to a verified install in a disconnected network. OSSeva handles steps 1, 2, 4 and 5. Step 3 is yours, because it follows your security policy.
- 01
Scope the estate
Name the technologies, the versions and the platforms they run on. Check the versions against the supported versions list. Patch includes a version compatibility matrix for runtime and operating system.
- 02
Land builds in your repository manager
Builds arrive in the Artifactory, Nexus or Harbor instance you already run. That instance is the only source production pulls from, so your deployment tooling does not change.
- 03
Cross the boundary on your route
If the repository manager sits inside the enclave, the build crosses on the transfer path your security policy allows: a connected staging host, a one-way transfer, removable media. Agree the route and the cadence when the scope is set.
- 04
Verify inside the enclave
Run the signature and checksum checks below on the receiving side, before the build reaches a host.
- 05
Install, then file the record
Builds are binary-compatible drop-ins for upstream, so you install them the way you install the upstream release. Keep the SBOM, the VEX statements and the CVE record with your change ticket.
Your transfer cadence is your exposure window
The patch window is OSSeva's time to ship a build: Critical CVEs within 48 hours and High within 7 days. In a connected network that is close to the time to install. Behind an air gap the time from release to install adds your transfer cycle, your testing and your change window.
A monthly transfer cycle means a Critical fix shipped in 48 hours can wait up to a month to cross. A rule with a one-month install window, such as PCI DSS v4.0.1 Requirement 6.3.3 for patches to critical vulnerabilities, leaves little room for that cycle plus testing (see the compliance matrix). Decide in advance which severities get an out-of-cycle transfer.
Formats and platforms
What each platform receives. Which technologies and versions exist in each format depends on the line: check the supported versions page and send the exact platform through the form.
| Platform | Delivered as | Where it lands |
|---|---|---|
| Debian-family Linux | Signed DEB packages | Your internal repository manager |
| RPM-based Linux | Signed RPM packages | Your internal repository manager |
| Containers and Kubernetes | Signed container images (cosign) and Helm charts | Your internal registry: Harbor, Artifactory or Nexus |
| Java | Signed Maven artifacts (GPG) | Your internal Maven repository |
| Archives | Tarballs and zip releases | Your artifact store, checked against the SHA-256 file |
| .NET on Windows | Windows installers for patched .NET runtimes | Your artifact store or software distribution tool |
OSSeva does not patch operating systems. For RHEL 7, Windows Server or any other host OS, patches come from the OS vendor or an OS-level provider; the vendor comparison lists who covers what.
Verify a build with no outbound access
The commands are the ones on the security page. Fetch the signing key on a connected host, compare its fingerprint with the one published there, then carry the key file in with the builds.
gpg --recv-keys B7C4E831
gpg --fingerprint B7C4E831 # compare with /security
gpg --export B7C4E831 > osseva-signing-key.gpggpg --import osseva-signing-key.gpg
gpg --verify <artifact>.asc
shasum -a 256 <artifact> # compare with the SHA-256 file shipped with the releaseContainer images carry cosign signatures, and the command on the security page is the keyless form. Sigstore documents offline options for cosign, such as a saved bundle or a local key for an image saved to disk. Confirm which one applies to your images before you build a release process around it. The SBOM and the VEX statements travel with the build as files, so they need no network either.
Not a fit for
- Host operating system patching. OSSeva does not patch Linux distributions, kernels or Windows.
- A network where nothing from a third party may be installed. Patched builds still have to cross your boundary.
- A technology or version that is not on the supported versions list.
Sources, checked 26 October 2026: Sigstore, cosign: verifying signatures (keyless, bundles, local key), PCI SSC, PCI DSS v4.0.1 (Requirement 6.3.3).
Can you deliver to an air-gapped network?
Yes. Artifacts are delivered to your internal Artifactory or Nexus instance, and production needs no outbound internet access. How a build crosses into the enclave is set by your own transfer policy, so agree the route and the cadence when the scope is set.
Do you build for RHEL 7?
OSSeva does not patch operating systems, so RHEL 7 itself stays with Red Hat. OSSeva ships patched open source packages and images for the technologies on the supported versions list, and the version compatibility matrix that comes with Patch records the runtime and operating system each build runs on. Whether a given build runs on RHEL 7 is a coverage question: send the technology, the version and the platform through the form.
Does the 48-hour patch window apply inside an air gap?
The window is the time OSSeva takes to ship a patched build: Critical CVEs within 48 hours and High within 7 days. In a disconnected network the time from release to install also includes your transfer cycle, your testing and your change window, and those are yours to set.
Can we verify a build with no internet access?
GPG signatures and SHA-256 checksums check against files and a key you hold locally. Container images are signed with cosign, and the verification command on the security page is the keyless form. Sigstore documents offline options for cosign, such as a saved bundle or a local key for an image saved to disk. Confirm which one applies to your images before you rely on it.
Get a quote
Tell us the platform.
We will say what it receives.
Send the technology, the version and the host operating system. An engineer replies within 1 business day.