Managing and Securing VS Code Extensions at Scale

Editor’s Note: In this blog post, Palantir’s Information Security (InfoSec) team shares their approach to implementing a comprehensive VS Code extension management program, demonstrating practical solutions to a frequently overlooked attack vector.

Introduction

Integrated development environments (IDEs) serve as the primary interface for authoring code and managing infrastructure, sitting at the heart of every software company. Despite their ubiquity, it’s easy to overlook the security risks they present. Nearly every IDE user relies on extensions — familiar tools like code debuggers, git add-ons, and custom color themes that enhance productivity. However, these seemingly helpful extensions pose potentially disastrous risks to both individuals and enterprises.

While information security teams often focus on securing web browsers and their extensions, the IDE ecosystem presents an equally significant but less scrutinized attack surface. At Palantir, we’ve successfully implemented enterprise-wide security controls for browser extensions, but the world of IDE extensions was once largely uncharted territory.

This post details Palantir InfoSec’s journey to implement VS Code extension security at scale, building on lessons learned from our browser extension management program while addressing the unique challenges posed by development environments.

Background: Learning from browser extension security

Palantir has been managing browser extensions as code since 2022, using an allowlist-based system that balances security with productivity. This experience taught us several key principles that would prove invaluable as we tackled the challenge of IDE extension security:

1. Defining security policies in version-controlled repositories enables transparency, automation, and collaborative decision-making.
2. Allowing users to request changes through pull requests creates buy-in while maintaining security oversight.
3. Manual processes don’t scale, so successful security controls must integrate seamlessly into existing infrastructure.
4. Not all extensions pose equal risk, which means analysis tools help effectively prioritize review efforts.

The Problem: A security gap in development environments

Building on our mature browser extension controls, we identified an opportunity to extend similar protections to VS Code. Developers could install any extension from the marketplace without oversight, creating several concerning scenarios that we could no longer ignore.

Unlike browser extensions, many IDE extensions are integral to development workflows. Blocking them outright would severely impact productivity, while allowing them unchecked posed unacceptable security risks. Understanding that malicious VS Code extensions could achieve remote code execution in minutes, we prioritized implementing comprehensive technical controls.

Media Attention and Industry Recognition

The VS Code extension security problem gained significant media attention throughout 2024, validating our concerns and highlighting the urgency of the issue. Security researchers documented several cases of malicious extensions infiltrating the marketplace, including fake theme extensions and compromised developer tools that affected users at major corporations.

Notable examples include Aqua Security’s investigation into VS Code extension trust issues, where researchers successfully impersonated the popular Prettier extension and gained over 1,000 installations within 48 hours. Check Point discovered multiple malicious extensions with more than 45,000 combined downloads that actively stole personal information and enabled remote backdoors on victim machines. Koi Security demonstrated the severity of this attack vector by compromising systems at multi-billion-dollar companies within just 30 minutes using a fake extension that mimicked the popular Dracula theme.

The security community rallied around this issue, with companies like Koi Security emerging specifically to address VS Code marketplace security through automated analysis and threat detection. VS Code introduced enterprise extension controls in November 2024, providing the technical foundation needed for organizations to implement comprehensive protections.

These developments confirmed that our concerns were shared across the industry and that the time was right to implement comprehensive controls.

Understanding Palantir’s Extension Landscape

Before implementing any controls, we needed to understand our current state. Using osquery data, we discovered how many unique VS Code extensions Palantirians had installed across our fleet, which revealed both the popularity of the platform and the scope of the security challenge.

The data revealed several concerning patterns that would shape our approach. A surprising number of extensions were installed by only a single user, suggesting widespread experimentation without security considerations. This pattern indicated that half of our extension attack surface came from rarely-used, potentially unmaintained software. Many developers were unaware of which extensions they currently had installed. When we later released our impact assessment tool, numerous users discovered extensions they had completely forgotten about or never actively used.

Meanwhile, widely-adopted extensions cluster around essential categories: productivity tools, language support, and development utilities that teams actively rely upon for daily work. This landscape analysis revealed that any solution would need to carefully balance the legitimate productivity needs of our development teams against the clear security risks posed by uncontrolled extension installation.

Building Our Extension Analysis Framework

Given the scale and diversity of extensions in our environment, we needed a systematic approach to evaluate risk. Rather than becoming customers of existing solutions, we decided to build our own internal tool focused on static analysis and metadata review. We tailored our analysis engine to reflect the unique challenges that Palantir faces and customized the rules to match our understanding of security risk.

Our tool utilizes static analysis to identify potentially risky code behaviors including network and API calls that could facilitate data exfiltration, shell command execution events, hardcoded secrets or credentials, code obfuscation techniques, and overly permissive activation events. We integrated NPM audit to identify known vulnerabilities in extension dependencies, providing another layer of risk assessment. The tool automatically extracts and analyzes extension configuration files, permissions, and marketplace metadata to build comprehensive risk profiles.

