Managing the engine binary

Proxies, air-gapped mirrors, pinned versions, and shared installs.

The extension needs the Vulnetix CLI. By default it manages one for you. This page is for when you need it to do something else.

How it decides which binary to use

1. vulnetix.cli.path, if set
2. vulnetix on your PATH
3. A copy it downloaded previously
4. Otherwise, offer to download one

A binary you configured is used as-is: it is never auto-updated, and if it fails the compatibility check you get an error naming the reason rather than a silent fallback to a different one. You asked for that binary.

Verification is not optional

Every download is checked against the checksums.txt published with the release, before the binary is executed. A mismatch discards the file and reports an error.

There is no flag to skip this. If something between you and GitHub rewrites traffic, the answer is a binary your organisation has vetted, via vulnetix.cli.path, or a mirror you control. A disabled integrity check is not a smaller problem than a failed download.

Behind a proxy

The CLI honours HTTP_PROXY, HTTPS_PROXY and NO_PROXY from the environment the editor inherits. On macOS and Linux that means launching your editor from a shell where they are set; launching from the Dock or an application menu will not pick up your shell profile.

If your proxy performs TLS interception, checksum verification will still pass, because the checksum comes from the same proxied connection as the asset. What it cannot protect against is a proxy serving a modified binary and a matching modified checksum, which is why an internally vetted binary is the better answer in that environment.

Air-gapped, or an internal mirror

Mirror the release assets and point the extension at them. The mirror must serve the same layout, including checksums.txt:

<base>/<tag>/vulnetix-linux-amd64
<base>/<tag>/checksums.txt

{ "vulnetix.cli.downloadBaseUrl": "https://artifacts.internal/vulnetix" }

Or install the binary through your usual configuration management and set the path:

{ "vulnetix.cli.path": "/usr/local/bin/vulnetix" }

Note that dependency findings additionally need to reach the vulnerability database. Fully air-gapped, code, secret, container and infrastructure scanning work in full because they are local rule evaluation; dependency findings will not be available. Talk to us about on-premises options.

Pinning a version

{
  "vulnetix.cli.path": "/opt/vulnetix/3.90.1/vulnetix",
  "vulnetix.cli.autoUpdate": "never"
}

The extension and the engine share a protocol version that must match, so a pinned engine constrains which extension versions will work with it. The extension tells you plainly when they diverge rather than behaving oddly.

Shared machines

On a multi-user host, each user’s extension host has its own storage and would otherwise download its own copy. Install once and point everyone at it through machine-scope settings:

{ "vulnetix.cli.path": "/usr/local/bin/vulnetix" }

Why these settings are machine-scoped

vulnetix.cli.path, vulnetix.cli.downloadBaseUrl and vulnetix.sast.rules all determine which code gets executed. Machine scope means a workspace cannot set them, so cloning a repository can never redirect the extension at a binary or a rule pack of the repository’s choosing.

That is a deliberate boundary. It is also why the extension requires a trusted workspace at all.

Updates

Checked at most once a day. vulnetix.cli.autoUpdate controls what happens:

• prompt (default): a notification with Update, Later, and Never for this version
• auto: downloaded in the background, applied on the next restart, never mid-session
• never: pinned

The extension never runs vulnetix update. The CLI’s self-updater would replace the binary underneath a running server; the extension owns that lifecycle instead.