Visual Studio Code 的扩展生态正在成为供应链攻击的焦点战场。2025 年 10 月，安全研究人员发现了首个针对 VS Code 扩展的自我复制蠕虫 GlassWorm，这一里程碑事件标志着攻击者已从单次投毒演进到规模化传播。理解这一攻击演进路径，对于安全团队构建有效的防御体系至关重要。
攻击演进的三阶段模型
VS Code 扩展供应链攻击经历了清晰的演进过程。第一阶段是静态投毒期，攻击者通过上传恶意扩展至 marketplace，利用开发者的信任心理直接感染目标。这一阶段的典型特征是攻击者需要手动推广恶意扩展，受害范围有限。第二阶段是供应链污染期，攻击者开始瞄准扩展开发者，通过盗取发布令牌或入侵开发者账号，实现对合法扩展的恶意更新分发。Wiz 安全团队的研究显示，超过 100 个 VS Code 扩展泄露了访问令牌，攻击者可利用这些令牌直接向全部 15 万安装基础推送恶意更新。第三阶段是自我复制期，以 GlassWorm 为代表的新型恶意软件具备了自动化传播能力，感染后会窃取 NPM 令牌、GitHub 凭证和 OpenVSX 访问令牌，并自动利用这些凭证继续感染更多扩展和包，形成蠕虫式的传播链条。
GlassWorm 的技术解剖
GlassWorm 代表了当前扩展供应链攻击的技术巅峰。它采用了多层隐蔽技术来规避检测，其中最值得关注的是不可见 Unicode 字符注入。恶意代码使用私有使用区（PUA）字符和零宽字符进行编码，这些字符在代码编辑器中完全不可见，即使进行代码审查也几乎无法发现。在命令控制架构上，GlassWorm 摒弃了传统的服务器模式，转而利用 Solana 区块链作为 C2 基础设施。攻击者将载荷 URL 嵌入区块链交易的备忘录字段中，形成了一个去中心化、不可篡改的 C2 网络。这种设计使得传统的 C2 阻断手段完全失效，因为区块链基础设施无法被关闭。作为备份通道，恶意软件还会使用 Google Calendar 的公共事件作为辅助 C2，利用合法基础设施绕过安全监控。
Evelyn Stealer 的多阶段投递链
与 GlassWorm 的传播特性不同，Evelyn Stealer 展示了针对开发者的高精度攻击手法。这是一场精心设计的多阶段投递攻击，第一阶段通过钓鱼或恶意广告诱导开发者安装看似无害的 VS Code 扩展。一旦扩展被激活，恶意代码会释放第二阶段载荷，建立持久化后门。第三阶段开始横向移动，窃取开发者环境中的敏感资产，包括 SSH 密钥、云服务凭证、GitHub 访问令牌以及加密货币相关数据。Trend Micro 的分析指出，开发者工作站通常缺乏生产环境级别的安全监控，却存放着大量高价值凭证，这使得开发者成为绕过生产安全防护的理想突破口。
信任模型的系统性脆弱
VS Code 扩展生态的脆弱性根植于其信任模型的内在缺陷。Marketplace 的 "Verified Publisher" 徽章仅验证域名所有权，并不意味着代码安全性的任何保证。扩展权限模型采用粗粒度的全有或全无策略，开发者安装时必须授予所有声明的权限，无法针对敏感操作进行细粒度控制。扩展更新机制是另一关键风险点：发布令牌被盗取后，攻击者可以无声息地向所有已安装用户推送恶意更新，整个过程不需要用户任何交互。此外，大量扩展开发者习惯将 API 密钥、访问令牌等敏感信息硬编码在扩展包中，而扩展文件本质是 ZIP 压缩包，任何人都可以解压检查这些秘密。
工程化防御清单
面对演进中的威胁，安全团队需要建立多层次的防御体系。在扩展准入环节，应建立企业级扩展白名单，仅允许经过安全审核的扩展安装；使用静态分析工具扫描扩展包的硬编码秘密；监控扩展声明权限与实际行为的差异。在供应链验证环节，发布令牌应存储在专用密钥管理系统中，使用最小权限原则分配；对扩展更新进行代码签名验证；在 CI/CD 流程中集成扩展安全扫描。在运行时监控环节，部署扩展行为审计机制，监控文件操作、网络请求和敏感 API 调用；建立扩展进程的沙箱隔离；定期扫描已安装扩展的权限声明变化。在应急响应环节，准备扩展供应链事件的响应预案；建立与 marketplace 运营方的快速沟通渠道；制定扩展回滚和清除的标准操作流程。
VS Code 扩展供应链攻击的演进揭示了一个核心趋势：攻击者正在利用开发工具生态的信任链条作为突破点。对于安全团队而言，仅关注生产环境已远远不够，需要将安全边界前移至开发者的编辑器环境，构建覆盖工具链全生命周期的防护体系。
资料来源： Veracode 威胁研究报告、The Hacker News 供应链风险报道、Trend Micro 安全分析。