2026-05-07 05:22:53 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： Checkmarx公司遭遇供应链攻击导致GitHub核心数据泄露，攻击者通过篡改GitHubActions工作流和VSCode插件植入凭证窃取器，进而污染KICSDocker镜像并引发Bitwarden等下游组件级联感染。事件揭示CI/CD流水线安全脆弱性，建议开发者严格遵循最小权限原则、锁定Actions版本并实施依赖项扫描机制。 综合评分： 85 文章分类： 供应链安全,漏洞预警,安全运营,WEB安全,解决方案

cover_image

警惕！KICS Docker镜像、VS Code插件被接连投毒，这场攻击到底是怎么打的？

原创

Hankzheng Hankzheng

技术修道场

2026年5月6日 08:04 广东

在小说阅读器读本章

去阅读

最近安全圈和开发圈可谓是出了个“惊天大瓜”。著名的以色列应用安全测试公司 Checkmarx 自己家后院起火了——他们确认其 GitHub 仓库的数据被黑客打包放到了暗网上售卖。

今天，我不打算只给大家报个新闻。作为技术人，咱们遇到这种级别的安全事件，一定要有“打破砂锅问到底”的极客精神。今天我就带大家从技术的视角，抽丝剥茧，扒一扒这场堪称“教科书级”的连环供应链攻击究竟是怎么打穿 Checkmarx 防线的。

🚨 暗网惊现核心资产，谁干的？

整件事的导火索是这两天在社交平台 X 上，有人爆出臭名远扬的网络犯罪团伙 LAPSUS$ 在其数据泄露网站上挂出了 Checkmarx 的数据。

这批数据有多致命？根据挂出来的清单，里面包含了：

源代码 (Source Code)
员工数据库 (Employee Database)
API 密钥 (API Keys)
MongoDB / MySQL 数据库凭证 (Credentials)

对于一家做代码安全扫描起家的公司来说，源码和密钥被端了，这无疑是被人在心窝子上捅了一刀。Checkmarx 官方随后证实，这些数据确实源自他们的 GitHub 仓库，而攻击的源头，可以追溯到 2026 年 3 月 23 日的一场初始供应链攻击。

🕷️ 抽丝剥茧：这场供应链攻击的技术路径

很多人可能会纳闷，Checkmarx 这种体量的安全公司，防御体系应该很完善，怎么会被人把 GitHub 连底裤都扒了？这就是供应链攻击的可怕之处——它不正面刚你的防火墙，而是通过你信任的第三方依赖、自动化流水线（CI/CD）给你“投毒”。

第一阶段：Trivy 供应链“投毒”与凭证收割

上个月末，一个名为 TeamPCP 的威胁组织发起了第一波攻势（Trivy 供应链攻击）。他们并没有直接攻击 Checkmarx 的核心服务器，而是极其狡猾地篡改了：

两个 GitHub Actions workflows（工作流）
通过 Open VSX 市场分发的两个插件

技术难点与实现原理： 黑客在这些工作流和插件中注入了凭证窃取器 (Credential Stealer)。大家平时写 CI/CD 脚本都知道，为了实现自动化部署，我们通常会在 GitHub Secrets 里存大量的高权限 Token、云服务密钥等。黑客通过篡改工作流的 YAML 文件或植入恶意构建脚本，在运行时悄悄读取环境变量，将这些开发者级别的机密凭证直接外发（Exfiltration）到了黑客自己的服务器上。

划重点：

正是这一波“凭证收割”，极大概率让黑客拿到了 Checkmarx GitHub 仓库的直接访问权限，为后续的数据泄露埋下了伏笔。

第二阶段：连环“套娃”，从 KICS 到 Bitwarden

到了上周，这帮黑客（疑似同一出于经济动机的团伙）利用已经获取的权限，开始在 Checkmarx 的生态里“疯狂横向移动”。他们接连攻破了：

Checkmarx 自家的 KICS Docker 镜像
两个 VS Code 扩展插件
另一个 GitHub Actions 工作流

这些基础设施同样被植入了类似窃取凭证的恶意软件。最恐怖的是，这种污染产生了级联效应 (Cascading Impact)。因为很多下游项目都在使用这些镜像和插件，最终导致著名的密码管理器包 Bitwarden CLI npm package 也遭遇了短暂的妥协（Compromise）。

这就是典型的“套娃式”供应链攻击：攻破一个节点 -> 窃取凭证 -> 污染上游镜像/组件 -> 感染下游无数开发者。

🛡️ 官方回应与补救措施

针对这次严重的事故，Checkmarx 官方也给出了定调和补救措施。他们强调了非常关键的一点：被攻破的 GitHub 仓库与客户的生产环境是完全物理/逻辑隔离的，该仓库中没有存储任何客户数据。

目前，他们已经紧急封锁了受影响的 GitHub 仓库访问权限，并正在配合取证团队核查被发布数据的真实性质和范围。官方承诺，一旦发现客户信息牵涉其中，将第一时间通知各方。

💡 给咱们开发者的几点硬核启示

吃完这个瓜，作为 IT 人，咱们绝不能只看热闹。CI/CD 和供应链安全现在已经是整个行业最脆弱的一环。结合这次事件，我建议大家回去马上检查以下几点：

收敛 GitHub Secrets 权限：

严格遵循最小权限原则（PoLP）。不要给 CI/CD 赋予不需要的全局写权限，定期轮换 API Keys 和数据库密码。
锁定 GitHub Actions 版本：

别再直接用 @master 或 @v2 引用第三方 Action 了！老老实实将其绑定到特定的 Commit SHA 值（例如 @a1b2c3d），防止第三方仓库被篡改后直接执行恶意代码。
防范镜像与依赖投毒：

引入依赖项扫描机制。对于核心业务，Docker 镜像和 npm 包在使用前务必进行签名校验和漏洞扫描。

连安全大厂都能在供应链上栽跟头，咱们平时写代码、配流水线时可得多长点心了。毕竟在这个“到处都是引用的开源时代”，你永远不知道你 npm install 或者 docker pull 下来的东西，里面到底藏着什么猫腻。

各位老铁，你们平时在公司是如何防范 CI/CD 供应链攻击的？有没有踩过类似的坑？欢迎在评论区和我交流探讨！咱们技术人就是要多交流，才能少踩坑。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng Hankzheng《警惕！KICS Docker镜像、VS Code插件被接连投毒，这场攻击到底是怎么打的？》