“当启用自动更新时，新版本将在发布后两小时自动更新，为存在问题或疑似遭篡改的发布版本增设了一道额外防护屏障。”微软在VS Code 1.123版本的发布说明中这样解释新机制的设计逻辑。从6月3日起，所有新发布的扩展版本不再即时推送，而是先等上两个小时。如果插件维护者的账号在这期间被不法分子盗用、上传了恶意代码，官方还有机会在数百万开发者收到更新前把问题版本撤下来。不过用户随时可以手动点击更新按钮，绕开这道缓冲。
这项机制的动机不难理解：软件供应链攻击越来越频繁，攻击者盯上的不是最终用户，而是开发者工具这条上游通道。一旦插件的分发渠道被污染，恶意代码能顺流而下进入无数个项目。两小时的窗口期，理论上给了安全团队一个极短的响应时间。但问题出在微软给这条规则开了个例外——微软、GitHub和OpenAI等“可信发布者”的扩展不经延迟，照样即时推送。考虑到这些发布者恰好拥有最庞大的安装基数，它们的账号恰恰是攻击者眼中价值最高的目标，单独把它们拎出来豁免，让整项保护措施的逻辑显得有些自相矛盾。
Reddit上一位获得超过650个点赞的评论直接点出了这种不满：“两小时冷静期远远不够，因为很多供应链入侵是在几天甚至几周后才被发现的。我觉得默认延迟时长应该设置得更长一些，同时再提供可供用户自定义时长的选项。”这条评论基本定下了讨论区的主流基调。另一位安全行业从业者的批评更尖锐：“我在网络安全领域听过的最大的一个神话就是‘确保一有更新就立即下载’。我曾在极高安全等级的环境中工作过，我们从来不会第一时间跟进更新。除非是针对高危特定漏洞的补丁，其余更新一律会延后一周乃至一个月。”
不过，并非所有人都全盘否定两小时窗口的价值。有评论者指出，大多数恶意包是被自动化扫描工具而非人工发现的：“绝大多数恶意npm软件包都不是用户发现的，而是自动化安全扫描工具检测出来的，VS Code插件的情况也是如此。新版本包一经发布，安全扫描工具会立刻检索可疑代码。”这位评论者接着承认，两小时对机器来说或许足够跑完一轮扫描，但后续的人工核查环节需要的时间远不止于此，“毕竟就算扫描工具标记出存在风险的安装包，仍需要人工核查，确认威胁真实存在。”
这场争论的背景是整个软件包生态系统在过去一年间密集推出的安全管控措施。Python的包管理器pip在26.1版本中引入了可配置的依赖冷却期，允许团队屏蔽发布不足七天的包；研究显示，七天冷却期可以阻止已发生的供应链攻击中80%的案例。RubyGems也为Bundler加上了可选的冷却期。npm、pnpm、Yarn和Bun则陆续引入了最小发布时长限制。相比之下，VS Code的两小时窗口在整个生态圈里是最短的，这成了Reddit讨论中反复被提及的槽点之一。
多名评论者认为，延迟更新本身并没有触及问题的根源。有人建议VS Code应该像移动操作系统管理应用那样，给插件加上沙箱隔离和权限管理。还有人提出了分阶段灰度推送的方案：先向5%的用户开放新版本，几小时后再扩大到10%，随后几天逐步放量，直到覆盖所有用户。这样一来，即使某个更新包被动了手脚，受影响的也只是极小一部分用户，扫描工具和社区有充足时间在更大范围分发前识别出风险并阻断传播。
已经有人在其他平台上实践了更长的延迟策略，并给出了正反馈。一位网友说，他将npm库的更新延迟设置为两周，“这种设置避免的问题比造成的问题多”。另一人提到所在公司对内部npm仓库强制执行六天延迟。还有一位pnpm用户说，minimumAgeRelease配置在过去几个月里帮他们挡下了两次供应链攻击。这些零散的个案至少说明，更新延迟确实能在真实场景中起到拦截作用，而非只是理论上的防御手段。
目前仍然缺少更新缓冲机制的一个例外是WordPress。据InfoQ报道，一名攻击者在网站交易平台Flippa上购买了超过30个插件，首次提交代码时就植入了后门，随后等待了八个月才激活。这套攻击之所以成立，正是因为WordPress既没有发布延迟机制，不审查控制权变更，也不强制要求代码签名。在这样一个对比参照系下，VS Code的两小时延迟虽然力度有限，却让其他平台安全机制的缺失变得更加显眼。对于需要管理团队级别VS Code部署的人，两小时延迟默认开启，无需额外配置。如果觉得两小时还不够，可以彻底关掉自动更新，转用基于策略的许可名单或自建内部插件市场来集中管控版本。
热门跟贴