Search for a command to run...
No comments yet. Be the first to comment.
This guide was initially generated using AI. Rather than writing every sentence from scratch, I used AI as a research, drafting and teaching assistant to help produce a comprehensive first draft. The
A fresh Ubuntu installation is designed to be permissive, catering equally to desktop, server, and container workloads without assuming a strict security model. However, the moment a system is exposed
Developing software locally is only one part of the job. Systems must also operate reliably in production, handle failures, and remain maintainable as requirements change. A backend should be understa
Modern software systems power nearly every aspect of business operations, from banking platforms and healthcare systems to cloud infrastructure, e-commerce applications, and enterprise automation. As
Modern dev environments rely heavily on third-party extensions. Many of these extensions execute code locally and may have access to source code, config files, credentials, and other sensitive data.
A recent write-up from OX Security examined vulnerabilities in widely used IDE extensions, showing how flaws in extension design can enable remote code execution and local file exfiltration.
The exposure isn't limited to software engineers. Anyone using an IDE for scripting, automation, infrastructure management, or data processing operates within the same environment and is subject to many of the same risks.
VS Code and similar editors are deeply embedded in daily development workflows. That familiarity can make it easy to overlook how much access installed extensions may have.
Depending on their functionality, extensions can interact with:
Source code and build artifacts
Environment variables and configuration files
Credentials such as API tokens, SSH keys, and cloud access keys
Unlike app dependencies, extensions are often installed to solve an immediate problem and then forgotten. Automatic updates are common, permissions are rarely revisited, and extensions can remain present for years without review.
Many dev environments therefore contain software with access to code, systems, and credentials that receives little ongoing scrutiny. For security teams, this represents a blind spot that is easy to overlook and difficult to quantify.
The OX Security report identified vulnerabilities in several widely used IDE extensions, including issues that could be abused to execute code or access local files.
Examples included:
Remote code execution through exposed extension functionality
Local file exfiltration through crafted inputs
Insufficient validation of data received from external sources
The vulnerabilities were identified in extensions that were already in widespread use.
The challenge often comes down to visibility.
In many environments:
Extension inventories are not centrally tracked.
Permissions are not reviewed regularly.
Extensions remain installed long after their original purpose has passed.
Formal reassessment and removal processes are uncommon.
As a result, IDE extensions gradually become part of the attack surface. They exist across developer workstations, have access to source code and local resources, and frequently receive little attention during security reviews.
If you want to audit extensions, the first step is simply knowing what is installed.
On macOS, you can list all your VS Code extensions by running:
ls ~/.vscode/extensions
Each directory follows this format:
publisher.extension-version
Important: Only include the Extension ID and NOT the version number
Extension scanning and auditing tools, such as VSCan, expect the extension ID in the following format otherwise the tool will not recognise it:
publisher.extension #nothing else
To extract clean extension IDs on macOS, run this in your terminal:
for dir in ~/.vscode/extensions/*; do
name=\((basename "\)dir")
echo "${name%-*}"
done
This list can then be used for:
Manual review – Check if extensions like ms-python.python or eamodio.gitlens are really needed, and remove any that are unused.
Feeding into scanning tools – tools such as VSCan can analyse each extension for risky behaviours or suspicious permissions.
Cross-referencing against vulnerability disclosures and advisories – See if installed extensions match those flagged in vulnerability reports, such as the OX Security blog highlighting Live Server or Markdown Preview Enhanced.
Staying informed – Devs should consider following sources like The Hacker News, security blogs, and advisory feeds to stay up to date on new extension vulnerabilities and patches.
Here’s an example of the output you can expect to see from VSCan:
Risk indicators are not absolute: Even well-maintained extensions can introduce exposure depending on how they are configured, what files they can access, and whether they have network reach. The actual risk is determined less by the extension itself and more by the environment it runs in and the privileges it operates under.
Unlike system packages or backend dependencies, IDE extensions don't have a mature, centralised vulnerability tracking ecosystem. That makes conventional dependency scanning only partially effective.
In environments where no formal process exists, tools such as VSCan can help by analysing installed extensions for risky behaviour patterns and known security concerns. The goal is to replace assumption-based trust with observable facts about what each extension actually does.
From there, a lightweight operational baseline is often enough:
Periodic review of installed extensions to ensure each one still serves a purpose
Removal of unused or redundant extensions to reduce overall attack surface
Preference for extensions that are actively maintained or published by trusted sources
This approach avoids unnecessary process overhead while still reducing exposure in a meaningful way.
IDE extensions operate within the same trust boundary as the rest of your software stack. They may look like productivity tools, but they still execute code and interact with sensitive data.
Addressing this does not require complex policies or restrictive controls. It starts with visibility and a habit of asking a simple question:
What is running inside this environment?
Whether you're developing applications, processing data, or managing infrastructure, your editor is part of the software supply chain. It should be evaluated with the same level of attention as any other dependency.