Running a Software Supply Chain Platform Inside an Air Gap

If your enclave has no internet, your software supply chain platform has to live inside it, and everything it knows about the outside world has to arrive on a schedule you control. The job is not "find a scanner that works offline". The job is to design what crosses the gap, in which direction, how often, how it is verified on arrival, and how you prove all of that to an assessor who will ask for it control by control.

This guide is written for the CISO or head of security at a sovereign or disconnected enterprise: a national utility, a defense supplier, a government-owned bank, a classified program office, or a critical infrastructure operator whose production network has no outbound route. It works with whatever tools you already run. Safeguard appears only in the last third.

Key takeaways

• An air-gapped supply chain program is a data logistics problem first. Decide the import channel, the cadence, the verification step and the export path before you pick tools.
• Vulnerability data goes stale inside the gap. Your risk acceptance has to say how stale is acceptable, and your evidence has to show the age of the data each scan used.
• NIST SP 800-53 Rev. 5 already describes the controls an assessor will test: boundary protection (SC-7), information flow (AC-4), vulnerability scanning with updated vulnerability lists (RA-5), flaw remediation (SI-2), component inventory (CM-8) and the supply chain family (SR).
• Verification of every inbound bundle is non negotiable. Signature checks happen in a staging zone before anything touches the production enclave.
• Closed, hosted AI models cannot run inside a true air gap. Either run models locally or run with no model at all.
• Safeguard capabilities covered, all GA: air-gapped and on-prem deployment with signed offline snapshot delivery, Zero AI mode, local and on-prem models, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the compliance and GRC suite, CSAF and VEX upload, the CLI and local runner, the desktop app, and autonomous remediation (GA, shipped switched off with every category set to Manual).

The situation

The trigger usually looks like one of these. A program moves into an enclave that has no outbound route, and the accreditation package is due before go live. A regulator or national authority tells a bank or utility that production systems holding sovereign data may not depend on a foreign cloud. A defense prime flows down a requirement that controlled technical data stays on a disconnected network. Or the board simply decides, after a supply chain incident somewhere else, that the build and production estate will be isolated.

Whichever it is, the CISO now owns a question nobody had to answer when the scanners were SaaS: how does the security tooling inside the enclave stay current, and how do we show that it is?

A bad week looks like this. A widely exploited flaw lands in a common open source library on Monday. Outside the gap, every team has a dashboard by Tuesday. Inside the gap, nobody knows which systems contain the library because the last inventory import was three weeks old, the vulnerability database was refreshed a month ago, and the person who carries media across the boundary is on leave. The assessor's next visit will ask when you knew, what you knew, and what you did about it. "We were waiting for the next transfer window" is an answer, but only if your written procedure says that window is acceptable and your records show you followed it.

The rest of this guide is about making that answer defensible. If you are still choosing between SaaS, private VPC, on-prem and air-gapped, start with picking a deployment model by data class, and for the narrower vendor screening questions see can a security scanner run offline or air-gapped.

What an air-gapped supply chain platform actually has to include

A disconnected program needs the same functions as a connected one. The difference is that each function must work with no outbound call.

Two things follow from that table. First, most functions work fine offline as long as the software runs entirely inside the perimeter. Second, the parts that degrade are all about outside knowledge: advisories, exploitation signals, fixed package versions and model weights. Those are exactly what your import channel has to carry.

The rules behind it

This is not legal or audit advice, and your authorizing official or national regulator has the final word on how controls apply to your system. What follows is how the published catalogs describe the controls an assessor is most likely to test in a disconnected supply chain program.

NIST SP 800-53 Rev. 5

NIST SP 800-53 Rev. 5 is the control catalog behind US federal baselines, including the FedRAMP baselines, and many sovereign programs abroad borrow from it. The controls that matter most here:

