Developer Workstation Security

Authored by:

s1ns3nz0

🔑 Key Takeaway: Screen untrusted development material before an integrated development environment (IDE), package manager, model loader, or artificial intelligence (AI) agent interprets it. Confinement limits the damage when screening misses a malicious input.

A developer workstation is an execution boundary, not just a place to edit code. Routine actions can activate content from another party before a developer reaches the application entry point.

This guidance applies when evaluating a new repository, contributor branch, coding exercise, dependency, development tool, agent integration, or model artifact. Perform intake on a credential-free system, then move only approved material into normal development environments.

Why the workstation is part of the supply chain

Source code reaches production through developers, their tools, and their credentials. A compromised workstation can alter source or lockfiles, steal package-publishing and cloud credentials, tamper with commits, or provide a foothold into internal systems. It can therefore compromise downstream builds even when the production pipeline is isolated.

Execution may begin when a tool interprets repository configuration, installs packages or extensions, starts Model Context Protocol (MCP) servers, follows agent rules or skills, accepts AI-suggested packages, or loads executable model artifacts. Treat opening, installing, importing, building, testing, and asking an agent to work as distinct execution decisions. Trust applies to a specific artifact and version, not to a familiar name, repository, or author profile.

Review each input's canonical source, execution triggers, requested permissions, data and credential access, network destinations, update behavior, and integrity evidence. Local MCP servers can run with the client's privileges, and some model formats execute code during deserialization, so their configuration and artifacts are executable software rather than passive data.

Govern external development tools

Organizations should govern anything brought into the development environment from an external source throughout its lifecycle. This includes extensions, MCP servers, coding agents, package-manager plugins and packages, model loaders and model artifacts, repository-supplied configuration, and other external development inputs and tools:

1. Establish business need. Record the approved use and why an existing capability does not meet it.
2. Classify risk. Assess execution, data, update, and communication risk in the intended environment.
3. Review the tool. Examine provenance, permissions, data flows, credentials, egress, and behavior.
4. Make the risk decision. Approve, reject, or grant a time-limited exception with compensating controls.
5. Deploy the decision. Distribute and enforce the approved version and configuration.
6. Monitor drift. Detect changes in version, permission, publisher, and behavior.
7. Reassess the decision. Review on a defined cadence and after material changes or incidents.
8. Revoke and remove. Withdraw access, remove the tool, and preserve the decision record.

Organizations may combine these functions in one role or distribute them across security, engineering, procurement, legal, and operations. The control objective is documented separation between the request, the risk decision, and ongoing ownership, not a prescribed department or organization chart.

Maintain a managed allowlist as the authoritative inventory of approved external development tools. Each record must include:

Inspection evidence should show inventory completeness, approval records, expired exceptions, periodic review completion, configuration enforcement, version or permission drift, removal evidence, and linked incident records. This evidence lets owners demonstrate that decisions remain current without asserting compliance with a particular regulation or standard.

Screen before execution

Apply the following gates in order. A failed or inconclusive gate keeps the material in quarantine.

1. Acquire without execution. Fetch the material into a quarantine directory or disposable virtual machine (VM) with IDE integration, file previews, shell directory hooks, agents, and package installation disabled. Do not start a referenced MCP server or load a model merely to inspect it.

2. Inspect provenance and execution triggers. Confirm the canonical source through an independent channel, then inspect signatures, release metadata, contributors, and the exact revision. Search workspace tasks and settings, launch and container files, Git hooks, package scripts, build plugins, MCP startup commands, agent rules and skills, and model-loading code. A plausible commit author or old timestamp does not defeat forged history; corroborate important revisions with signed releases, immutable object identifiers, repository audit data, or a known upstream. A trusted workspace may permit workspace auto-run, so keep Workspace Trust enabled, leave the folder untrusted in Restricted Mode, and require explicit approval before trusting it or enabling automatic tasks.

3. Scan and compare artifacts with reviewed source. Run static malware, dependency, secret, and policy scans without importing the project. Inspect unusually large whitespace, encoded strings, binary files in source paths, and bidirectional or invisible Unicode. Invisible Unicode can make displayed control flow differ from the compiled source, so use a scanner or editor view that exposes code points. Compare packaged files and model artifacts with reviewed source, checksums, signatures, and provenance; a clean source tree does not prove a separately built artifact is identical.

