Checkmarx遭供应链攻击：恶意Docker镜像与VS Code扩展被植入
引言：知名安全厂商自身遭遇供应链攻击
在网络安全领域，供应链攻击已成为最具威胁性的攻击手段之一。近日，一起针对知名应用安全公司Checkmarx的供应链攻击事件引发业界广泛关注——攻击者成功将恶意镜像推送至Checkmarx官方的「checkmarx/kics」Docker Hub仓库，同时还涉及恶意VS Code扩展的传播。这一事件再次敲响了软件供应链安全的警钟。
核心事件：官方仓库标签被恶意覆盖
据软件供应链安全公司Socket今日发布的安全警报，未知威胁行为者成功入侵了Checkmarx旗下开源项目KICS（Keeping Infrastructure as Code Secure）的Docker Hub官方仓库。攻击者采取了极为隐蔽的策略：
- 覆盖已有标签：攻击者覆盖了包括「v2.1.20」和「alpine」在内的已有镜像标签，将合法镜像替换为包含恶意代码的版本
- 伪造新版本：引入了一个全新的「v2.1.21」标签，而该版本并不对应任何官方发布的正式版本
- 利用信任链：由于这些镜像托管在Checkmarx的官方Docker Hub仓库中，开发者在拉取时通常不会产生怀疑
与此同时，攻击还波及到了VS Code扩展市场。恶意的VS Code扩展被植入后，可能影响大量使用KICS进行基础设施即代码安全扫描的开发人员。这些扩展一旦被安装，攻击者便可在开发者的本地环境中执行恶意操作，包括窃取凭证、注入后门代码或进一步横向渗透。
深度分析：供应链攻击为何屡屡得手
攻击手法的精妙之处
此次攻击的高明之处在于，攻击者并非创建一个仿冒的新仓库，而是直接篡改了官方仓库中的已有内容。这意味着那些通过自动化CI/CD管道拉取「latest」或特定版本标签的团队，可能在毫不知情的情况下已经部署了恶意镜像。
覆盖已有标签的策略尤为危险。许多企业在Dockerfile或部署脚本中会固定使用某个版本标签，认为这样可以确保一致性和安全性。然而，与不可变的镜像摘要（digest）不同，Docker标签本质上是可变的指针，攻击者一旦获得推送权限，便可将标签指向完全不同的镜像内容。
安全厂商成为攻击目标的深层逻辑
安全厂商本身成为供应链攻击的目标，这一现象值得深思。Checkmarx作为一家专注于应用安全的企业，其工具被广泛应用于全球众多企业的开发流程中。攻击这类厂商的供应链，攻击者可以实现「一次入侵，多点开花」的效果——通过污染上游工具链，间接渗透到所有下游用户的开发环境中。
KICS作为一款开源的基础设施即代码安全扫描工具，在DevSecOps实践中被广泛采用。使用该工具的团队往往拥有对云基础设施配置的高级访问权限，这使得此次攻击的潜在影响范围极为广泛。
与近期供应链攻击趋势的关联
此次事件并非孤例。近年来，从SolarWinds事件到Codecov漏洞，从npm恶意包到PyPI投毒攻击，供应链攻击的频率和复杂度都在持续攀升。Docker Hub和VS Code扩展市场作为开发者生态的核心基础设施，正日益成为攻击者的重点目标。
应对建议：开发者应立即采取行动
针对此次事件，安全专家建议开发者和企业采取以下措施：
- 立即审查环境：检查是否使用了受影响的KICS Docker镜像版本，特别是「v2.1.20」「alpine」和「v2.1.21」标签
- 使用镜像摘要固定：在生产环境中，应使用不可变的SHA256摘要而非可变标签来引用Docker镜像
- 审计VS Code扩展：检查已安装的VS Code扩展列表，移除任何可疑的KICS相关扩展
- 启用镜像签名验证：采用Docker Content Trust或Sigstore cosign等工具验证镜像的完整性和来源
- 监控CI/CD管道：对自动化构建和部署流程中的依赖变更实施实时监控和告警
展望：软件供应链安全亟需体系化建设
此次Checkmarx供应链攻击事件揭示了一个严峻现实：即便是安全厂商自身，也难以完全免受供应链攻击的威胁。随着AI驱动的开发工具日益普及，开发者对第三方组件和工具的依赖程度不断加深，攻击面也在持续扩大。
未来，软件供应链安全需要从多个层面进行体系化建设。在技术层面，镜像签名、SBOM（软件物料清单）、零信任架构等技术手段需要得到更广泛的采用；在管理层面，企业需要建立完善的供应商安全评估和持续监控机制；在生态层面，Docker Hub、VS Code Marketplace等平台运营方需要加强身份验证和异常检测能力。
正如这次事件所警示的那样，在软件供应链中，信任不应是默认的——它需要被持续验证。