VSCode插件市场不提供自动化审核能力，开发者需自行组合工具链实现本地或CI环境下的行为审计；其API仅支持只读操作，无源码、权限或运行时日志返回，且微软未开放沙箱审计接口。
VSCode插件市场本身不提供面向开发者的“自动化审核”能力——你无法用脚本一键触发对某个插件的合规性、安全性或行为审计。所谓“自动化审核”，实际是开发者主动组合工具链，在本地或 CI 环境中对插件行为做可观测、可验证的检查。
为什么不能直接调用 VS Code 市场 API 审核插件？
VS Code 扩展市场（包括官方 marketplace.visualstudio.com 和 Open VSX）只提供只读接口，用于搜索、下载和元数据查询，GET /api/search 或 GET /api/publishers/{publisher}/extensions 这类端点不返回插件源码、权限声明细节或运行时行为日志。更重要的是，微软未开放插件沙箱行为审计接口，也没有提供类似浏览器扩展的 manifest.json 静态策略扫描入口。
常见误判场景：
- 看到插件页面显示 “Verified Publisher”，就认为它已通过安全审查 —— 实际只是微软确认了发布者身份，不等于代码无恶意逻辑
- 用
vsce verify检查打包合法性，误以为等同于功能审计 —— 它只校验package.json结构、图标路径、README 格式等，不分析 JS/TS 代码行为 - 在本地安装后用 DevTools 检查渲染进程，却忽略插件可能在主进程或扩展主机中执行 Node.js 代码（如调用
require('child_process')）
真正可行的本地插件行为审计三步法
要对一个插件（比如 streetsidesoftware.code-spell-checker）做轻量但有效的自动化行为观测，核心是拦截、记录、比对它的实际动作，而非依赖描述文案或市场标签。
推荐做法：
- 用
code --inspect-extensions启动 VS Code，打开 Chromechrome://inspect，连接扩展主机进程，捕获所有eval、require和网络请求（注意：部分插件会禁用调试器） - 在项目根目录运行
node -r esbuild-register ./audit-plugin.mjs @vscode/vsce，用自定义加载器重写require，记录插件加载时引入的所有模块路径（尤其是fs、net、child_process） - 对插件解压后的
extension.js或dist/目录，用eslint+ 自定义规则扫描高危模式，例如：RegExp构造函数动态拼接、eval(、Function(、硬编码的 API 密钥正则、未校验的vscode.workspace.getConfiguration()调用
CI 中批量验证插件来源与签名的实操要点
团队若需在 CI 流程中自动拦截不可信插件（例如禁止使用非 Open VSX 官方源的私有 .vsix），关键不是“审核插件功能”，而是“验证分发链可信度”。
必须检查的三项：
-
.vsix文件是否带有效签名：用vsce verify-signature path/to/extension.vsix，失败时返回非零退出码，可直接中断 pipeline - 插件 publisher ID 是否在白名单内：解析
extension.vsix/package.json中的publisher字段，比对预置列表（如只允许ms-vscode、esbenp、stylelint） - 插件是否来自预期 registry：下载前校验
Content-Security-Policy响应头或 registry 返回的X-Content-Type-Options: nosniff，防止中间人替换 .vsix
最容易被跳过的点是：很多团队只校验 package.json 的 engines.vscode 兼容性，却忽略插件可能通过 process.versions.electron 绕过版本限制，直接调用 Electron 内部 API —— 这类行为只能靠动态沙箱（如 Firejail + strace）捕获，无法静态覆盖。
