Your developers installed a linter yesterday. Your security team approved a formatting extension last week. Both could be exfiltrating your source code right now.
Socket recently identified 73 fake VS Code extensions linked to the GlassWorm v2 campaign, with six confirmed as actively malicious. These extensions use Zig-based droppers and obfuscated JavaScript to steal credentials, tokens, and source code from development environments. The extensions mimicked legitimate tools that developers trust and install without a second thought.
This checklist helps you audit your current extension inventory and establish controls that align with supply chain security requirements in PCI DSS v4.0.1 (Requirements 6.3.2 and 6.3.3), NIST Cybersecurity Framework v2.0 (Supply Chain Risk Management), and SOC 2 Type II (Change Management controls).
What This Checklist Covers
You'll establish a defensible process for:
- Auditing currently installed extensions across your development fleet
- Implementing approval workflows before new extensions enter your environment
- Monitoring extension behavior and update patterns
- Responding when a malicious extension is discovered
This is not about blocking all extensions. It's about knowing what's running in your development environments and having evidence that you reviewed it.
Prerequisites
Before you start:
- Inventory tool access: You need a way to query installed extensions across developer workstations (MDM solution, VS Code Settings Sync, or custom script).
- Baseline documentation: Document your current state before implementing controls (auditors will ask for before/after evidence).
- Change management system: You need somewhere to log approval decisions (ServiceNow, Jira, or even a tracked spreadsheet).
- Communication channel: Establish how you'll notify developers when an extension is flagged or blocked.
Extension Security Checklist
1. Audit Your Current Extension Inventory
Task: Generate a report of every VS Code extension installed across your development team.
How to verify: You have a spreadsheet or dashboard showing extension ID, version, install count, and last update date for every extension in use.
Good looks like: You can answer "How many developers have extension X installed?" in under five minutes. You know which extensions are company-wide versus individual experiments.
2. Identify High-Risk Extensions
Task: Flag extensions with fewer than 10,000 installs, extensions updated in the last 30 days, or extensions from publishers with only one or two published extensions.
How to verify: Your inventory includes a risk flag for each extension based on these criteria.
Good looks like: You've marked approximately 15-30% of your extensions as "requires review" based on risk indicators. Extensions like Prettier (millions of installs, established publisher) are marked low-risk. Extensions with 200 installs from a new publisher are marked high-risk.
3. Review Publisher Verification Status
Task: For each extension, document whether the publisher is verified by Microsoft and whether the publisher domain matches the extension's claimed purpose.
How to verify: Your inventory includes publisher verification status and you've manually checked the top 10 highest-risk extensions for domain/purpose alignment.
Good looks like: You've identified that "Python Formatter Pro" is published by "webdev-tools.io" (mismatch) versus "Python" published by Microsoft (verified, aligned).
4. Establish an Approved Extensions List
Task: Create a list of pre-approved extensions that developers can install without additional review.
How to verify: You have a documented list (wiki page, internal docs, or configuration file) that developers can reference. The list includes at least 20-30 commonly needed extensions.
Good looks like: Your list includes specific version ranges ("ESLint ^2.4.0"), publisher names, and extension IDs. Developers know they can install these immediately. Your list covers 70-80% of common use cases.
5. Implement a Request Process for New Extensions
Task: Create a workflow where developers can request approval for extensions not on the pre-approved list.
How to verify: You have a ticket template or form that captures extension name, business justification, and security review fields.
Good looks like: Requests are resolved within 2 business days. Your template asks: "What problem does this solve?", "What alternatives did you consider?", "Does this extension require network access?". Approved requests automatically update your approved list.
6. Review Extension Permissions and Network Behavior
Task: For each extension under review, document what permissions it requests and whether it makes network calls.
How to verify: You've documented the permission model (does it access files, execute commands, make network requests) for extensions flagged as high-risk.
Good looks like: You can explain why "GitLens" needs file system access (it reads git history) but why "Theme Pack Pro" shouldn't need network access. You've used browser dev tools or network monitoring to verify claimed behavior matches actual behavior for at least your top 10 most-installed extensions.
7. Monitor Extension Updates
Task: Set up alerts when approved extensions publish new versions.
How to verify: You receive notifications (email, Slack, or monitoring dashboard) when extensions update, and you've defined a re-review threshold (major version changes require re-review).
Good looks like: When an extension jumps from v2.1.5 to v3.0.0, you're notified within 24 hours. Your team reviews the changelog before the update propagates to developer machines. You've blocked auto-updates for extensions marked as high-risk.
8. Scan Extension Source Code for High-Risk Patterns
Task: For extensions not published from public repositories, request source access or remove them from your approved list.
How to verify: Every approved extension either links to a public GitHub repository or has passed a manual code review by your team.
Good looks like: You've verified that approved extensions don't contain obfuscated JavaScript, don't use eval() or Function() constructors, and don't make requests to unfamiliar domains. You maintain notes on what you reviewed and when.
9. Test Extensions in Isolated Environments First
Task: Before approving an extension for general use, install it in a sandboxed development environment and monitor its behavior.
How to verify: You have a test VM or container where you install and run suspicious extensions while monitoring file system access, network connections, and process execution.
Good looks like: You've caught an extension that attempts to access ~/.ssh/ or makes requests to non-extension-related domains during testing. You've documented this behavior as grounds for rejection.
10. Document Your Removal Process
Task: Write a runbook for removing a malicious extension from developer machines.
How to verify: Your runbook includes specific commands, communication templates, and escalation paths.
Good looks like: Your runbook specifies: (1) How to force-uninstall via MDM or remote command, (2) What to tell developers and when, (3) How to check for persistence mechanisms, (4) When to involve incident response. You've tested this process with a benign extension to verify it works.
Common Mistakes
Blocking all extensions without a request process: Your developers will find workarounds. Build the approval workflow first, then enforce it.
Approving based only on install count: The GlassWorm v2 campaign shows that malicious extensions can accumulate installs through social engineering. Verify publisher identity separately.
Ignoring extension updates: An extension that was safe at v1.0 can become malicious at v2.0 when the publisher account is compromised. Monitor updates for approved extensions.
Not documenting your reviews: When an auditor asks "How do you manage third-party development tools?", you need evidence of reviews, approvals, and monitoring. Screenshots and approval tickets matter.
Treating all extensions equally: A syntax highlighter that operates locally is lower risk than an AI coding assistant that sends your code to external APIs. Differentiate your review depth based on extension capabilities.
Next Steps
Start with items 1-3 this week. You need visibility before you can implement controls.
Schedule a 30-minute review meeting with your development leads to present your findings and proposed approved list. Get their input before you enforce restrictions—they'll help you identify which extensions are non-negotiable for productivity.
Within 30 days, you should have items 1-6 complete and evidence of at least five extension reviews. This gives you a defensible position if an auditor asks about software supply chain controls or if you discover a malicious extension in your environment.
The GlassWorm v2 campaign succeeded because organizations treated VS Code extensions as low-risk developer conveniences. Your job is to make extension management routine—reviewed, approved, monitored—before the next campaign targets your team.
