Your developers installed 14 new VS Code extensions last week. How many did your security team review? If the answer is "none," you're not alone—and that's exactly what the threat actors behind GlassWorm are counting on.
The recent discovery of 73 fraudulent extensions in the Open VSX marketplace isn't just another supply chain incident. It's a wake-up call about a blind spot in most security programs: the lack of controls around IDE extensions. These myths about developer tool security have persisted because they're convenient, not because they're true.
Myth 1: "Marketplace vetting means extensions are safe"
Reality: Open marketplaces have minimal security review, and attackers exploit this systematically.
The GlassWorm campaign shows how easily threat actors bypass marketplace checks. Six extensions were activated in one week, followed by eight more the next week—a methodical operation that the Eclipse Foundation (which oversees Open VSX) only caught after the malware was already distributed.
The extensions impersonated trusted developer tools and used benign code at submission time. The malicious payload? Downloaded later from external accounts, after the extension passed whatever review process existed.
This isn't unique to Open VSX. Most extension marketplaces prioritize developer experience over security verification. They check for obvious malware signatures but don't perform behavioral analysis, code audits, or ongoing monitoring after publication.
Myth 2: "Developers know which extensions to trust"
Reality: Visual similarity and social engineering defeat even security-aware developers.
The fraudulent extensions in the GlassWorm campaign impersonated legitimate tools. They looked right, had plausible descriptions, and appeared to do what developers expected. The malware didn't activate immediately—it waited, establishing trust before connecting to external accounts to download GlassWorm.
Your developers are making trust decisions based on:
- Star ratings (easily manipulated)
- Download counts (inflatable)
- Visual branding (trivial to copy)
- Descriptions (written by the attacker)
They're not reviewing source code, checking publisher verification status, or analyzing network behavior. Even if they wanted to, most extensions update automatically, so a trusted extension today could ship malicious code tomorrow.
Myth 3: "We'll catch malicious extensions with endpoint security"
Reality: IDE extensions operate in a privileged context that bypasses many endpoint controls.
Extensions run with the same permissions as your IDE, which typically means:
- Read/write access to all source code
- Access to environment variables (including secrets)
- Network connectivity without application-layer inspection
- File system access across the entire development workspace
The GlassWorm extensions connected to external accounts to download malware—a network operation that looks identical to legitimate extension behavior like checking for updates, downloading language servers, or syncing settings.
Your EDR might flag a standalone executable downloading and running malware. It's far less likely to flag a trusted IDE process making an HTTPS request to download what appears to be an extension component.
Myth 4: "Developer machines aren't high-value targets"
Reality: Developer environments are the crown jewels of your software supply chain.
Consider what's accessible from a compromised developer IDE:
- Source code for your applications
- API keys and credentials in environment variables or config files
- Cloud infrastructure access via CLI tools
- Internal documentation and architecture diagrams
- Direct commit access to your repositories
ISO 27001 Annex A.8.1 requires asset inventory and classification. If you're classifying developer workstations as standard endpoints rather than critical supply chain components, you're misunderstanding the threat model.
The GlassWorm malware specifically targets credential theft. From a developer's machine, those credentials can include:
- GitHub/GitLab tokens with repository write access
- AWS/Azure credentials with infrastructure permissions
- Database connection strings with production access
- Internal API keys with elevated privileges
Myth 5: "We can't restrict extensions without breaking developer productivity"
Reality: Balanced controls exist—you're just not implementing them.
The false choice between "no controls" and "locked-down environments" keeps organizations paralyzed. Here's what practical controls look like:
Allowlisting with exceptions: Maintain a vetted list of approved extensions. Developers can request additions through a lightweight review process—not a six-month security committee approval, but a 48-hour check by someone who understands both security and development workflows.
Network segmentation: Developer machines shouldn't have the same network access as production infrastructure. If an extension gets compromised, limit what it can reach.
Credential hygiene: Stop storing secrets in environment variables or config files that extensions can read. Use credential managers, temporary tokens, and principle of least privilege. PCI DSS v4.0.1 Requirement 8.3.2 requires authentication for all system components—that includes limiting what credentials live on developer machines.
Monitoring without blocking: Log extension installations, network connections from IDE processes, and file access patterns. You don't need to block everything, but you should know when something unusual happens.
What to do instead
Start with visibility. Before you can enforce controls, you need to know what extensions your developers are using:
Inventory current extensions across your development team. Most organizations discover they have 50+ different extensions installed, many duplicative or abandoned.
Establish a review process for new extensions. This doesn't mean security reviews every extension—it means defining criteria (publisher verification, source code availability, network behavior) and checking them before installation.
Implement technical controls where they matter most:
- Remove secrets from developer environments (use secret managers and temporary credentials)
- Segment network access so compromised developer machines can't reach production infrastructure
- Monitor for unusual behavior (extensions making unexpected network connections, accessing files outside the project directory)
Create an approved extensions list starting with the 10-15 most common tools your team uses. Review them once, document the decision, and make installation straightforward.
Plan for incidents because assuming you'll catch everything is the sixth myth. When (not if) a malicious extension gets installed, how quickly can you identify affected machines, revoke credentials, and assess impact?
The GlassWorm campaign added 73 fraudulent extensions to a single marketplace, with activations happening over multiple weeks. The Eclipse Foundation was notified and will remove them—but the attackers will upload more, to this marketplace and others. The question isn't whether malicious extensions exist. It's whether your security program acknowledges that IDE extensions are now a primary attack vector and deserves the same attention you give to other supply chain risks.
