Architecture

Three pieces: the extension, a language server, and a vulnerability database.

The pieces

The extension is the interface: views, panels, commands, diagnostics. It contains no scanning logic at all.

The language server does the work. It is a mode of the Vulnetix CLI, the same binary that runs in your CI, started as vulnetix lsp and spoken to over the Language Server Protocol on standard input and output.

The vulnerability database answers questions the local engine cannot: which advisories affect a package version, what exploit activity exists, what the remediation options are.

┌──────────────────┐        LSP over stdio        ┌──────────────────┐
│  Your editor     │ ←──────────────────────────→ │  vulnetix lsp    │
│  (the extension) │                              │  (the CLI)       │
└──────────────────┘                              └────────┬─────────┘
         │                                                 │
         │ HTTPS: intel, org policy, publishing            │ reads your files
         ↓                                                 ↓
   api.vdb.vulnetix.com                            your working tree

Why a language server

Three reasons, in order of importance.

State. The rule engine compiles roughly 1,900 policy modules on startup. A process started fresh for each check would pay that every time. A long-running server pays it once and then answers in milliseconds.

Incrementality. The server knows which documents are open and which changed, so it re-evaluates the edited file rather than re-walking the repository.

Editor independence. LSP is a standard. The same server can serve Neovim, Zed, JetBrains and Emacs without a line of editor-specific code, which is why this is a server and not a library compiled into a TypeScript extension.

Why the same binary as CI

Because two engines produce two answers, and the moment your editor and your pipeline disagree, people stop believing the editor.

One binary, one rule set, one vulnerability database. What CI blocks on is what your editor already showed you.

Where it runs

The extension declares itself a workspace extension, so in a remote session the extension and the server both run where the files are: the SSH host, the WSL distribution, the container, the cloud workspace. Never on your laptop against a remote filesystem, which would be scanning an illusion.

The exception is a browser-only editor, where there is no process to run. See browser-based editors.

Failure behaviour

If the server crashes it is restarted, up to three times in three minutes, after which you get an actionable notification instead of a restart loop. Its log is in the Vulnetix output channel.

If the vulnerability database is unreachable, local scanning continues in full and dependency findings degrade to what is cached. The extension tells you the difference between “clean” and “could not check”, because those must never look the same.