This automated analysis gives us a foundation for making informed decisions about extension risk, though human judgment remains essential for balancing security concerns with developer productivity needs.

Extension Review Findings

Our comprehensive review of marketplace extensions yielded fascinating insights into developer behavior and the VS Code extension ecosystem:

• We found multiple instances of extensions with the same or nearly the same feature set as other extensions. This can lead to extension sprawl, which makes management more difficult.
• There were a significant number of extensions with low installation counts, yet these extensions can be extremely valuable for developer productivity. We are working with development teams to surface these high value extensions to a wider audience in order to improve developer experiences.
• We identified numerous extensions developed by Palantirians for their own productivity, highlighting the importance of supporting internal development while maintaining security controls.

These findings reinforced the need for careful, case-by-case evaluation rather than broad categorical rules.

Enterprise Configuration and Policy Design

With VS Code’s enterprise extension controls available, organizations are able to implement technical enforcement of extension policies. Our configuration strategy balanced security with operational simplicity in order to avoid overly complex versioning or tagging requirements that would create administrative overhead.

This enables us to allowlist a small set of highly trusted organizations whose entire extension catalogs receive automatic approval. The remaining extensions are allowlisted individually, ensuring proper security review for less established developers. We also have the ability to deny specific extensions from allowed publishers, providing flexibility when publishers release tools that don’t meet our security requirements. By not utilizing some of the more granular allowlisting options, such as version or tag-based allowlisting, we made it straightforward to manage and simple for developers to understand which extensions are and are not allowed. Below is an example of what a VS Code enterprise configuration can look like:

{
    "extensions.allowed": {
        // Allow all extensions published by Microsoft affilitiated publishers
        "microsoft": true,
        
        // Allow all extensions created by the publishers below
        "github": true,
        "palantir": true,
        "google": true,
    
        // Explicitly allow the extensions below
        "esbenp.prettier-vscode": true,
        "eamodio.gitlens": true,
        "continue.continue": true,
    
        // Do not allow Copilot web search extension
        "ms-vscode.vscode-websearchforcopilot": false,
    },
    "telemetry.telemetryLevel": "off"
}

In addition to the allowed extension configuration, VS Code enterprise settings provided us with the ability to configure the telemetry level of participating extensions. While analyzing extensions, we found that many collect telemetry via a package called Application Insights provided by Microsoft. Sending telemetry off to a third party is often a non-starter for us when evaluating tools, so we were concerned that we’d have to consider banning any extension that utilizes this functionality. Luckily, we are able to disable Application Insights and similar telemetry systems across all extensions to prevent data leakage to third parties by setting the telemetry level to off.

Integration with Existing Infrastructure

One of the key success factors was seamlessly integrating VS Code extension management into our existing infrastructure automation. Our extension allowlist GitHub repository includes automated validation similar to what we use for browser extensions, ensuring that the approved publishers and extensions do not conflict with denied extensions.

We leverage our existing Excavator service to automatically generate properly formatted configuration files for both macOS Jamf and Windows Group Policy profiles, reducing manual administrative overhead. The allowlist automatically deploys to our fleet through existing device management infrastructure, ensuring rapid and consistent enforcement. Like our browser extension controls, the VS Code allowlist lives in a GitHub repository where developers can request changes through pull requests, maintaining transparency and enabling collaborative security decisions.

Here’s how it works:

Step One: Submit an Extension Request
A developer who wants to use a new extension must get InfoSec approval in order for it to be enabled on their machine. This means that they must navigate to our GitHub repository containing the current extension configuration and submit a pull request with the extension ID. We require that they also provide business justification as to why the extension is important for their workflows and make them check that the existing set of allowed extensions doesn’t already cover their needs.

Step Two: Review the Extension Request
When a new extension request is submitted, we run the extension through our analysis tool in order to understand the risks it might pose. After weighing the findings and the user-provided business justification, the InfoSec engineer will make the determination whether to allow the extension or deny the request.

Step Three: Publish to Artifactory
Once the pull request is approved and merged, our CircleCI continuous integration scripts will automatically publish the results to Artifactory. We publish three .txt files: allowed_publishers.txt, allowed_extensions.txt, and disallowed_extensions.txt. This makes it easy to understand which extensions are allowed and which are disallowed.

Step Four: Generate the Allowed Extensions Configuration
With those files published to Artifactory, we created automation to quickly convert the .txt files into valid .json VS Code enterprise configurations. These scripts are triggered when new updates to the Artifactory files are published which then inform our Endpoint Engineering team that new updates need to be applied to users’ laptops.

Step Five: Enforce Policy on Mac and Windows
Finally, our Endpoint Engineering team utilizes Jamf Pro and Group Policy Objects to enforce the VS Code enterprise configuration settings, thus closing the loop on the new extension request.

This integration approach meant that our existing administrative processes and infrastructure could immediately support VS Code extension management without requiring new tooling or workflows.