• SC-7 Boundary Protection. Monitor and control communications at the external boundary and key internal boundaries. In an air-gapped design, your transfer channel is the boundary. Document it.
• AC-4 Information Flow Enforcement. Enforce approved authorizations for controlling the flow of information within the system and between connected systems. Each import and export is a flow that needs an approval rule.
• RA-5 Vulnerability Monitoring and Scanning, and its enhancement RA-5(2) Update Vulnerabilities to Be Scanned, which asks you to update the vulnerabilities you scan for at one or more of these points: a frequency you define, before a new scan, or when new vulnerabilities are identified and reported. In an enclave, every one of those points depends on your import cadence.
• SI-2 Flaw Remediation. Identify, report and correct flaws, and install security relevant updates within an organization defined time. Your time period has to account for the transfer window.
• CM-8 System Component Inventory. An accurate, current inventory at the level of granularity you need for tracking and reporting. SBOMs are the practical way to meet this for software.
• SI-7 Software, Firmware, and Information Integrity. Integrity verification tools to detect unauthorized changes. This is where signature verification of imported bundles belongs.
• The SR family. SR-3 Supply Chain Controls and Processes, SR-4 Provenance, SR-5 Acquisition Strategies, Tools, and Methods, and SR-11 Component Authenticity all apply to the platform you bring inside, as well as to the software it scans.

NIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, is the companion guidance for running the SR controls as a program rather than a checklist. It is useful for the part of the job that is about the security tooling itself: the platform you install in the enclave is a supplier, its update bundles are supplied components, and the same provenance and authenticity expectations apply to it.

NIST SP 800-218, the SSDF

The Secure Software Development Framework (SP 800-218 v1.1) matters if the enclave also builds software. Practice PS.3 (archive and protect each software release) includes collecting provenance data for all components, and practice RV.1 (identify and confirm vulnerabilities on an ongoing basis) assumes you can keep learning about new vulnerabilities after release. In an air gap, "ongoing" means "on every import".

CISA SBOM minimum elements

On 29 July 2026 CISA published the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the minimum elements NTIA published in 2021. Whatever SBOM format you settle on (CycloneDX or SPDX), make sure the documents generated inside the enclave carry the elements the current guidance asks for, because those SBOMs are what an assessor or a downstream customer will see.

Exploitation signals: KEV and EPSS

CISA's Known Exploited Vulnerabilities catalog, which CISA describes as the authoritative source of vulnerabilities exploited in the wild, and FIRST's Exploit Prediction Scoring System are the two signals most programs use to decide what to fix first. EPSS gives every published CVE a probability of exploitation in the next 30 days, updated daily. KEV grows whenever CISA adds an entry. Both are only as useful as your last import, which is why the cadence decision below matters so much.

The five decisions that define the program

Every disconnected program makes the same five decisions, explicitly or by accident. Make them explicitly and write them down, because they become your control narrative.

Decision 1: the inbound channel

There are four common patterns.

The right choice depends on your classification rules, not on the tool. Pick the channel your accreditation allows, then make sure every tool you bring inside can be fed through it. If media is part of the route, the handling risks in USB risks and air-gapped transfer belong in your procedure.

Decision 2: the cadence

How often does outside knowledge enter? A practical way to set it is to work backwards from your remediation clock. If your policy says critical, actively exploited flaws are fixed within a short window, an import cadence longer than that window means you will routinely miss it without knowing.

A simple worked example, with invented round numbers you should replace with your own:

With those numbers a weekly import is too slow on the worst day, and a daily import leaves margin. The point of writing it out is that the cadence becomes a reasoned control parameter instead of a habit, and the assessor can follow the arithmetic.

Keep an emergency path too. Most programs allow an out of cycle import when a high profile, actively exploited flaw lands, with the same verification steps and a named approver.

Decision 3: verification on arrival

Nothing enters production until it has been verified in a staging zone. That means:

1. Check the bundle signature against a key you trust and pinned during installation, not one that came in the same bundle.
2. Check that the bundle is newer than the last one you accepted, so an attacker cannot replay an old, stale feed.
3. Record the bundle identifier, the signer, the time, and who approved the import.
4. Only then push the contents to the systems inside.

Signing keys need an owner and a rotation procedure, and rotation should be a two person, logged operation. If you cannot answer "who can change the key that every update is checked against", the assessor will.

Decision 4: the outbound path

Most programs forget the other direction. Some information has to leave: aggregate risk reports for the board, attestations or SBOMs a customer or regulator requires, or support diagnostics for a vendor. Decide what may leave, in what form, and who approves it. Many sovereign programs allow only summarised, reviewed reports outbound and never raw findings, source code or inventory detail. Write that rule into the AC-4 narrative.

