自 VS Code 1.123 版本发布以来，新扩展插件在自动推送前将延迟两小时。此举旨在防止恶意攻击者窃取账号并上传恶意更新包。然而，这一措施引发了争议，特别是对于微软、GitHub 和 OpenAI 等可信发布者的插件。尽管这些插件仍会即时更新，但用户仍可手动点击更新。此举是软件包生态系统中同类安全措施的一部分，如 Pip 的依赖冷却期和 RubyGems 的可选冷却期。VS Code 引入的这一机制虽比其他生态系统短，但仍需改进以适应更广泛的安全需求。

--91likeyou---

此次改动紧跟各类软件包生态系统推出的同类安全管控措施。Pip 26.1 最近推出了可配置的依赖冷却期，团队可以屏蔽发布不足七天的包。研究发现，七天的冷却期可以阻止已发生的供应链攻击中十分之八的案例。RubyGems 也为 Bundler 添加了可选的冷却期。npm、pnpm、Yarn 和 Bun 在过去一年中都引入了最小发布时长限制设置。VS Code 现在也在 IDE 扩展层加入了这一机制，尽管两小时的窗口期比其他生态系统设置的要短得多。

Reddit 的一个讨论帖对这一时长并不买账。其中获得 650 多个点赞的热门评论定下了基调：

两小时冷静期远远不够，因为很多供应链入侵是在几天甚至几周后才被发现的。我觉得默认延迟时长应该设置得更长一些，同时再提供可供用户自定义时长的选项。

一名安全行业从业者对这种“即时更新”的固有主流观点提出了强烈反对：

我在网络安全领域听过的最大的一个神话就是“确保一有更新就立即下载”。我曾在极高安全等级的环境中工作过，我们从来不会第一时间跟进更新。除非是针对高危特定漏洞的补丁，其余更新一律会延后一周乃至一个月。

并非所有人都全盘否定两小时的冷静窗口。一位评论者指出，大多数恶意包是由自动扫描器发现的，而不是人工：

绝大多数恶意 npm 软件包都不是用户发现的，而是自动化安全扫描工具检测出来的，VS Code 插件的情况也是如此。新版本包一经发布，安全扫描工具会立刻检索可疑代码。但两小时的缓冲时长确实太短了。毕竟就算扫描工具标记出存在风险的安装包，仍需要人工核查，确认威胁真实存在。

多名评论者认为，设置更新缓冲期完全没有抓住问题核心。有人提议 VS Code 应当效仿移动端操作系统对应用的管理模式，为插件提供沙箱隔离机制并设置明确的权限。还有人建议采用分阶段灰度推送：先向 5% 的用户推送新版，再过几小时开放给 10% 的用户，随后数日里逐步扩大推送范围，直至所有用户。如此一来，若更新包遭到恶意篡改，受影响的只会是一小部分用户，扫描工具和社区也能在大范围分发前及时处置风险。

已有开发者在其他平台使用更长更新缓冲期的实际经验，印证了该方案的价值。一位网友表示自己将 npm 库的更新延迟设置为两周，并表示“这种设置避免的问题比造成的问题多”。还有人分享说，他们的公司对内部 npm 仓库强制执行六天延迟策略。一位 pnpm 用户称，minimumAgeRelease 配置在过去几个月内帮他们避免了两次供应链攻击。

目前仍未推出更新缓冲机制的生态是 WordPress。正如 最近报道的，一名攻击者在 Flippa 上购买了 30 多个插件，在第一次提交时就植入了后门，然后等待了八个月才激活。该平台没有发布延迟机制，没有控制权变更审查，也不强制要求代码签名。VS Code 的这一改变尽管力度有限，却让这套安全机制缺失的问题再也无法被无视。

对于管理 VS Code 部署的团队来说，两小时延迟机制默认启用，无需额外配置。那些想要更长窗口期的团队可以完全禁用自动更新，再通过基于策略的许可名单，或是自建内部精选插件市场来统一管控插件版本。

VS Code 1.123 现已可供下载，支持 Windows、macOS 和 Linux。

查看英文原文：

🔥 热词：#vs code必备插件 · #vs code代码提示插件 · #vs code下载插件 · #vs code 安装插件 · #vs code live server插件 · #vscode插件多了会卡么 · #vscode插件冲突 · #vscode插件code runner