"Should I trust this VS Code extension?" 8 Questions Teams Are Actually Asking

The Problem: Hidden Threats in VS Code Extensions

Recently, Socket researchers found 72 malicious Open VSX extensions impersonating popular tools like ESLint and Prettier. The GlassWorm campaign exploited a common oversight: extension dependencies. An extension may seem safe at first but can later update to include malicious payloads through its dependency tree.

This discovery has sparked a wave of concern. Teams that never worried about editor extensions are now asking how to audit them. Here are the questions that keep coming up, with actionable answers.

Q1: "Do Extensions Have Dependencies? How Does That Work?"

Yes, extensions can have dependencies, which is what GlassWorm exploited.

When you install a VS Code extension, it may declare dependencies on other extensions in its manifest. It's similar to npm packages or Python imports for your editor. The extension manager automatically installs these dependencies to ensure the main extension functions correctly.

The attack pattern involves publishing a clean extension that mimics a popular tool. Once it gains installs, an update adds a dependency on a malicious extension. Users who trust the initial extension automatically pull in the malicious payload.

Your action: Check your extension manifests. Look for the extensionDependencies field in package.json. Investigate any unexpected dependencies.

Q2: "How Can I Identify a Malicious Extension?"

Look beyond descriptions and screenshots. Attackers are skilled at copying these.

Publisher verification: On the VS Code Marketplace, verified publishers have a blue checkmark. Open VSX lacks formal verification, making it a target. If you use Open VSX, you need to accept or mitigate this risk.

Install counts and age: Malicious extensions often have low install counts and are recently published. A "Prettier" extension with 200 installs published last month should be suspicious compared to the real Prettier with millions of installs and years of history.

Repository links: Legitimate extensions link to public GitHub repos. Check if the repo exists, has a real commit history, and matches the claimed functionality. GlassWorm extensions often lacked repo links or linked to empty repositories.

Update frequency: An extension that suddenly updates after months of inactivity, especially if it adds new dependencies, deserves scrutiny.

Q3: "Can We Block Open VSX and Use Only the Official Marketplace?"

Yes, and in some compliance contexts, you should.

If you're subject to PCI DSS v4.0.1 Requirement 6.3.2, you need defined approval processes for development tooling changes. Restricting to a single, curated marketplace simplifies enforcement.

However, Open VSX exists for organizations needing open-source alternatives to Microsoft's marketplace, especially in restricted environments. If you're using VS Codium or other open-source forks, Open VSX might be your only option.

Middle ground: Maintain an internal allowlist of approved extensions. Use group policy or configuration management to enforce it.

Q4: "How Can We Inventory Extensions for 200 Developers?"

VS Code stores extensions in a user profile directory, complicating centralized inventory. Here's what works:

For managed workstations: Query the extensions directory programmatically. On Windows, it's %USERPROFILE%\.vscode\extensions. On macOS/Linux, it's ~/.vscode/extensions. Each extension has an identifiable folder name and package.json.

Using the CLI: The code --list-extensions command outputs installed extensions. Run this through your configuration management tool (Ansible, Chef, etc.) and aggregate the results.

For unmanaged devices: Rely on self-reporting or endpoint detection tools that can scan file systems. This is where your SOC 2 Type II controls around asset management become relevant.

Build this inventory before creating your allowlist. You'll find extensions you didn't know existed, including ones that should concern you.

Q5: "Do We Need to Remove and Reinstall All Existing Extensions?"

Not all, but you need to audit dependency chains.

For each installed extension, check its package.json for extensionDependencies. If it lists dependencies:

1. Verify each dependency is legitimate.
2. Check when the dependency was added (compare against the extension's version history in its repo).
3. Look for dependencies that don't match the extension's stated purpose.

If an extension added new dependencies in recent updates, that's a red flag. For critical systems or compliance-sensitive environments, consider a clean slate: uninstall all extensions, build your allowlist, and reinstall only approved extensions.

Q6: "Are Our CI/CD Extensions at Risk?"

Yes, and this impacts more than individual workstations.

If your pipeline uses containerized build environments that install VS Code extensions, you're pulling from the marketplace on every build. A compromised extension could inject malicious code into your build artifacts.

Mitigations:

Pin extension versions explicitly: Specify exact versions in your container definitions or install scripts.

Use a local mirror: Download approved extensions and serve them from an internal repository.

Consider alternatives: Many tools (ESLint, Prettier, Black) work well as CLI tools without requiring VS Code extensions. In CI/CD, the CLI approach is often cleaner and more auditable.

This aligns with NIST 800-53 Rev 5 control SA-10.

Q7: "What Should Our Extension Approval Process Look Like?"

Keep it simple enough for developers to follow, but strict enough to provide protection.

Minimum process:

1. Developer requests extension by submitting name, publisher, and business justification.
2. Security reviews publisher verification, install count, repository, and dependency chain.
3. If approved, extension goes on the allowlist and developer can install it.
4. Monthly review of allowlist to remove unused extensions and check for new security issues.

For higher-risk environments, add: automated scanning of extension code, review of network permissions in the manifest, and time-boxed approvals that require renewal.

Q8: "Is This Only an Open VSX Problem?"

This technique can work anywhere dependencies exist. Open VSX was targeted due to its lack of verification and monitoring infrastructure. However, the official VS Code Marketplace isn't immune. Your security model should assume any extension marketplace can be compromised.

Defense in depth: allowlist, version pinning, dependency review, and periodic re-evaluation.

Next Steps

For more details, Socket's research report on GlassWorm provides technical indicators and extension names. The Open VSX GitHub repository tracks security issues and removal actions.

For policy frameworks, consider NIST 800-53 SA-10 and SR-3. If building an extension approval process from scratch, OWASP ASVS v4.0.3 Section 14 offers relevant controls.

Remember, your development environment is part of your attack surface. Treat it that way.