Every dependency scanner is, underneath, a program that looks things up. Take away the network and you find out how much of it was a lookup.
For teams in defence, sovereign cloud, medical devices, industrial control, or any environment where the build network has no route to the internet, this determines whether a tool works at all. This post is what actually breaks, what the honest operating model looks like, and the questions to ask a vendor before you find out in a proof of concept. Written for whoever has to make security tooling work behind an air gap.
What a scanner needs the network for
Six things, and they fail differently.
The vulnerability database. The largest and most obvious. Advisories from NVD, GitHub, OSV, distribution trackers, and vendor feeds. Without updates, findings decay: the tool reports what was known on the day the data was frozen, and every advisory published since is a false negative.
Package metadata. Resolving a dependency tree often means asking a registry what a version range means, what the transitive dependencies are, and sometimes fetching the package to inspect it. A lockfile removes much of this need, which is one reason lockfiles matter more in an air-gapped build than anywhere else.
Reachability and analysis data. Some analyses need the dependency's own code, not just its name and version, which means the package has to be present locally rather than resolved on demand.
Licence and provenance lookups. Identifiers, signatures, attestations, transparency log verification. Sigstore verification in particular expects to reach a log, and an offline verification path is a distinct feature rather than a default.
Telemetry and licensing checks. The one nobody mentions in the datasheet. Plenty of commercial tools phone home for entitlement, and will refuse to run or degrade silently when they cannot. This is worth testing explicitly, because it is the failure that is least likely to be documented.
Any model inference. If the product uses a hosted model for triage, explanation, or fix generation, that path is gone entirely unless the model can run locally.
The four operating models, honestly
Fully offline with scheduled data import. A signed data bundle is produced on a connected system, transferred through whatever your transfer process is, and imported. Everything runs locally against imported data.
This is the only model that is genuinely air-gapped. The two questions that decide whether it works: is the bundle signed and verifiable offline, and how large is it. A multi-gigabyte daily bundle is a different operational proposition from a hundred megabyte weekly one, particularly if your transfer path involves physical media and a human.
A broker on the boundary. A proxy in a controlled zone that fetches data and serves it inward. More convenient, and it is a connection, so whether it satisfies your requirement is a question for whoever wrote the requirement rather than for the vendor.
Scan outside, import results. Code leaves the environment, findings come back. For most organisations with an air gap this is the thing the air gap exists to prevent, so it is usually not available. Worth naming to rule it out early.
Local execution, encrypted results out. The scan runs inside your environment on your hardware, and only findings leave, encrypted. A useful middle position when the constraint is data residency and source confidentiality rather than a strict absence of connectivity. It does not satisfy a true air gap, and it does satisfy a surprising number of requirements that get described as one.
Be precise about which constraint you actually have. "Air-gapped" is used for all four, and the difference decides which products are even candidates.
Questions to ask before a proof of concept
Ask these in writing. The answers vary far more between vendors than the marketing does.
- Can the product run with no outbound connectivity at all, including licensing? Ask for the behaviour when a licence check fails, specifically.
- What is the update bundle: size, cadence, signed by what, verifiable how, and can verification be done offline?
- What happens when data is stale? Does it warn, and does it tell a report consumer the data age? A finding count computed from six month old advisories, presented without that context, is worse than no report.
- Which features degrade offline, and is the degradation visible in the output? A tool that silently skips an analysis it cannot perform is producing a clean result that means nothing.
- If there is AI in the product, can it run entirely locally, and what hardware does that need?
- Can the installer run offline, including every base image and dependency it pulls? This is where most first attempts fail, before scanning is even reached.
That last one deserves emphasis. An installer that pulls a base image at runtime fails on a machine with no route out, and it fails in a way that looks like a broken product rather than a missing network.
Operating it once it works
Track data age as a metric, and alert on it. In a connected environment staleness fixes itself. Here it is a manual process, and manual processes slip. The date of your last successful import belongs on a dashboard next to your finding counts.
Put the age in every report. Any artifact leaving the environment, for an auditor or a customer, should carry the advisory data date. It is the difference between an honest report and a misleading one, and auditors respond well to seeing it.
Rehearse the import. Whatever your transfer process is, run it on a schedule rather than when an urgent advisory lands. The first time you do it under pressure you will discover which step needs an approval nobody is available to give.
Keep an offline copy of the packages, not only their names. If your analysis needs the dependency's code, a lockfile that names versions is insufficient without a local mirror holding them.
The concession
An air-gapped deployment is worse at finding vulnerabilities than a connected one, and no vendor architecture changes that. Your data is always older. There is a real window, between an advisory being published and your next import, where you are exposed and your tooling shows green.
Pretending otherwise helps nobody. The right response is to make the window explicit: know its length, state it in your reports, and shorten it where the risk justifies the operational cost. A team that knows its data is nine days old makes better decisions than one that assumes it is current.
The implication
The useful question for evaluating any tool in this setting is not whether it supports air-gapped deployment, because nearly every vendor will say yes.
It is what the product does when a lookup fails. If it errors, you can manage it. If it silently returns a smaller answer, you have a tool that reports success in exactly the situation it was bought to handle.
