You already fixed it. You just did not know yet.

The cost of a vulnerability is mostly the delay. Scanning in CI is not wrong, it is late. By the time a pipeline reports something, you have written the code, opened the pull request and started on the next thing. Now the fix is an interruption: rebuild the context, work out whether the finding is real, decide whether it can wait, argue about it in review. The same finding on the line, while you are still looking at it, is a thirty-second decision.

Six scanners, because attackers do not specialise

An extension is a delivery mechanism. The data is the product.

Two extensions can look identical, draw the same squiggle and disagree completely about what you should do next, because the difference is not the editor integration. It is what the underline can be joined to. Every finding can carry four KEV catalogues (CISA with its binding due date, the EU/ENISA catalogue, VulnCheck and the Vulnetix KEV), exploit records counted across 20 sources with first and last observation dates, end-of-life release data for a runtime nobody will patch again, malware and typosquat records for packages that never receive a CVE, OpenSSF Scorecard and provenance for project health, and per-advisory tree-sitter queries naming the affected routines. The VDB aggregates 150+ upstream sources, enumerable through the public /v1/sources endpoint, across 4.8M advisory records and 173M affected-version rows.

Three questions have no advisory to answer them at all: "is this version still supported?", "is this package malicious?" and "what do I watch for until I can patch?". Support ending produces no CVE, malicious packages rarely receive one, and detection content is normally a separate product. Those are answered from lifecycle records, malware records, and Snort, Suricata, YARA and Nuclei content returned whole. The same records answer the same questions in the CLI, in CI, in the console and through the MCP server.

Your code does not leave your machine

Not a policy, an architecture. The rule set is compiled into a binary on your disk and evaluated in a process on your machine. Matching a dependency to known advisories does require asking something, because there is no local copy of the vulnerability database, and what is sent is package coordinates such as pkg:npm/lodash@4.17.20. Never your code, your file paths or your repository name. Turn dependency lookups off entirely and code, secret, container and infrastructure scanning still work in full, offline. The panels inside the extension run under a content security policy that forbids network requests outright, so a compromised dependency inside one has no route out.

Thirteen editors, because forks are where developers went

Only Microsoft's own builds of VS Code may use the Visual Studio Marketplace. Every fork uses Open VSX instead, and most security extensions never publish there, which quietly excludes a large share of working developers. Vulnetix publishes to both: VS Code, Cursor, Windsurf, VSCodium, code-server, Gitpod, Coder, Eclipse Theia, OpenVSCode Server, Firebase Studio, Kiro, Positron and Trae. Cloud workspaces run the extension next to your files rather than in the browser sandbox, so scanning there is exactly as capable as on a laptop. The only reduced case is vscode.dev and github.dev, which have no filesystem at all.

The same engine your pipeline runs

The failure mode we most wanted to avoid: your editor says clean, CI says blocked, and you learn to ignore your editor. The extension drives the same binary that runs in your pipeline, against the same rules and the same organisation policy. Where a policy and a local setting disagree, the policy wins, including over a flag someone passed deliberately. A policy a developer can quietly opt out of is not a policy.

Read the documentation →