Decision 5: the AI posture

If you want AI assistance for triage or fix drafting, the model has to run inside the perimeter. Hosted models from the large commercial providers run only on their providers' infrastructure, so using one always means sending requests outside. For a true air gap you have three honest options: run with no model at all, run an open weight or vendor supplied model on your own hardware, or keep AI use outside the enclave on non sensitive work only. Decide this in policy before an engineer decides it for you.

Step by step: standing up the program, with or without a platform

These steps work with any combination of tools. The order matters more than the products.

1. Draw the boundary. List every network zone involved: the outside staging zone, any DMZ, the transfer channel, the enclave, and any build networks inside it. Mark which direction each flow goes.
2. Inventory what the enclave runs. Generate SBOMs for every build and every container image inside the enclave. If you cannot generate them inside, you cannot keep CM-8 current.
3. Choose the inbound channel and cadence. Use the table and worked example above. Write the cadence into your vulnerability management standard.
4. Define the import bundle. At minimum: vulnerability advisories, KEV additions, EPSS scores, fixed package versions for your ecosystems, and tool updates. Note the source and date of each feed.
5. Build the verification step. Signature check, freshness check, approval record. Automate what you can; keep a human approver for the push into production.
6. Mirror the fixes. An advisory that names a fixed version is useless if the fixed package cannot be installed inside. Keep internal package mirrors and container registries fed through the same channel.
7. Write the gate rules. Decide what blocks a build or deployment, what only warns, and what only notifies. Decide how a team gets a time bound exception and who approves it.
8. Decide the outbound rules. What reports leave, in what form, approved by whom.
9. Set the AI posture. No model, a local model, or AI outside the enclave only.
10. Record data age. Every scan result should carry the date of the vulnerability data it used. This one field answers half of an assessor's RA-5 questions.
11. Run a drill. Pick a past high profile flaw and walk it through: import, verify, scan, find, fix, deploy, report. Time each step. Fix the slowest one.
12. Review quarterly. Cadence, key rotation, exception backlog, data age trends.

A one page checklist for the accreditation package

• Boundary diagram showing every transfer path and its direction.
• Named inbound channel, cadence, and emergency import procedure.
• Verification procedure with the pinned key, freshness check and approver.
• Key ownership and rotation procedure.
• Outbound rules and approver.
• SBOM generation scope and format.
• Gate rules: block, warn, notify, and the exception process.
• AI posture statement.
• Evidence samples: one import record, one scan with its data age, one exception with approval, one fix traced from finding to deployment.

How fresh does vulnerability data need to be?

There is no universal number. RA-5(2) lets you choose one or more update points: a frequency you define, before a new scan, or when new vulnerabilities are identified and reported. Inside an air gap, "before a new scan" only helps if a fresh import arrived first. In practice, assessors look for three things: a stated frequency, evidence that you met it, and a reason the frequency is consistent with your remediation timelines. The worked example above gives you the reason. The import log gives you the evidence.

A useful habit is to report data age on the same dashboard as finding counts. "Two critical findings, data 18 hours old" is a very different statement from "two critical findings, data 19 days old", and the board deserves to know which one they are reading.

What has to cross the gap, and in which direction

Inbound, in rough order of importance:

• Vulnerability advisories from the sources your program trusts, as deltas where possible.
• KEV additions and EPSS scores.
• Fixed package versions and patched container base images for the ecosystems you use.
• Policy template updates, if your tool ships them.
• Tool and platform updates.
• AI model updates, if you run local models.

Outbound, only what your rules allow:

• Summarised risk reports for leadership.
• SBOMs and vulnerability exploitability statements a customer or regulator requires.
• Support diagnostics, reviewed and stripped of sensitive detail.

Anything not on these lists should not cross.

How do you prove it to an assessor?

Assessors work from controls, so organise evidence by control.

The most common gap is the last row. Teams prove that the software they scan is tracked, but cannot show provenance for the scanner itself. Ask your vendor for the SBOM of the platform you are installing, and keep it with your package. For a fuller treatment of FedRAMP High evidence for supply chain controls, see FedRAMP High software supply chain evidence.

