Local Dev Tools and Security Implications

Modern development environments are powerful by design. That power comes with a trade-off that is often ignored in day-to-day work: third-party extensions running with local access to your machine.

A recent write-up from OX Security highlights this clearly, documenting vulnerabilities in popular IDE extensions that can lead to remote code execution and local file exfiltration.

This isn’t limited to software engineers. Anyone using an IDE for scripting, automation, or data work is operating in the same environment.

Reference:
https://www.ox.security/blog/four-vulnerabilities-expose-a-massive-security-blind-spot-in-ide-extensions/

The Trust Boundary Problem

VS Code and similar editors tend to feel like local tools. They are familiar, fast, and deeply integrated into daily workflows. Over time, that familiarity creates a subtle assumption: that everything inside the editor is safe by default.

In practice, many extensions run with broad local permissions. They may be able to access:

• Local source code and build outputs

• Environment variables and configuration files

• Secrets such as API tokens, SSH keys, and cloud credentials

These permissions are rarely reviewed with the same rigor as backend dependencies. Extensions are installed ad hoc, updated automatically, and often left in place indefinitely.

The risk is not that extensions are inherently malicious, but that they operate inside a trust boundary that is often undefined, unenforced, and rarely audited.

What the Research Highlights

The OX Security report shows that this trust model does not hold under scrutiny, even for widely used extensions with large install bases.

Key findings include:

• Remote code execution via exposed extension functionality

• Local file exfiltration triggered through crafted inputs

• Weak assumptions about the origin and integrity of incoming data

These issues arise because extensions operate in a hybrid model: local execution combined with network access, without the same controls typically applied to production services.

The Visibility Gap

This is not primarily a tooling problem. It is a visibility problem.

In most environments:

• Extension inventories are not centrally tracked

• Permissions are not regularly reviewed

• There is no lifecycle process for reassessment or removal

Over time, IDE extensions become a silent part of the attack surface—present on every developer machine, but rarely included in security reviews.

Listing Installed VS Code Extensions on macOS

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.

Auditing Extensions Without Overengineering

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.

A Small Shift in Perspective

The key takeaway is straightforward. IDE extensions sit inside the same trust boundary as other dependencies, even if they are often treated as harmless convenience tools.

Addressing this doesn't require heavy governance or restrictive controls. It starts with basic visibility and a consistent habit of asking a simple question:

What is actually executing inside this environment?

Whether you're writing application code, working with data, or managing infrastructure, the editor is part of the software supply chain. It deserves to be treated with that same level of scrutiny.