VSCode插件市场无实时安全检测，依赖静态审核、身份核验与用户反馈；“Verified Publisher”不保证代码安全；package.json中capabilities声明仅提示用户，不强制限制；真正有效的安全检测需本地工具链（vsce verify、Extension Guard、CodeQL）离线执行。
VSCode插件市场本身没有实时安全检测机制
官方 Marketplace 不会对每个扩展做运行时行为分析或动态沙箱检测。它依赖的是静态审核 + 发布者身份核验 + 用户反馈三重机制，但面对日均新增上百个扩展的现实，审核深度有限。你看到的“Verified Publisher”标识只代表邮箱/公司信息通过了微软基础验证，并不等于代码无恶意逻辑。
package.json 中的 "capabilities" 声明是唯一强制性安全约束
自 VSCode v1.86 起，所有新发布扩展必须在 package.json 中显式声明所需能力，比如 "workspace": "read"、"env": true、"terminal": "execute"。但声明≠限制——VSCode 不会阻止扩展实际调用未声明的 API，只是在安装页展示给用户看。真正起作用的是用户是否点“同意”。
- 声明了
"*://*/*"网络权限却只做语法高亮？大概率可疑 - 声称支持远程开发，但
untrustedWorkspaces.supported为false？说明 manifest 和功能描述矛盾 - 没声明
"localProcess"却在代码里调用require("child_process")？属于静默越权，需靠静态扫描工具发现
能落地的安全检测只能靠本地离线工具链
真正有效的检测不在市场侧，而在你本机。目前最实用的组合是：vsce verify（验签名）、Extension Guard（静态行为模式扫描）、CodeQL（语义级漏洞挖掘）。它们都不上传代码，全部本地运行。
-
vsce verify xxx.vsix只能确认包没被篡改、证书有效，无法判断逻辑是否恶意 -
Extension Guard会解析main.js和所有require()调用链，识别eval()、Function()、硬编码 IP 或域名等高风险模式 -
CodeQL需先构建数据库，适合对已安装扩展做深度审计，比如查它是否在 WebView 通信中拼接未过滤的用户输入
“已安装扩展”的行为监控比“安装前检测”更关键
很多恶意扩展在首次激活时不触发 payload，而是监听特定事件（如打开 Git 仓库、执行终端命令）才加载第二阶段模块。所以单看 manifest 或静态扫描仍可能漏掉。
- 打开命令面板 → 运行
Developer: Open Process Explorer，观察扩展进程的 CPU / 网络连接异常波动 - 禁用可疑扩展后，用系统工具（如 macOS 的 Activity Monitor 或 Windows 的 Resource Monitor）检查 VSCode 是否仍有异常外联
- 某些扩展会注入 Webview 并绕过 CSP，此时需手动检查 DevTools → Network 标签页中是否有陌生域名请求
"workspace": "read" 和 "env": true 的代码格式化插件——它本不需要读取环境变量，这种冗余声明就是人工复核的重点。 
