How should teams handle VS Code extensions that fetch code at runtime?

Why This Matters for Security Teams

VS Code extensions that fetch code at runtime should be treated as executable supply chain components, not just developer convenience tools. The trust decision is no longer fixed at marketplace review because the extension can change after install, introduce new network dependencies, and execute code that was never inspected. That creates an NHI problem as much as a software supply chain problem, because the extension effectively behaves like an autonomous workload with its own identity and outbound access.

For security teams, the real risk is not only malicious intent. It is also drift: a benign extension can become high risk when a maintainer updates a remote payload, a CDN is compromised, or a dependency chain silently changes. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which is a useful reminder that externally reachable trust boundaries are common and often under-governed in practice. The same logic applies to runtime-fetching extensions, especially when they can spawn child processes or access local secrets.

Current guidance suggests treating these extensions as continuously evaluated code, with runtime monitoring aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls and the broader lifecycle visibility model in Ultimate Guide to NHIs. In practice, many security teams encounter extension abuse only after outbound traffic or unexpected child processes have already occurred, rather than through intentional review.

How It Works in Practice

The operational question is how to reduce trust in a component that can rewrite its own behaviour after approval. The answer is to combine allowlisting, runtime telemetry, and containment. Marketplace vetting is still useful, but it is only the first checkpoint. Teams should verify where the extension loads code from, whether those domains are fixed or dynamic, and whether the extension can execute downloaded payloads without further user interaction.

In practice, monitoring should focus on three signals: outbound connections, spawned processes, and changes to post-install artifacts. If an extension starts reaching new domains, calling script interpreters, or altering files outside its package boundary, that should trigger review or quarantine. Security teams should also validate whether the extension needs access to secrets, source trees, or build tooling at all. If not, those capabilities should be blocked at the workstation, EDR, or application control layer.

• Restrict extensions to approved publishers and known hash baselines.
• Alert on new outbound domains, especially CDN or paste-style endpoints.
• Monitor child process creation from the editor process.
• Inspect post-install file changes and runtime-fetched modules.
• Treat secret access as a privileged capability, not a default permission.

This model aligns with the lifecycle and visibility emphasis in Ultimate Guide to NHIs, and it maps cleanly to asset and change monitoring expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when extensions are allowed unrestricted internet access in developer workstations that also hold long-lived credentials and production tokens.

Common Variations and Edge Cases

Tighter extension control often increases developer friction, requiring organisations to balance productivity against runtime assurance. That tradeoff becomes sharper in environments where teams rely on fast-moving extension ecosystems, internal plugin marketplaces, or remote development hosts. There is no universal standard for this yet, so guidance should be adapted to the risk level of the workstation and the sensitivity of the repos and secrets it can reach.

Some extensions only fetch signed updates from a fixed vendor endpoint, which is lower risk than extensions that dynamically load arbitrary code or shell out to system tools. Best practice is evolving, but current guidance suggests using stronger controls whenever an extension can modify itself, invoke interpreters, or access credentials. In high-trust developer environments, monitor for domain changes and payload drift rather than assuming version numbers tell the whole story.

Where teams already use device control or EDR, the most practical rule is simple: if the extension can change its execution path after install, it should be governed like an active workload. That is consistent with the NHI Mgmt Group view that trust must follow runtime behaviour, not just initial approval. In practice, unmanaged exceptions usually appear first in fast-moving engineering teams that value convenience over control.

Related resources from NHI Mgmt Group

• How should teams assess risky VS Code extensions before allowing them on developer machines?
• How should security teams handle risks from AI browser extensions?
• How should teams handle secrets that have no obvious owner?
• How should security teams prioritise NHI remediation in cloud environments?