CI tells you after you have moved on
Scanning in a pipeline is not wrong, it is late. By the time it reports something you have written the code, opened the pull request and started on the next thing. The fix becomes an interruption: context rebuilt from scratch, queued behind current work, argued about in review, and sometimes shipped anyway with a ticket attached. The change itself is usually one line; everything around it is the expensive part. 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
Most editor security extensions cover one thing: dependencies, or secrets, or static analysis. Real incidents rarely respect that boundary.
Dependencies
Vulnerable packages across 40+ ecosystems, direct and transitive, anchored to the line that declares them, with the safe version to move to and the chain that introduced it.
Code
790 rules for command and SQL injection, unsafe deserialization, weak cryptography, path traversal, SSRF and authentication mistakes, evaluated as you type.
Secrets
1,090 credential patterns for cloud keys, tokens, private keys and connection strings, including ones committed earlier and still present in git history.
Containers
End-of-life base images, root users, remote ADD, unpinned installs, secrets baked into layers, privileged containers and mounted Docker sockets.
Infrastructure
Terraform, OpenTofu, Kubernetes and Helm checked for public storage, open security groups, IAM wildcards and unencrypted databases.
Licences
Copyleft contaminants such as AGPL and SSPL pulled in transitively, caught against your policy before a release rather than during a customer review.
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
Trae
Cloud workspaces are included, and worth being precise about: Gitpod, Coder, code-server and Firebase Studio present a browser interface but run the extension next to your files, 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.
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. The Vulnetix VDB aggregates 150+ upstream sources, enumerable through the public /v1/sources endpoint, across 4.8M advisory records and 173M affected-version rows, and every record type below can be attached to a finding.
Four KEV catalogues, not one
CISA, the EU/ENISA catalogue, VulnCheck and the Vulnetix KEV. CISA entries carry the binding remediation due date and required action; the others do not, and a finding says which catalogue it came from.
20 exploit sources, counted per source
ExploitDB, Metasploit, Nuclei, VulnCheck XDB, CrowdSec, GitHub proof-of-concepts, HackerOne, Bugcrowd, Intigriti, MISP, nmap NSE and Shadowserver among them, each with its own count and first and last observation dates.
End-of-life release data
A runtime, framework or base image that stopped receiving security fixes never gets an advisory saying so. Lifecycle records cover the product, its releases and their support dates, so an abandoned version is a finding rather than a silence.
Malware and typosquat records
Published packages confirmed malicious, with the evidence, the indicators and, where attribution exists, the actor. A malicious package rarely has a CVE at all, so this is a separate record type to advisories.
OpenSSF Scorecard and provenance
Per-check Scorecard results, maintainer records, SLSA provenance and dependency attestations, so "should I add this?" is answered by project health as well as by open advisories.
Reachability queries per advisory
Advisories carry tree-sitter queries naming the affected routines, which is how a finding can point at the function to look for rather than only the package at fault.
This is not a claim about anyone's roadmap, it is a claim about data. An extension backed by an advisory feed answers advisory questions well. "Is this runtime still supported?", "is this package malicious?" and "what do I deploy while I wait for the patch?" have no advisory to answer them: support ending produces no CVE, malicious packages rarely receive one, and detection content is normally a separate product. Vulnetix answers them from end-of-life release 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.
Severity that means something
A CVSS score says how bad a vulnerability would be if exploited. It says nothing about whether anyone is exploiting it. Every finding carries CISA KEV membership with its remediation deadline, EPSS probability, exploit maturity from ExploitDB, Metasploit, Nuclei and VulnCheck, and dated in-the-wild sightings. Ten weaponised issues you can work through beats three hundred theoretical ones you cannot.
It tells you what to change
Safe version selection within a major-version budget you set, package-manager overrides for transitive dependencies you cannot upgrade directly, and documented workarounds when no fix exists yet. Fixes apply as editor edits, so undo works and unsaved buffers are respected. CycloneDX and SPDX SBOMs, OpenVEX exploitability statements and crypto and AI inventories generate from the same data, which turns the security questionnaire you answer by hand every quarter into a file.
Frequently asked
Does my source code leave my machine?
No. Scanning is local: 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 sends package coordinates such as pkg:npm/lodash@4.17.20, never code, file paths or repository names. Disable dependency lookups and code, secret, container and infrastructure scanning still work fully offline.
Does it work in Cursor, Windsurf and VSCodium?
Yes. Only Microsoft’s own builds of VS Code may use the Visual Studio Marketplace, so Vulnetix is published to Open VSX as well. That covers Cursor, Windsurf, VSCodium, code-server, Gitpod, Coder, Eclipse Theia, OpenVSCode Server, Firebase Studio, Kiro, Positron and Trae.
Does it work in browser-based editors?
Cloud workspaces such as Gitpod, Coder, code-server and Firebase Studio are fully supported, because the extension runs next to your files rather than in the browser sandbox. vscode.dev and github.dev have no filesystem and no ability to start a process, so scanning is unavailable there; threat intelligence, organisation policy and previously published findings still work.
Will it slow my editor down?
A language server holds the compiled rule set in memory, so a check as you type costs around 10 milliseconds. The expensive rules, secret detection, are deferred to save rather than throttled everywhere, which is measured rather than assumed.
Is it the same as what runs in CI?
Yes, deliberately. The extension drives the same binary as your pipeline, against the same rules and the same organisation policy, so what CI blocks on is what your editor already showed you. Where an organisation policy and a local setting disagree, the policy wins.
Do I need an account?
No. Scanning works signed out on the community tier. Signing in adds private threat intelligence, organisation policy, reachability analysis and the ability to publish results to your organisation.