A New Security Mindset: Friction Before Code Execution
Software supply chain attacks are attacks in which adversaries compromise dependencies, build tools, or extensions so that malicious code executes during routine development workflows without any direct action from the victim beyond installing or updating software. npm and Visual Studio Code are responding by inserting deliberate friction between dependency installation and automatic code execution. Instead of assuming that everything pulled from a registry or marketplace is safe, both tools now force developers or security teams to make explicit trust decisions about when and how untrusted code is allowed to run. That shift turns common automation paths—npm install scripts and VS Code extension updates—into guarded checkpoints rather than invisible execution surfaces. These changes will not remove dependency vulnerabilities or code execution risks, but they do slow down attacks and give people and scanners time to catch suspicious behavior before it spreads widely.
npm 12: Install Scripts Turn from Default to Opt-In
In npm 12, GitHub is making one of the most significant changes to Node.js package installation in years: install scripts are disabled by default. GitHub calls install-time lifecycle scripts "the single largest code-execution surface in the npm ecosystem" because npm install runs scripts from every transitive dependency, so one compromised package can run arbitrary code across developer machines and CI. Now, preinstall, install, and postinstall scripts from dependencies are blocked unless explicitly allowed in the project. Native node-gyp builds are caught too, as implicit node-gyp rebuilds are treated as script execution. Git dependencies and remote URL dependencies also require explicit flags (--allow-git and --allow-remote). To prepare, GitHub recommends upgrading to npm 11.16.0+, running installs, and then using npm approve-scripts to whitelist only the packages whose scripts you trust before moving to npm 12.
VS Code 1.123: Two-Hour Extension Update Delay and Trusted Publishers
VS Code 1.123 adds a two-hour delay before automatic extension updates, creating a small but important revocation window. When an extension maintainer publishes a new version, auto-update waits two hours, giving security scanners and marketplace reviewers time to flag or pull compromised releases before they roll out to millions of developers. Manual updates still work immediately. Microsoft notes that "when automatic updates are enabled, new versions are auto-updated two hours after they are published, adding an extra layer of protection." A key carve-out is that extensions from trusted publishers such as Microsoft, GitHub, and OpenAI skip the delay and update instantly. That exception aims to preserve convenience for common tools but also concentrates code execution risks in a small set of very high-value targets, raising questions about whether trust lists should be narrower or more dynamic as the threat landscape changes.
Balancing Security Friction, Developer Experience, and Ecosystem Risk
Both npm’s new defaults and VS Code’s extension security delay accept more friction in exchange for fewer silent supply chain attacks. For npm users, the workflow changes from blind npm install to a review step: inspect warnings, run npm approve-scripts, and commit an allowlist of npm install scripts that are permitted to execute. That can break existing pipelines that rely on implicit postinstall behavior, but it sharply reduces accidental code execution risks from freshly compromised dependencies. In VS Code, the default two-hour delay is short compared with cooldowns elsewhere—pip, Bundler, and npm registries increasingly support multi-day minimum release ages—yet it still adds a checkpoint where scanners and maintainers can stop bad updates. Teams wanting stronger guarantees can disable auto-updating extensions and manage versions through allowlists or internal marketplaces, but the broader trend is clear: security-sensitive ecosystems are moving away from automatic trust toward explicit, configurable approval.
