Developer Workstation Security
Why isn't EDR enough for developer machines?
EDR (Endpoint Detection and Response) is insufficient for developer machines because it operates at the process and binary level, while developer threats operate inside trusted applications. EDR sees VS Code as a legitimate process and does not inspect what happens inside it — malicious extensions, compromised packages, and unauthorized MCP connections all execute within the trusted IDE boundary. EDR detects malware after execution; developer supply chain attacks need to be caught before installation.
What Is / Definition
EDR limitations on developer machines refer to the structural gaps in Endpoint Detection and Response technology that prevent it from detecting the categories of threats most relevant to software development environments.
EDR was designed to solve a specific problem: detecting malicious binaries, suspicious process behavior, lateral movement, and known malware signatures on endpoints. It excels at this. If ransomware executes on a developer's machine, EDR will likely detect it. If an attacker establishes a reverse shell, EDR will flag the anomalous network connection. These capabilities are essential and EDR remains a necessary layer in any security stack.
The limitation is that developer-specific threats do not look like traditional malware. A malicious VS Code extension is JavaScript running inside the VS Code Electron process. A compromised npm package executes its postinstall script within a Node.js process spawned by the developer's terminal. An unauthorized MCP server connection is an HTTP request from an AI coding assistant. None of these trigger EDR detection rules because they occur within processes that EDR explicitly trusts.
The numbers illustrate the gap: 1,283 VS Code extensions have been found with malicious dependencies (229 million installs combined), and 3,180+ confirmed malicious packages were identified across npm and PyPI in 2025. In September 2025, 20 npm packages with 2 billion weekly downloads were compromised. EDR detected none of these at the point of installation because they were not binary malware — they were supply chain compromises operating within trusted development tooling.
EDR's trust model was built for a world where applications were monolithic binaries. Developer environments are modular ecosystems of extensions, plugins, packages, and service connections — all running inside a single "trusted" process.
Why It Matters
For security leaders who have invested in EDR, understanding its developer machine limitations is critical for accurate risk assessment.
The practical impact is a false sense of coverage. Organizations that have deployed EDR across all endpoints — including developer workstations — reasonably assume those machines are monitored. The EDR dashboard shows green. Agents are healthy. No alerts. But the threats specific to developer environments are passing through undetected.
Consider a real scenario: a developer installs a VS Code extension that includes a dependency with a known vulnerability. The extension reads the developer's `.env` file containing API keys and database credentials, then exfiltrates that data via an HTTPS POST to an attacker-controlled domain. From EDR's perspective, VS Code (a trusted process) made an HTTPS connection (normal behavior for an IDE that syncs settings, checks for updates, and communicates with language servers). No alert is generated.
This gap has compliance implications. When a CISO reports to the board that \"all endpoints are monitored,\" that statement is technically true at the OS level but misleading at the application level. The developer workstation's most dangerous attack surface — the supply chain layer of extensions, packages, and AI tools — is unmonitored.
The September 2025 npm compromise affecting packages with 2 billion weekly downloads demonstrated this at scale. Organizations with robust EDR deployments were exposed because the compromised packages executed within normal Node.js processes. Detection came from package registry analysis and community reporting, not from endpoint security tools.
EDR remains essential, but treating it as sufficient for developer machines creates a dangerous coverage gap that attackers are actively exploiting through supply chain compromises.
How It Works
EDR's limitations on developer machines stem from its architectural design — specifically its trust model, detection methodology, and visibility boundary.
Trust model. EDR maintains allowlists of trusted applications. VS Code, JetBrains IDEs, terminal emulators (iTerm, Windows Terminal), and language runtimes (Node.js, Python) are standard allowlisted processes. When these processes perform actions — reading files, making network connections, spawning child processes — EDR evaluates them with lower suspicion than unknown binaries. A VS Code extension running malicious JavaScript is indistinguishable from VS Code running legitimate extension code, because it is the same process.
Detection methodology. EDR detects threats through behavioral analysis (unusual process trees, suspicious system calls), signature matching (known malware hashes), and anomaly detection (deviations from baseline behavior). Developer supply chain attacks do not trigger any of these. A malicious npm postinstall script reading `~/.ssh/id_rsa` and sending it over HTTPS looks behaviorally identical to a legitimate build script that reads configuration files and makes API calls. The actions are the same; the intent is different. EDR cannot distinguish intent.
Visibility boundary. EDR operates at the OS process level. It sees process names, file system access, network connections, and registry changes. It does not see inside application ecosystems. VS Code's extension API, npm's package.json dependency resolution, pip's virtual environment management, and MCP server protocol connections all operate within application boundaries that EDR does not instrument. The result is that EDR sees "VS Code is running" but not "VS Code extension X is reading credentials and sending them to an external server."
Timing gap. EDR is primarily a detection-and-response tool — it identifies threats during or after execution. Developer supply chain security requires prevention at the point of installation, before malicious code has the opportunity to execute. Once a compromised package runs its postinstall script, the damage is done. EDR may eventually correlate the resulting data exfiltration, but the initial compromise is invisible.