Upgrades, rollback and keeping the platform itself current

The platform inside the enclave is software with its own vulnerabilities. Plan its upgrade path the same way you plan application releases:

1. Verify the new release bundle in staging.
2. Install it alongside the running version, not over it.
3. Cut traffic over.
4. Keep the previous version available for one release cycle so you can roll back.

Treat platform upgrades as change controlled events with a ticket, an approver and a rollback plan.

Staffing and the operating rhythm

Disconnected programs fail on people more often than on technology. The import function needs a named owner and a deputy, the key ceremony needs two people who are never the same person, and someone has to watch the import log every day. A lean program might run on a weekly rhythm like this:

How Safeguard does this

Safeguard is a software supply chain security platform that runs in SaaS, private VPC, on-prem or fully air-gapped deployments. For a sovereign or disconnected enterprise, the relevant part is that the air-gapped deployment (GA) runs the full platform inside your perimeter with no outbound call, and receives outside knowledge as signed offline snapshot bundles on a cadence you choose. Safeguard's posture is designed for FedRAMP High, and it is SOC 2 Type II compliant. The steps below follow Safeguard's air-gapped deployment documentation.

1. Pick a delivery channel. Safeguard's docs list four: a one way diode, signed removable media carried by a courier, a scheduled sync through a separate DMZ with a short outbound window, and a pull replica where one site mirrors updates and feeds one or more air-gapped sites. These map directly to Decision 1 above.
2. Set the cadence. The docs say snapshot cadence is configurable from hourly down to quarterly. Use your worked example from Decision 2 to choose.
3. Install the Receiver and the control plane. In Safeguard's reference architecture, a Receiver sits in the DMZ or staging zone, verifies bundle signatures, and pushes deltas to the control plane inside the perimeter. The docs state that no component inside the perimeter ever calls outbound. The control plane runs on your Kubernetes cluster with Postgres and S3 compatible object storage, and an optional GPU pool for local models. A single node evaluation install exists for trials. The install runbook, including hardening baselines, Helm values and the day zero signing key ceremony, is provided to authorized tenants as a private repository, so its contents are not reproduced here.
4. Understand what each bundle carries. Per the docs, a bundle carries vulnerability feed deltas (including NVD, OSV, CISA KEV and daily EPSS), policy template updates, and platform binaries when releases ship. Each bundle is signed with Safeguard's air-gap signing key. This is the inbound list from the section above, delivered as one verified unit.
5. Generate SBOMs inside the enclave. SBOM generation and analysis in SPDX and CycloneDX (GA) runs locally, along with SCA and deep transitive dependency scanning (GA). Safeguard's continuous scanning docs say that in air-gapped environments it uses signed, incremental vulnerability database snapshots applied as deltas to the on-prem instance, so each scan uses the data of the most recent accepted bundle.
6. Prioritise with exploitation and reachability. Vulnerability management with EPSS and KEV (GA) uses the scores carried in the bundle. Reachability analysis and prioritisation (GA) runs inside the perimeter and helps separate findings in code your applications call from findings in code they do not.
7. Choose the AI posture per tenant. Safeguard supports four modes, configurable per tenant. Zero AI mode (GA) runs the entire platform deterministically with no LLM in the loop, and every scanner still works. Local and on-prem models (GA) run quantized builds of Safeguard's own models, Griffin, Eagle and Lion (some docs pages call Lion "Lino"), inside your environment, on your GPUs or, per the docs, as slower CPU only builds, a nightly batch mode, or a retrieval only mode. Bring your own model (GA) and full hosted AI exist too, but Safeguard's docs are explicit that closed models from the large commercial providers run only on their providers' infrastructure and are never installed on-prem or air-gapped. In a true air gap, that leaves Zero AI or local models.
8. Write policies and gates. Policies, gates and guardrails (GA) let you define rules in the web app, including in plain English. Gate actions are Block, Warn and Notify. A team that needs to ship despite a finding asks for an exception, and approval runs through the exception workflow, which leaves the time bound, approved record your SI-2 evidence needs.
9. Use the CLI and local runner inside the perimeter. The docs list the MCP server, API, CLI, desktop app and runner as available air-gapped. The Safeguard CLI and its local runner (GA) execute scan jobs on a machine, poll the platform for work, and upload only SBOMs and findings, never source code. The runner's traffic is outbound HTTPS that it opens; nothing connects to it, and on networks that forbid held connections you can run it with a fixed polling interval. Inside an enclave, the platform it polls is your own control plane. Safeguard's CLI installation page covers pinning a release with SAFEGUARD_VERSION and verifying the archive against the release checksums file. It also documents SAFEGUARD_SKIP_CHECKSUM=1 as an explicit opt out for an air-gapped mirror that does not carry that file. In a sovereign program, carry the checksums file across with the binary rather than opting out.
10. Bring in vendor statements. CSAF and VEX upload (GA) lets you load vulnerability exploitability statements from your suppliers, carried in through the same channel, so findings a supplier has analysed are marked accordingly.
11. Map evidence to your frameworks. The compliance and GRC suite (GA) includes a FedRAMP framework. Safeguard's FedRAMP framework page lists scan requirements that check each product's SBOM against component inventory (CM-8), integrity verification (SI-7), identifier correlation for vulnerability scanning (RA-5) and supply chain provenance (SR-4), alongside further controls you evidence with uploads, policies or attestations. In an air-gapped deployment that evidence stays inside the perimeter, and any outbound report is a deliberate export you approve under your AC-4 rule.
12. Upgrade with a rollback path. Safeguard's documented upgrade runbook is: validate the new snapshot bundle signatures, install blue and green through Helm in a new namespace, cut over through your ingress, and keep the prior namespace for one release cycle as rollback. That is the change control pattern from the upgrade section above.
13. Rotate keys under two person control. The docs say signing keys rotate on a configurable cadence (default annually), rotation is a two person, signed, logged operation, and old and new keys are both trusted for a grace period.
14. Use your own identity stack. Access to an air-gapped control plane uses your existing SSO over SAML or OIDC against your directory, SCIM sync inside the perimeter, and bastion hosts or PAM gated access for operators.

