近日，安全研究人员披露了一种针对 Visual Studio Code（VS Code）开发环境的攻击方式。攻击者可以利用编辑器对特殊链接的处理机制，在恶意代码项目中预先构造特定内容，诱导开发者进行一次点击操作，进而触发恶意扩展安装。
值得关注的是，该攻击路径可能绕过 VS Code 的 Workspace Trust（工作区信任）防护机制。恶意扩展一旦成功安装，不仅能够执行攻击者预设的代码，还可能长期驻留在开发者设备中，对源代码、开发凭据以及其他敏感数据构成威胁。
VS Code 为降低未知代码仓库带来的安全风险，引入了 Workspace Trust 机制。
当开发者打开来源不明、尚未被信任的项目时，VS Code通常会进入受限模式。在这种状态下，包括任务执行、调试以及部分终端操作在内的高风险功能会受到限制，以降低未经用户授权执行代码的可能性。
然而，研究人员发现，攻击者可以从另一条路径突破这一安全边界。
VS Code除了能够识别常见的 HTTP、HTTPS 等链接外，还支持特殊的 command: 协议。与普通网页链接不同，这类链接可以调用编辑器内部注册的命令，并向相应命令传递参数。
攻击者因此可以在README、代码文件、注释或其他项目内容中嵌入经过构造的链接，再通过“安装依赖”“初始化环境”“配置开发工具”等具有迷惑性的文字，引导开发者点击。
一旦用户触发恶意链接，就可能调用VS Code内部的相关功能，为后续攻击创造条件。
此次攻击链中值得重点关注的是VS Code扩展安装能力。
攻击者可以提前准备恶意VSIX扩展包，并将其放置在恶意项目目录或攻击者能够控制的位置，再利用经过构造的命令链接尝试触发扩展安装。
与普通项目配置文件不同，VS Code扩展具备较强的系统交互能力。扩展通常可以执行JavaScript或TypeScript代码，并能够在用户权限范围内访问开发环境中的相关资源。
如果攻击者成功植入恶意扩展，其潜在目标可能包括：
本地项目源代码及配置文件；
SSH密钥和开发环境凭据；
Git代码仓库认证信息；
云平台访问令牌及API密钥；
CI/CD相关配置和凭证；
开发工具保存的身份认证信息；
用户权限范围内可访问的其他敏感文件。
因此，这类攻击的危险之处并不只是“一次恶意代码执行”，而是可能进一步演变为针对开发者工作站的长期控制。
传统恶意项目攻击通常与当前打开的代码仓库存在较强关联。当用户关闭项目后，部分攻击行为也会随之终止。
但恶意扩展安装成功后的情况有所不同。
扩展属于VS Code开发环境的一部分，一旦进入已安装扩展列表，就可能脱离原始恶意项目继续存在。开发者即使关闭相关代码仓库甚至重新启动计算机，恶意扩展仍可能在后续启动VS Code时再次加载。
这意味着攻击者可能将一次性的用户点击转化为持续性的攻击入口。
对于普通用户而言，这可能导致个人文件或账号凭据泄露；对于企业开发人员而言，影响范围可能进一步扩大至代码仓库、内部开发系统以及生产环境。
相比普通办公终端，开发人员使用的设备通常拥有更多高价值资源。
例如，开发工作站可能保存GitHub、GitLab等代码平台的访问凭据，同时还可能连接企业内部Git服务器、CI/CD平台、云服务器、容器平台以及生产环境。
部分开发人员还拥有软件发布、代码签名、服务器运维或云资源管理权限。
因此，一旦开发人员终端被攻击者控制，攻击范围可能从单台设备继续向企业内部基础设施扩散。
攻击者甚至可能利用获取到的代码仓库权限修改源代码、植入后门，并借助正常的软件构建和发布流程进一步传播，从而形成软件供应链安全事件。
此次披露的问题还暴露出一个值得关注的安全边界问题：工作区处于Restricted Mode（受限模式），并不意味着项目中的所有交互操作都不存在风险。
研究人员指出，恶意VSIX扩展可以声明自身支持不可信工作区。如果编辑器在相关场景下允许扩展完成安装和加载，攻击者就可能利用这一机制扩大攻击效果。
从用户角度来看，一个项目即使仍显示为“不可信”，也不能因此直接判断其中所有链接和交互内容都是安全的。
尤其需要警惕项目中出现的“点击完成配置”“点击安装依赖”“一键初始化开发环境”等操作。
对于经常下载、审计或分析陌生代码仓库的开发人员，可以考虑进一步限制VS Code中的链接点击能力。
可在用户设置中加入：
网站资讯
渠道合作
解决方案
更多服务"editor.links": false
关闭该选项后，VS Code源码编辑器将不再按照默认方式自动识别并提供可点击链接能力，从而降低通过编辑器链接诱导用户触发恶意命令的风险。
不过，该措施主要针对此次披露攻击路径中的特定触发环节，并不能替代完整的终端安全和开发环境安全措施。
针对VS Code等高度可扩展的开发工具，企业安全管理不应只关注代码仓库本身，还需要将IDE插件和扩展纳入软件供应链安全体系。
企业可以重点加强扩展来源管理，对开发环境允许安装的插件建立白名单或审批机制，并限制未经审核的VSIX文件直接安装。
同时，应定期检查开发终端中的已安装扩展，对来源未知、长期未使用或权限异常的扩展及时清理。
对于能够访问生产环境、代码签名系统、核心代码仓库以及云平台的开发人员，还应进一步落实最小权限原则，减少长期有效凭据直接保存在开发终端中的情况。
此外，SSH密钥、API Token、云平台Access Key以及CI/CD凭据应尽量采用分级授权、定期轮换和访问审计机制。
此次攻击方式再次说明，开发工具本身正在成为供应链攻击的重要入口。
对于来源未知的Git仓库，即使只是查看代码，也应谨慎处理其中出现的链接、脚本、任务配置以及扩展安装提示。
开发人员尤其不要因为VS Code显示“受限模式”就默认当前环境绝对安全。对于陌生项目中的链接，应先确认实际目标和执行行为，再决定是否打开。
企业则应从代码仓库、IDE扩展、开发凭据和终端权限等多个层面建立防护措施，避免一次简单的点击操作最终演变为开发终端失陷乃至更大范围的软件供应链安全事件。
