微软在 VS Code 1.123 版本中引入了一项低调但关键的安全改动：扩展程序发布新版本后，自动更新不再即时生效，而是强制等待 2 小时。这段时间给了安全团队和社区一个窗口——如果某个扩展被入侵、推送了恶意代码，2 小时内发现问题并下架，大量用户就不会已经被感染。
即时更新的隐患
VS Code 扩展商店的自动更新机制过去是"发布即推送"。一个拥有数十万安装量的扩展，一旦作者账号被盗或供应链被渗透，恶意版本会在几分钟内抵达绝大多数用户的机器。这不是假设——过去几年已经出现过多次真实事件：npm 包被劫持、Chrome 扩展被恶意接管、VS Code 扩展商店中也曾有伪装成流行工具的钓鱼扩展。
问题核心在于：开发者的 IDE 是高权限环境。扩展可以读写文件、执行 shell 命令、访问 Git 凭据、操作 Docker 容器。一个被入侵的扩展，杀伤力远超普通浏览器插件。
2 小时延迟的工作方式
从 1.123 起，当用户开启了扩展自动更新（默认开启），VS Code 不会在检测到新版本后立刻拉取安装，而是将更新请求挂起 2 小时。2 小时后，如果该版本仍然存在于商店中且未被标记为有问题，更新才会执行。
关键细节：
- 延迟只针对自动更新。用户手动点击更新按钮，或通过
code --install-extension命令安装，不受延迟限制。 - 延迟发生在客户端侧，不是商店侧——也就是说，扩展作者发布后版本立即可见，只是自动更新通道被按住了 2 小时。
- 如果在 2 小时窗口内微软或社区发现问题并将版本下架，用户的自动更新将不会执行。
这个设计本质上是一种"软熔断"：不阻断正常发布流程，但给安全响应留出时间。
供应链攻击的现实威胁面
VS Code 扩展的攻击面比很多人想象的要宽：
- 凭据窃取：扩展可以访问
~/.ssh/、~/.gitconfig、环境变量中的 API Key。 - 代码注入：扩展能在编辑器中注入 lint 规则或 snippet，潜移默化地引导开发者引入漏洞代码。
- 本地命令执行：通过 Task Provider 或 Debug Adapter，扩展可以执行任意 shell 命令。
- 依赖链污染：扩展自身依赖的 npm 包如果被入侵，效果等同于扩展本身被入侵。
2 小时延迟解决的是"发布后立即大面积扩散"的问题，但它不是万能的——手动安装不受限、已有版本中的潜伏恶意不受限、依赖链问题也不受限。
实践：审查与控制你的扩展更新策略
除了依赖微软的 2 小时缓冲，开发者自己也可以做更多。下面是一组可以直接使用的配置和脚本。
1. 关闭自动更新，改为手动审查
在 VS Code 的 settings.json 中：
{
"extensions.autoUpdate": false,
"extensions.autoCheckUpdates": false
}
关闭后，扩展列表中会出现可用更新提示，但不会自动安装。你可以在每次更新前查看 changelog 和版本差异，再决定是否升级。
2. 锁定当前安装的扩展版本清单
用一条命令导出所有已安装扩展及其版本，作为审计基线：
# 导出扩展 ID 列表（VS Code 原生命令）
code --list-extensions --show-versions > vscode-extensions-lock.txt
输出格式类似：
ms-python.python@2024.0.1
golang.go@0.40.0
dbaeumer.vscode-eslint@2.4.2
定期对比这个文件的变化，任何未预期的版本跳升都值得警惕。
3. 快速检查扩展最近更新时间与发布者信息
写一个简单的脚本，从 VS Code 扩展商店 API 拉取元数据：
#!/usr/bash
# check-ext-meta.sh — 查询扩展最近发布时间与发布者
# 用法: ./check-ext-meta.sh ms-python.python
EXT_ID="${1:?请传入扩展 ID，如 ms-python.python}"
curl -s "https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery" \
-H "Content-Type: application/json" \
-d '{
"filters": [{
"criteria": [{"filterType": 7, "value": "'"$EXT_ID"'"}]
}],
"assetTypes": [],
"flags": 0x192
}' | python3 -c "
import json, sys, datetime
data = json.load(sys.stdin)
for ext in data.get('results', [{}])[0].get('extensions', []):
publisher = ext.get('publisher', {}).get('publisherName', 'N/A')
name = ext.get('extensionName', 'N/A')
versions = ext.get('versions', [])
if versions:
last = versions[0]
date = last.get('lastUpdated', 'N/A')
ver = last.get('version', 'N/A')
print(f'扩展: {publisher}.{name}')
print(f'最新版本: {ver}')
print(f'发布时间: {date}')
else:
print('无版本信息')
"
运行示例：
chmod +x check-ext-meta.sh
./check-ext-meta.sh ms-python.python
# 输出:
# 扩展: ms-python.python
# 最新版本: 2024.0.1
# 发布时间: 2024-01-15T10:30:00.000Z
如果一个你很少关注的扩展突然在深夜推送了新版本，这就是一个值得深挖的信号。
4. 团队级策略：共享扩展白名单
在团队中，可以用一个共享的 JSON 文件定义允许安装的扩展和最低版本：
{
"allowedExtensions": {
"ms-python.python": { "minVersion": "2024.0.1", "reason": "官方 Python 支持" },
"golang.go": { "minVersion": "0.39.0", "reason": "Go 官方维护" },
"dbaeumer.vscode-eslint": { "minVersion": "2.4.0", "reason": "ESLint 核心" }
}
}
结合 CI 检查或入职脚本，确保团队成员不会随意安装未经审批的扩展。
2 小时够不够？权衡与建议
2 小时延迟是一个务实的折中：
- 好处：零配置、零成本，所有开启自动更新的用户立刻获得保护；对正常发布节奏几乎无影响——绝大多数扩展更新不需要"秒级到达"。
- 局限：手动安装绕过延迟；2 小时窗口对慢速攻击（潜伏数周后激活的恶意代码）无效；依赖链污染不在覆盖范围内。
对于个人开发者，建议的做法：
- 保持自动更新开启（享受 2 小时缓冲），但定期用
--list-extensions --show-versions记录基线。 - 对涉及凭据、SSH、Docker、Kubernetes 的高权限扩展，更新前手动查看 changelog。
- 不安装来源不明、安装量极低、发布者无法验证的扩展。
对于团队和组织：
- 维护扩展白名单，禁止安装未审批的扩展。
- 在入职流程中预装白名单扩展并锁定版本。
- 关注 VS Code 后续版本——微软已表示正在探索更多供应链防护机制，2 小时延迟只是第一步。
供应链攻击不会因为一个 2 小时延迟就消失，但每一层缓冲都在缩小攻击者的窗口。把这个机制用起来，再配合自己的审查习惯，防线就比"即时更新"时代厚了不少。