VS Code 1.123 Adds Two-Hour Extension Update Delay to Limit Supply Chain Attacks
TL;DR · AI 摘要
VS Code 1.123 引入两小时扩展更新延迟，以减少供应链攻击风险。
核心要点
- VS Code 1.123 引入两小时扩展更新延迟，防止恶意更新。
- 受信任的发布者（如 Microsoft、GitHub）的扩展仍可立即更新。
- 其他生态系统（如 npm、RubyGems）已引入类似延迟机制。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- VS Code 1.123 更新延迟机制
- 更新延迟机制
- 两小时延迟
- 自动更新触发
- 信任发布者例外
- Microsoft
- GitHub
- OpenAI
- 其他生态系统措施
- npm
- RubyGems
- Bundler
金句 / Highlights
值得收藏与分享的关键句。
When automatic updates are enabled, new versions are auto-updated two hours after they are published, adding an extra layer of protection against problematic or potentially compromised releases.
The biggest myth in cybersecurity I've ever heard is 'Make sure you download every update as it becomes available.'
Research found that a seven-day cooldown would have stopped 8 out of 10 analyzed supply chain attacks.
VS Code 1.123 增加两小时扩展更新延迟以限制供应链攻击 - InfoQ
InfoQ 首页 News VS Code 1.123 增加两小时扩展更新延迟以限制供应链攻击
开发
为自主可靠性架构：将 AI 嵌入您的可观测性堆栈（网络研讨会 6 月 25 日）
VS Code 1.123 增加两小时扩展更新延迟以限制供应链攻击
6 月 18 日，2026 年，3 分钟阅读
作者
- Steef-Jan Wiggers
#### 为 InfoQ 撰写文章
激发你的好奇心。
帮助 55 万+ 全球
高级开发人员
每个月保持领先。
联系我们
收听这篇文章 -
0:00
音频准备播放
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新的下拉阅读列表
- 阅读列表
从 VS Code 1.123 开始，于 6 月 3 日发布，新发布的扩展版本在自动更新之前会等待两个小时。这个想法很简单：如果有人入侵了扩展维护者的账户并推送了恶意更新，那么就有一个窗口期可以发现并阻止该发布，避免其传播到数百万开发人员。你仍然可以在任何时候手动点击“更新”。微软对此解释得非常清楚：
当启用自动更新时，新版本在发布后两个小时自动更新，这为防止有问题或可能被入侵的发布增加了一层额外的保护。
一个例外情况是：延迟不适用于来自“受信任发布者”（如 Microsoft、GitHub 和 OpenAI）的扩展。这些扩展仍然可以立即更新。考虑到拥有大量安装基础的受信任发布者恰恰是账户入侵的最高价值目标，这个例外情况看起来有些奇怪。
这一举措紧随其他包生态系统中类似控制措施的浪潮。Pip 26.1 最近发布了可配置的依赖项冷却时间，团队可以阻止发布不到七天的包。研究发现，七天的冷却时间可以阻止 10 个分析的供应链攻击中的 8 个。RubyGems 为 Bundler 添加了可选的冷却时间。npm、pnpm、Yarn 和 Bun 在过去一年中都引入了最低发布年龄设置。VS Code 现在加入了 IDE 扩展层，尽管它的两小时窗口期远短于其他生态系统提供的窗口期。
Reddit 的帖子对两小时的延迟并不友好。最高赞的评论（超过 650 个赞）设定了基调：
两小时远远不够，因为许多供应链入侵是在几天甚至几周后才被发现的。我认为默认设置应更长一些，并且应增加一个选项让用户自行选择。
一位安全从业者对“立即更新”的正统观念提出了更强烈的反驳：
我听过的网络安全领域最大的一个误区是“确保在更新发布时立即下载每一个更新”。我在非常安全的环境中工作过。我们从未及时更新。通常会有一个长达一周甚至一个月的延迟，除非是针对特定漏洞的补丁。
并非所有人都完全否定了两小时的窗口期。一位评论者指出，大多数恶意包是由自动化扫描器发现的，而不是人类：
由用户发现的恶意 npm 包寥寥无几，大多数是由自动化安全扫描器发现的。VS Code 扩展也是如此。当新包发布时，安全扫描器会立即查找可疑代码。但两小时确实非常短。毕竟，当安全扫描器标记了一个包时，仍然需要有人去核实威胁是否真实。
一些评论者认为，冷却期完全偏离了问题的核心。有人提出，VS Code 应该通过明确的权限来对扩展进行沙箱隔离，就像移动操作系统对应用程序所采用的模型一样。另一个人建议采用分阶段发布的方式：5% 的用户立即获得更新，另外 10% 的用户在几个小时后获得更新，然后在几天内逐步扩大到所有用户。这样，被攻击的更新首先只影响一小部分用户，为扫描工具和社区提供了在广泛发布之前做出反应的时间。
实际验证来自已经使用更长冷却期的开发者。一位评论者报告称，他将 npm 库设置为两周的延迟，并表示“它避免的问题比造成的还要多。”另一位分享说，他们公司对其内部的 npm 仓库实施了六天的政策。一位 pnpm 用户则归功于 minimumAgeRelease 配置，称它在过去几个月中帮助他避免了两次供应链攻击。
目前仍缺乏任何冷却机制的生态系统是 WordPress。如 InfoQ 最近所报道的，一名攻击者在 Flippa 上购买了 30 多个插件，在首次提交中植入了后门，并在八个月后才激活。没有发布延迟，没有控制权变更的审查，也没有强制性的代码签名。VS Code 的这一改变，尽管看似微小，却使得这种缺失更难以忽视。
对于管理 VS Code 部署的团队，默认情况下两小时的延迟是启用的，无需任何配置。那些希望延长窗口期的人可以完全禁用自动更新，并通过基于策略的白名单或内部精选市场来管理扩展版本。
VS Code 1.123 现在已可在 Windows、macOS 和 Linux 上使用。
main wrapper for authors section
关于作者
section title
main wrapper for each author
#### Steef-Jan Wiggers
显示更多
显示更少
#### 本内容属于 Visual Studio Code 主题
##### 相关主题：
- 开发
- 架构与设计
- DevOps
- 应用程序安全
- 软件供应链
- Visual Studio Code
- 相关编辑
- 相关赞助商 了解 AI 代理安全性
- 相关赞助商 使用 Promptfoo 对您的 LLM 应用进行测试、评估和红队演练 —— 捕获回归，对模型进行基准测试，并更快地发布高质量的 AI 功能；今天就开始测试您的提示。了解更多。
InfoQ 新闻通讯
每周内容摘要，每星期二发送。加入超过 25 万名高级开发者的社区。查看示例
我们保护您的隐私。