The VS Code Marketplace is the extension catalogue for Visual Studio Code, where users browse, install and update extensions and themes. It also distributes extension packages and metadata, so the editor loads third-party code into the development environment under the permissions granted to that extension.
What the VS Code Marketplace is used for
The VS Code Marketplace is where developers discover and install third-party extensions, themes and related packages into Visual Studio Code. Because those add-ons run inside the editor’s trust boundary, the marketplace is not just a download catalogue, it is part of the software supply chain for the development workstation.
That matters because the extension ecosystem can change what code executes locally, what data an add-on can read, and what tools or services it can reach. A marketplace entry is therefore an access decision as much as a convenience feature, especially when developers install extensions without reviewing the publisher, permissions, or update history.
How marketplace distribution changes the security model
A normal application store mainly delivers software. A developer tooling marketplace also delivers execution context. Once an extension is installed, it may gain access to open files, workspace contents, terminals, local settings, network requests, or authentication material that the editor and surrounding tools expose.
That is why extension packaging and metadata are security-relevant. The metadata influences user trust, while the package delivers the actual code. If either is misleading, organisations can end up treating unvetted code as a routine productivity add-on. Developer Workstation and IDE Security Guide covers the control points that matter most when extensions, workspace trust and local secrets intersect.
Why the marketplace is attractive to attackers
Extension marketplaces are attractive because they concentrate developer trust, repeated updates, and high-value credentials in one place. A malicious or compromised extension can piggyback on normal update workflows, making abuse look like ordinary maintenance. That creates a strong path for token theft, code execution, supply-chain compromise, or persistence on developer machines.
Attackers also benefit from the fact that developers often install extensions to solve immediate work problems, which reduces scrutiny. When a malicious package is accepted into the ecosystem, it can spread through teams before defenders notice the behaviour shift. GlassWorm campaign 2025 is a concrete example of how vs code extension abuse can move from initial compromise to credential theft and propagation. GlassWorm VS Code Extension Worm Guide shows the detection and allowlisting lessons that follow from that pattern.
What organisations should govern around it
The marketplace should be treated as a governed software source, not an informal convenience layer. Organisations need to know which extensions are approved, which publishers are trusted, and which installation paths are allowed on managed developer machines. That is especially important when extensions can touch source code, CI secrets, cloud credentials, or internal APIs.
Policy also needs to account for code review and update review. A benign-looking extension can later gain new behaviour, so approval is not a one-time event. Marketplace monitoring, extension inventory, and remove-or-disable processes are part of keeping the development environment aligned with least privilege and change control. Developer Workstation and IDE Security Guide is the most directly relevant internal reference for those governance decisions.
Risk and Threat Considerations
The marketplace risk is not just malicious code, it is trust transfer at scale. If an extension is compromised, impersonated, or accepted too casually, the blast radius can include developer tokens, source repositories, cloud access, and the workstation itself.
Failure mechanism: A malicious package, poisoned update, or overly permissive extension uses the editor’s trust relationship to read secrets, execute code, or persist through normal update channels.
Impact: The result can be credential theft, source-code exposure, supply-chain compromise, lateral movement through developer tooling, or repeated compromise of multiple workstations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Marketplace-installed extensions affect account and secret exposure on developer endpoints. |
| Recommendation — Restrict and review extension installation on managed developer endpoints. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Extensions add executable functionality to the IDE and should be limited to what is necessary. |
| SA-11 — Developer Testing and Evaluation | Extensions and updates require evaluation before they are trusted in the development environment. | |
| SI-3 — Malicious Code Protection | Marketplace packages can deliver malicious code through normal extension updates. | |
| Recommendation — Limit approved extensions to the minimum needed for developer work. Evaluate third-party extensions before allowing them into the developer toolchain. Scan and block suspicious extension packages before they execute. | ||
| MITRE ATT&CK | T1176 — Browser Session Hijacking | Extension abuse can target developer sessions and adjacent credentials in the tooling environment. |
| Recommendation — Map suspicious extension behaviour to attacker techniques and hunt for credential abuse. | ||
Practitioner Guidance
Why practitioners should care: Treat marketplace hygiene as part of endpoint and supply-chain security, not as a developer preference issue. The core judgement is whether an extension’s function justifies the access it receives inside the IDE and on the host.
Common misunderstanding: A popular extension is not automatically safe, and a familiar publisher is not a guarantee that the current package is benign. Trust should follow the exact package, publisher, update path and permissions model, not the brand name alone.
Practitioner takeaway: The safest marketplace posture is one where installation is intentional, extension scope is limited, and update drift is continuously monitored.
Related resources from NHI Mgmt Group
- What breaks when a malicious VS Code extension can inherit a GitHub session silently?
- Why do VS Code extension attacks create more risk than simple token theft?
- What should security teams do when a VS Code extension starts spawning script hosts?
- How should security teams handle VS Code extensions that change after installation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org