For how the runner behaves on restricted networks, see how the local runner and offline mode work; for the AI modes in more depth, see air-gapped and sovereign AI security.

Network posture beyond the air gap: Safeguard's architecture polls rather than holding open connections, encrypts request communication, applies zero trust throughout, isolates enterprise tenants, and does not train shared models on customer code, SBOMs or telemetry.

A mapping you can paste into the control narrative

What Safeguard does not do

• It does not choose or operate your transfer channel. The diode, the courier process, the DMZ and the media handling rules are yours. Safeguard's bundle arrives through whichever channel your accreditation allows.
• It does not make stale data fresh. Between bundles, the platform knows only what the last accepted bundle told it. Your cadence decision, not the tool, sets the worst case data age.
• It does not run closed hosted models inside an air gap. If your engineers expect a commercial hosted assistant inside the enclave, that expectation has to change. Zero AI and local models are the options.
• It does not grant or carry an authorization for you. Safeguard is designed for FedRAMP High and it is SOC 2 Type II compliant. Neither is an authorization for your system. Your authorizing official decides, based on your package.
• It does not decide what may leave. Export rules, report review and who approves an outbound transfer remain your policy and your people.
• It does not replace the install ceremony or your operators. The signing key ceremony, cluster hardening, backups and disaster recovery are run by your team using the runbook Safeguard provides to authorized tenants.
• It does not deploy fixes into production by itself by default. Autonomous remediation (GA) ships switched off, with every category set to Manual. Turning it on, and for which categories, is your decision.

Common mistakes

• Treating the air gap as the control. The gap reduces some risks and adds others, mainly stale data and human transfer steps. Assessors test the transfer process, not the absence of a cable.
• Verifying bundles inside production. Verification belongs in staging, before anything touches the enclave.
• Trusting a key that arrived in the same bundle. Pin the verification key at install, rotate it deliberately, and log every rotation.
• No emergency import path. When a widely exploited flaw lands, a weekly cadence with no out of cycle procedure guarantees a missed deadline.
• Mirroring advisories but not fixes. An advisory that names a fixed version is useless if the fixed package or base image cannot be installed inside.
• Hiding data age. Reporting finding counts without the age of the data behind them misleads the board.
• Letting AI policy be set by default. Decide no model, local model or outside only before anyone installs anything.
• Forgetting the platform's own provenance. The security platform is a supplier too. Keep its SBOM and release verification records in your package.
• One person owning the import. Leave, illness or turnover then stops your vulnerability program.