Lessons Learned

Implementing VS Code extension security taught us several valuable lessons that will inform how we approach future security initiatives:

• We created an impact assessment script that we encouraged developers to run before we enabled enforcement of our extension controls. This script proved invaluable in garnering developer trust and buy-in. The tool allowed users to understand exactly how they would be affected and reduced resistance to the new controls.

#!/bin/bash
set -e

# Function to get installed extensions from VS Code extensions.json
get_installed_exts() {
    local ext_file="$1"
    
    # Check if extensions.json file exists
    if [ ! -f "$ext_file" ]; then
        echo "Extensions file not found: $ext_file" >&2
        return 1
    fi
    
    # Parse JSON and extract extension IDs, removing version suffixes
    jq -r '.[].identifier.id' "$ext_file" 2>/dev/null || {
        echo "Failed to parse extensions.json - invalid JSON format" >&2
        return 1
    }
}

# Get installed extensions from VS Code
EXTENSIONS_FILE="$HOME/.vscode/extensions/extensions.json"
INSTALLED_EXTENSIONS=$(get_installed_exts "$EXTENSIONS_FILE")

# Check if we got any extensions
if [ $? -ne 0 ] || [ -z "$INSTALLED_EXTENSIONS" ]; then
    echo "❌ Could not read installed extensions"
    exit 1
fi

# Read the configuration files in the same directory as this script
# NOTE: You must create the following .txt files with your enterprise configuration
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
ALLOWED_EXTENSIONS_FILE="$SCRIPT_DIR/allowed_extensions.txt"
ALLOWED_PUBLISHERS_FILE="$SCRIPT_DIR/allowed_publishers.txt"
DISALLOWED_EXTENSIONS_FILE="$SCRIPT_DIR/disallowed_extensions.txt"

AFFECTED_EXTENSIONS=()

while IFS= read -r ext; do
    [ -z "$ext" ] && continue

    publisher="${ext%%.*}"

    # Decision logic:
    # 1. If extension is explicitly disallowed, it's banned
    # 2. Else if extension is explicitly allowed, it's permitted
    # 3. Else if publisher is allowed, it's permitted
    # 4. Else, extension is banned (default deny)

    if grep -Fxq "$ext" "$DISALLOWED_EXTENSIONS_FILE" 2>/dev/null; then
        AFFECTED_EXTENSIONS+=("$ext") # extension disallowed, banned
    elif grep -Fxq "$ext" "$ALLOWED_EXTENSIONS_FILE" 2>/dev/null; then
        continue # extension allowed, skip
    elif grep -Fxq "$publisher" "$ALLOWED_PUBLISHERS_FILE" 2>/dev/null; then
        continue # publisher allowed, skip
    else
        # extension not explicitly allowed, banned
        AFFECTED_EXTENSIONS+=("$ext")
    fi
done <<< "$INSTALLED_EXTENSIONS"

if [ "${#AFFECTED_EXTENSIONS[@]}" -eq 0 ]; then
    echo "✅ You do not have any extensions installed that will be disallowed!"
else
    echo "❌ Extensions that will be DISALLOWED by this config:"
    echo "   (from $EXTENSIONS_FILE)"
    echo
    for ext in "${AFFECTED_EXTENSIONS[@]}"; do
        echo "   • $ext"
    done
    echo
    echo "Total disallowed extensions: ${#AFFECTED_EXTENSIONS[@]}"
fi

./scripts/how-will-i-be-affected-by-vs-code-security.sh 
✅ You do not have any extensions installed that will be disallowed!

• Our analysis revealed that many developers have no idea what extensions are listed in their environments. Our controls inadvertently helped users gain awareness of their tooling footprint and more intentionally curate their development environments around extensions they actively rely upon.
• Rather than viewing the allowlist as restrictive, many developers expressed relief at having a curated set of vetted extensions to choose from, viewing security controls as enabling rather than limiting. We discovered that developers sometimes struggle to navigate the VS Code marketplace, often installing the wrong extensions due to similar naming.

Conclusion

IDE extension security represents a critical but often overlooked aspect of enterprise security. VS Code’s enterprise controls enable security teams to implement comprehensive protections while maintaining developer productivity.

Our approach — combining automated risk analysis, collaborative policy development, and seamless infrastructure integration — has successfully reduced a significant attack vector while maintaining developer satisfaction. The key lies in treating this not as a pure security initiative, but as a collaboration between security and development teams to create a more secure and productive development environment.

The principles we’ve developed through both browser and IDE extension management can serve as a foundation for any organization looking to secure their development environment at scale. As the IDE ecosystem continues to evolve with new editors and extension capabilities, maintaining this security posture will require ongoing vigilance and adaptation. Policy as code, developer-driven processes, automation-first, and risk-based evaluation provide a scalable framework for meeting future challenges while keeping developers productive and workstations secure.

---

Managing and Securing VS Code Extensions at Scale was originally published in Palantir Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.