4. Approve dependencies and tools. Resolve every package name against the expected registry and publisher, including names proposed by AI tools. Confirm the item and intended use appear in the managed allowlist. Pin approved dependencies, extensions, MCP servers, actions, and model revisions to immutable versions or digests and verify integrity metadata. Install scripts execute during common package-manager operations, so block them by default and approve exceptions only after review. Mutable versions such as branches, floating tags, and ranges can resolve to different code after approval; do not treat them as a stable security decision.

5. Execute only in a confined, disposable environment. Use a fresh VM or hardened development container with no production, publishing, wallet, source-control, cloud, or personal credentials. Grant only required filesystem and process access, record activity, and allowlist required destinations. Unrestricted egress turns any missed execution path into a simple channel for payload retrieval or data exfiltration. Destroy the environment after the evaluation and promote only reviewed source and locked metadata.

Apply and verify baseline controls

Standardize controls so a developer does not have to reconstruct the intake boundary for each project. Workspace Trust reduces repository-driven execution, while extension and MCP allowlists address separately installed executable tools. Use endpoint detection and response (EDR) and mobile device management (MDM) to enforce and observe the baseline. Test the deployed configuration and retain its results; a documented setting is not evidence that endpoints enforce it.

This checklist defines the intake baseline. Apply the implementation patterns in Developer Machine Confinement and Sandboxing & Isolation rather than copying product-specific container, filesystem, or network configuration into this page.

Detect, respond, and learn from incidents

Collect endpoint, process, filesystem, network, IDE, agent, source-control, and package-registry telemetry. Alert on:

• Unexpected child processes: editors, agents, package managers, model loaders, or MCP clients spawning shells, downloaders, interpreters, persistence tools, or unsigned binaries outside an approved workflow
• Credential-path access: reads of wallet stores, browser profiles, SSH keys, cloud configuration, password-manager data, package tokens, or source-control credentials by development processes
• Unapproved egress: new domains, direct IP connections, tunneling, paste sites, or blockchain endpoints from an evaluation environment
• Tool drift: unapproved extension or MCP-server installation, changed hashes, disabled Workspace Trust, enabled automatic tasks, or divergence from the managed tool inventory
• Registry anomalies: a new publisher, unexpected ownership change, release outside the normal cadence, republished version, provenance failure, or package contents that differ from the reviewed source

When a signal indicates execution, isolate the endpoint without destroying volatile evidence, preserve relevant repository and tool artifacts, and identify every credential or signing capability the process could access. Revoke sessions and rotate exposed credentials from a clean device. Quarantine affected commits, packages, and build outputs; then hunt for the same indicators across developer systems, repositories, continuous integration, and registry logs. Coordinate the investigation through Supply Chain Incident Response. If malware may have executed, follow the immediate containment and recovery steps in the Malware Infection playbook.

The examples below connect a documented failure to a governance lesson. Dates are source publication and update dates, not when activity began or ended. The PolinRider execution path is repository-controlled workspace automation, not a malicious extension installation: the repository supplies the task, while the IDE's built-in task runner interprets it after trust is granted. Extension publishing incidents involve a separate artifact, approval path, and detection signal.

Further reading

• Risk Management: ownership patterns for risk acceptance, exception decisions, and recurring review
• Compliance & Regulatory Requirements: adaptable compliance- governance context for assigning evidence, review, and oversight responsibilities
• DPRK IT Workers: organizational controls for DPRK-linked hiring and insider risk
• AI Security: runtime controls for AI systems, coding agents, tool calls, and model use
• Endpoint Security: managed endpoint provisioning, EDR, MDM, and credential-separation ownership
• Integrated Development Environments: extension review and general IDE hardening
• Dependency Awareness: package pinning, lockfiles, and dependency review
• VS Code Workspace Trust: official behavior for Restricted Mode, tasks, settings, extensions, and AI agents
• VS Code automatic task controls: official documentation for runOn: "folderOpen" and task.allowAutomaticTasks
• Model Context Protocol security best practices: risks and confinement guidance for local MCP servers
• SLSA artifact verification: verifying artifact digests, signatures, canonical source, builders, and provenance
• npm lifecycle scripts: install-time execution behavior
• PyTorch model loading: warning against loading data from untrusted sources
• Trojan Source paper: analysis of bidirectional Unicode control characters that can alter how source code is displayed