FAQ

Can a software supply chain platform run fully air-gapped?

Yes, if every component runs inside the perimeter and outside knowledge arrives as verified bundles. The parts that degrade are advisory data, exploitation signals, fixed package versions and model weights, which is why the import channel matters.

How often should vulnerability data be imported into an air-gapped network?

Work backwards from your remediation deadline for actively exploited criticals. Subtract the time to build, test and deploy a fix and the time to scan. What remains is the maximum data age you can accept, which sets the cadence.

Which NIST controls cover air-gapped vulnerability management?

Mainly SC-7, AC-4, RA-5 with RA-5(2), SI-2, SI-7, CM-8 and the SR family in NIST SP 800-53 Rev. 5, with NIST SP 800-161 Rev. 1 for running supply chain risk management as a program.

Can I use a hosted AI assistant inside an air gap?

No. Hosted models run only on their providers' infrastructure, so using one means sending data out. Run with no model or with a model installed on your own hardware.

Does Safeguard work with no AI at all?

Yes. Zero AI mode (GA) runs the entire platform deterministically with no LLM in the loop, and every scanner still works.

How do Safeguard updates get into an air-gapped network?

As signed snapshot bundles delivered by one way diode, removable media, a scheduled DMZ sync or a pull replica. A Receiver in the staging zone verifies signatures and pushes deltas to the control plane.

Is Safeguard FedRAMP authorized?

Safeguard's posture is designed for FedRAMP High. That is a design target, not an authorization. It is SOC 2 Type II compliant.

Does the Safeguard local runner send source code out?

No. The runner executes scan jobs on the machine and uploads only SBOMs and findings. Inside an enclave it talks to your own control plane.

How do I upgrade an air-gapped Safeguard deployment safely?

Validate the new bundle's signatures, install it in a new namespace beside the running one, cut over through your ingress, and keep the previous namespace for one release cycle as rollback.

What evidence should I keep for an assessor?

Boundary and transfer diagrams, import and verification logs, scan records with data age, finding to fix records, exception approvals, SBOMs per build, and the provenance records for the platform itself.

Inside an enclave, the hardest flaws are the ones in open source components where upstream has not shipped a fix yet, because waiting for upstream also means waiting for your next import window. The block below describes how Safeguard closes those gaps. Inside an enclave, whatever fixed components you adopt still have to cross the boundary through the verified import channel described above.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below were recorded against Safeguard's hosted service, not an air-gapped install, so treat them as a view of the interface and the workflow rather than of the transfer channel. The same CLI, runner and desktop app are listed in Safeguard's docs as available inside an air-gapped perimeter.

The first demo shows the Safeguard CLI scanning a project from a terminal and explaining what it finds. Since CLI v11.10.0 the CLI asks before any command that changes something. Inside an enclave, the same commands run against your own control plane.

Click through it at your own pace, or open it full screen.

The second demo shows the local runner, which executes scan jobs on your own machine and uploads only SBOMs and findings. For a disconnected program, this is the piece that lets build hosts inside the enclave do the scanning while source code stays where it is.

Click through it at your own pace, or open it full screen.

The third demo shows the Safeguard desktop app, which pairs the web app with a local panel for file access, CLI execution and agent tasks. Safeguard's air-gapped docs list the desktop app as available inside the perimeter, where it would pair with your own control plane rather than the hosted service.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Air-Gapped Deployment
• Safeguard docs: Deployment options
• Safeguard docs: AI Models
• Safeguard docs: Continuous Scanning
• Safeguard docs: Local Runner
• Safeguard docs: CLI installation
• Safeguard docs: Policies and gates
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: FedRAMP framework
• Safeguard docs: Desktop app
• NIST SP 800-53 Rev. 5 catalog (OSCAL)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST SP 800-218, Secure Software Development Framework v1.1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS frequently asked questions

Download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.