According to Microsoft's documentation, the Visual Studio Marketplace scans each new extension and each update for malware, runs it in a sandbox to watch its behavior, signs the package, checks for leaked secrets and blocks name impersonation. These checks reduce risk but do not review every line of code.
The checks, in plain words
The VS Code documentation lists these protections. I have grouped them by what they protect against.
| Check | What it targets | What it does not tell you |
|---|---|---|
| Malware scan with several antivirus engines, on every new extension and update | Known bad code in the package | Novel or well hidden behavior |
| Dynamic detection in a sandboxed environment | Suspicious runtime behavior | Behavior that appears only later or only on certain machines |
| Package signing by the Marketplace | The package you install is the one published | That the publisher is trustworthy |
| Name protection for official publishers and popular extensions | Lookalike impersonation | Every possible typosquat |
| Monitoring of downloads and usage patterns | Unusual behavior around an extension | Quiet, low volume abuse |
| Secret scanning of new packages, blocking publish when keys are found | Publisher mistakes that leak credentials | Secrets in other places |
| Removal of reported malicious extensions | Known incidents after the fact | Harm done before the report |
The documentation also says an extension is not published for public use until the malware scan is all clear, and that the team gives an initial response to suspicious extension reports within one business day.
Reading the table as a buyer
Two points matter for a security review.
First, almost everything above is a gate at publication time. Once the extension is on a machine, it runs with the editor's permissions. The post what can a VS Code extension access on your machine covers that side.
Second, signing proves integrity, not intent. A signed package from a publisher whose account was taken over is still signed. That is why the verified publisher check, which requires domain ownership and six months of good standing, is a signal and not a guarantee.
What a team should add on top
- Allowlist. Decide which extensions are approved and block the rest with the organization controls VS Code provides.
- Version awareness. Know that auto update will install new versions without a review. Decide whether that is acceptable for extensions with broad access.
- Inventory. Keep a list of installed extensions per team. Our guide to auditing installed editor extensions across a team shows one approach.
- Reporting path. Tell developers where to report a suspicious extension, and what to do first: stop using it and tell security.
Why layered checks still miss things
Automated scanning is good at the known and the obvious. Attackers adapt to it. Reviews in your own organization catch a different class of problem, such as an extension that does something legitimate but unwanted, like sending code snippets to an external service. Neither layer replaces the other.
If you are comparing marketplaces, ask the same question of each: what is checked at publish, what is checked after, who can be removed, and how fast. Then ask what you control locally.
Safeguard's IDE extensions for VS Code, JetBrains and Open VSX bring dependency and vulnerability findings into the editor, which helps with the code you write, though it is a separate matter from vetting the extensions you install.
Quick check
Who signs a Marketplace extension?
The Marketplace signs all extensions when they are published, and VS Code checks the signature when you install. This verifies the package, not the publisher's intent.
If an extension passed scanning, can I skip my own review?
No. Scanning runs at publication and on updates, but you still decide what runs with your developers' permissions. Keep an allowlist and review high access extensions.
Sources
Last reviewed: 19 October 2026.
