Deploying Vexta on an Air-Gapped or Offline Network

Can a vulnerability scanner actually run on a network with no internet access at all? Yes: Vexta is a single self-hosted binary with modest hardware requirements, and its core scanning, verification, and CVE matching do not depend on reaching anything outside the machine it runs on. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and that combination, one binary plus no network dependency for the actual testing, is what makes it practical to drop onto an internal, segmented, or fully air-gapped network for the duration of an engagement.

Why air-gapped work needs a different kind of tool

Plenty of serious testing happens on networks that are deliberately cut off, an internal engagement on a segmented VLAN, an OT or industrial environment, a client site with strict egress rules for the duration of a test. A scanner built around a cloud backend or a vendor API it needs to phone home to simply cannot do its job there. Getting a tool cleared to run at all can already take longer than the engagement itself if it needs outbound access nobody is willing to grant.

That rules out a whole category of SaaS-style scanning tools before the first request is ever sent. What is left has to run entirely on hardware the client already controls, with nothing assumed about what that network can reach.

There is also a quieter reason this matters even on networks that do have internet access. A tool that only needs the network when a hunter chooses to update it is a tool that adds one less always-on outbound connection to a scoped test, which is one less thing a client's own monitoring has to account for when reviewing what happened during the engagement.

What hardware does Vexta actually need?

Vexta's system requirements are modest by design: two or more CPU cores recommended, 512 MB of RAM as a minimum with 2 GB or more recommended for large scans, and roughly 100 MB of disk for the binary itself plus whatever space scan results and the local database end up using. It runs on Linux as the primary target platform, with macOS and Windows also supported.

That is a spec a laptop or a small VM meets without effort, which matters when the machine running the scan has to be provisioned inside a client's environment rather than brought in fully configured from outside. There is no separate database server, message queue, or backend service to stand up. The binary is the application, and standing up a second instance for a second engagement is just running the binary again somewhere else.

What network access does Vexta actually require?

Normal deployment assumes outbound HTTP and HTTPS access, mainly for license activation and check-in, and optionally for out-of-band vulnerability confirmation, which is how a scanner confirms a blind vulnerability like a server-side request forgery by watching for a callback the target's own server makes to an external listener. Neither of those is the scanning itself.

The scanning, verification, and CVE matching that make up the bulk of an engagement run against a bundled set of over 10,000 detection templates and a local mirror of vulnerability data, so they do not depend on a live connection to any external feed while a scan is running. That is what actually makes air-gapped operation realistic: the parts of Vexta that do the testing were built to not need the network in the first place, rather than being retrofitted with an offline mode after the fact.

What about screenshots and OS fingerprinting?

Two features have their own, separate requirements worth knowing about before deployment. Per-host screenshots on Linux need a small set of headless browser libraries installed on the host; without them, Vexta still scans normally, it just skips that one capability. Active OS fingerprinting, an opt-in check that sends ICMP probes to refine an OS guess beyond what passive banner analysis already provides, needs the `CAP_NET_RAW` capability on the binary. Without it, that specific check is skipped silently, and nothing else about the scan is affected.

Everything else, port scanning, the script engine, recon, vulnerability detection, verification, and reporting, runs with neither of those in place. Exact deployment options can vary by license; see plans on the pricing page for specifics.

Key takeaways

What deploying Vexta on a segmented or air-gapped network actually looks like: