Enterprises rolling out the Snyk CLI inside locked-down networks tend to hit the same two walls: an outbound-only corporate proxy that terminates and re-signs TLS traffic, and a security policy that treats build agents and developer workstations as isolated from the open internet. The Snyk CLI ships as a compiled Node.js executable — installed via npm install -g snyk or downloaded directly from downloads.snyk.io — and it depends on the same environment-variable-driven proxy conventions used by most command-line tools, rather than a bespoke enterprise connector. Snyk's own documentation is specific about what makes this work: HTTPS_PROXY, a trusted CA bundle for inspected traffic, and a fixed list of domains that must be allow-listed. It is equally specific about what doesn't work — true zero-egress air-gapping isn't supported for the parts of the CLI that depend on Snyk's hosted vulnerability data. This post walks through the documented mechanics of a Snyk CLI air-gapped proxy configuration, and where the real limits of "air-gapped" sit.
How does the Snyk CLI route traffic through a corporate proxy?
It reads standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables at process start, rather than exposing its own proxy configuration command. There is no snyk config set proxy=... equivalent — the CLI inherits whatever proxy settings are already exported in the shell or CI runner environment, consistent with how most Node.js tooling resolves outbound connections. A typical setup looks like export HTTPS_PROXY=http://proxyuser:proxypass@proxy.corp.internal:8080, with credentials embedded directly in the URL when the proxy requires basic authentication. NO_PROXY is used to carve out exceptions for internal hosts that shouldn't be routed through the proxy at all, which matters when a single CI runner talks to both api.snyk.io and an internal artifact repository in the same job. This applies uniformly across CLI subcommands — snyk test, snyk monitor, snyk container test, and snyk iac test all resolve the same proxy variables rather than each maintaining separate network logic.
What happens when the proxy performs TLS inspection?
The connection fails certificate validation unless the proxy's signing certificate is explicitly added to the CLI's trust store, because SSL-inspecting proxies re-sign HTTPS traffic with an internal corporate root CA that isn't in Node's default trusted CA list. Without intervention, this surfaces as an UNABLE_TO_VERIFY_LEAF_SIGNATURE or SELF_SIGNED_CERT_IN_CHAIN error the moment the CLI tries to reach api.snyk.io. Snyk's documented fix is to point the NODE_EXTRA_CA_CERTS environment variable at a PEM file containing the proxy's CA certificate, which extends — rather than replaces — Node's built-in trust chain. The CLI also exposes a global --insecure flag that disables certificate validation outright, but Snyk's own guidance treats this as a last resort for troubleshooting, not a production configuration, since it removes protection against man-in-the-middle traffic on the same connection carrying source code and dependency manifests to Snyk's servers.
Does the Snyk CLI support fully air-gapped, offline scanning?
No — not for the core scanning workflows most teams rely on, because open-source dependency scanning (snyk test) and container scanning both match findings against vulnerability data hosted on Snyk's cloud backend, and that lookup happens over a live API call rather than against a bundled local database. A workstation or build agent with genuinely zero outbound connectivity cannot complete a standard snyk test run. What Snyk documents under "air-gapped" enterprise deployment is more precisely a single, tightly controlled egress path — one proxy, one allow-listed set of domains — rather than the absence of egress entirely. Snyk Code, the static analysis product, has the same constraint: its semantic analysis engine is invoked through a separate endpoint (deeproxy.snyk.io) and is not something the CLI runs fully in-process without network access. Teams evaluating the CLI for classified or disconnected environments should treat "proxy-mediated" and "air-gapped" as distinct requirements — the CLI satisfies the former, not the latter.
Which domains have to be allow-listed for the CLI to function?
Snyk publishes a fixed set of hostnames that firewalls and proxy allow-lists need to permit, centered on api.snyk.io for scan requests and authentication, snyk.io for general product traffic, and downloads.snyk.io for CLI binary distribution and self-updates. Enterprises on a dedicated or regional tenant instead route through region-specific hosts such as api.eu.snyk.io or api.au.snyk.io, configured via the SNYK_API environment variable rather than the default US endpoint. A common partial-failure pattern comes from allow-listing only api.snyk.io: snyk test succeeds because it only needs the API host, while snyk code test times out because deeproxy.snyk.io was never added, and CLI self-update checks fail silently because downloads.snyk.io is blocked. For networks that can't tolerate on-the-fly downloads of per-ecosystem helper binaries at scan time, Snyk also documents a standalone, self-contained CLI binary that bundles its language analyzers up front, reducing the number of runtime calls the npm-installed wrapper would otherwise make to fetch tooling on demand.
How does Snyk Broker extend this model to on-prem systems?
Broker handles the opposite direction of the same problem: instead of the CLI reaching out to Snyk, it lets Snyk's cloud interact with source control and artifact systems — GitHub Enterprise Server, GitLab self-managed, Bitbucket Server, Artifactory, Nexus — that live inside a private network and were never meant to accept inbound connections from the internet. Broker runs as a lightweight relay inside the perimeter and opens only outbound connections to Snyk's cloud, so integrations work without punching an inbound hole in the firewall for GitHub Enterprise or an internal package registry. It's a distinct component from the CLI, aimed at repository and registry integrations rather than command-line scans, but it follows the same outbound-only posture: one controlled egress channel, no inbound listener, and no bundled offline vulnerability data on the private-network side.
What are the most common failure modes, and how are they diagnosed?
Most support cases trace back to one of three causes: an untrusted proxy certificate, proxy authentication that silently drops embedded credentials, or an incomplete domain allow-list that lets some subcommands succeed while others fail. Running the CLI with -d (debug output) or setting SNYK_LOG_LEVEL=debug surfaces the exact URL and TLS handshake step where a request fails, which is usually enough to distinguish a certificate trust problem (visible as a TLS handshake error) from a blocked-domain problem (visible as a connection timeout rather than a rejection). Because the CLI reuses OS-level proxy variables, mismatched casing or scope — https_proxy set in a user's shell profile but not exported to a CI job's environment — is a frequent, easy-to-miss cause of scans that work locally but fail in the pipeline. Enterprises rolling this out at scale generally converge on a short checklist: confirm the proxy URL and credentials, install the corporate CA via NODE_EXTRA_CA_CERTS, verify all four domains (api, snyk.io, downloads, deeproxy) are reachable through that proxy, and pin CLI versions rather than relying on runtime self-update in restricted environments.
How Safeguard Helps
None of this network plumbing is visible from a security or compliance dashboard by default — a scanner that's silently failing to reach deeproxy.snyk.io behind a misconfigured allow-list looks, from a pipeline's perspective, identical to one that ran cleanly and found nothing. Safeguard's approach to software supply chain security is built around closing exactly that gap: verifying that the security tooling teams believe is running in a given pipeline or environment is actually completing successfully, rather than trusting a green checkmark that may reflect a network timeout rather than a clean scan. For organizations operating scanners like the Snyk CLI inside proxied or restricted network segments, Safeguard helps validate that scan coverage, artifact provenance, and dependency data are complete and consistent across every environment — proxied, multi-region, or otherwise — so that a network misconfiguration in one corner of the build fleet doesn't quietly become a blind spot in the overall supply chain security posture.
