Vet a VS Code extension by checking who published it, what it can do, how often it is maintained and what it depends on, then allow only approved extensions on work machines. Extensions run with the same permissions as VS Code, so an extension can read your files, environment variables and credentials.
Why do extensions matter for security?
Developers keep source code, cloud credentials and tokens on the same machine where they install extensions. VS Code's documentation on extension runtime security states that extensions are not sandboxed from the editor's permissions. That puts an extension in the same trust bracket as any other program you install.
The editor adds some protection. Workspace Trust lets you open an unfamiliar folder in restricted mode, which limits what extensions do until you trust it. This helps with malicious repositories. It does not make a malicious extension safe once you grant trust.
What should you check before installing?
Publisher. Is the publisher verified? Does the publisher have other extensions and a real organisation behind them? Names that look almost like a popular extension deserve suspicion.
Purpose and permissions. Read what it does. A theme should not need network access. A formatter should not ask for your cloud credentials.
Activity. Look at release history, open issues and whether security reports get answers. An abandoned extension will not be patched.
Source. Is there a public repository, and does the published package match it? Closed source is not forbidden, but it removes your ability to inspect.
Dependencies. An extension is a Node project. Its dependency tree runs inside your editor. Scan it.
Install counts and reviews. Useful as a weak signal only, since both can be manipulated.
What does a review look like for a real team?
A constructed example. A team wants a markdown preview extension. The reviewer finds a verified publisher, a public repository, monthly releases and 40 dependencies. A scan of the dependency list shows one with a known advisory fixed in a later version, and the extension pins the old one. The reviewer opens an issue, installs a different extension with a smaller tree, and records the decision in the team's list.
That took thirty minutes and produced a reusable record.
How do teams control extensions at scale?
Individual vigilance does not scale. Options include:
- Maintaining an approved list and communicating it in onboarding.
- Using VS Code's enterprise settings to restrict which extensions can be installed, where your management tooling supports it.
- Running development in dev containers or cloud workspaces, so a bad extension reaches a disposable environment rather than a laptop.
- Keeping long-lived credentials off developer machines in favour of short-lived ones.
Safeguard has IDE extensions for VS Code, Open VSX and Cursor, and JetBrains, and its Gold registry and free in-browser scan at gold.safeguard.sh/scan can check dependency lists, which is useful when reviewing an extension's package manifest.
What if an extension turns out to be malicious?
Treat it as a compromised machine. Uninstall the extension, then rotate every credential that was present on that device: cloud keys, source host tokens, package registry tokens and any secrets in environment files. Review recent commits and publishes from that account for changes you did not make. Report the extension to the marketplace operator, and tell the team which extension and version was involved so others can check. Afterwards, add the incident to your extension policy so the lesson turns into a control, such as moving long-lived keys off laptops.
How to check or apply this
- Write a short extension policy: what is allowed, who approves, how to request.
- For each request, check publisher, permissions, activity, source and dependencies.
- Scan the extension's dependencies and record the result.
- Use Workspace Trust restricted mode for unknown repositories.
- Prefer disposable development environments for risky work.
- Review the approved list quarterly and remove unused entries.
- Rotate any credentials if a malicious extension was installed.
Quick check
Are VS Code extensions sandboxed?
No. Per VS Code's documentation they run with the same permissions as the editor, so treat installation like installing a program.
Does Workspace Trust protect me from bad extensions?
It limits what happens in untrusted folders. It does not make a malicious extension safe once you trust the workspace.
Sources
- Extension runtime security, Visual Studio Code
- Visual Studio Marketplace
- NIST SP 800-218, Secure Software Development Framework, NIST
Last reviewed: 18 October 2026.
