Checkmarx 与 Bitwarden 被卷入 Trivy 攻击链：安全工具正在变成凭据跳板

3 月 19 日，漏洞扫描器 Trivy 被攻破。攻击者控制其 GitHub 账号，并向用户推送恶意软件。

4 天后，Checkmarx 发现自己受影响。到 4 月 22 日，Checkmarx 的 GitHub 账号再次出现恶意发布，官方 Checkmarx/kics Docker Hub 仓库也被 Socket 点名出现恶意包。随后，又出现疑似由 Lapsu$ 泄露的 Checkmarx 私有数据。

这件事最反常的地方在这里：被利用的不是边缘小工具，而是安全工具的发布渠道。攻击者把安全产品同时当成目标和交付机制。它们靠近代码仓库、CI/CD、容器镜像和凭据环境，一旦失守，后面牵出的就不是一台机器，而是一串开发与供应链入口。

攻击链怎么从 Trivy 传到 Checkmarx 和 Bitwarden

按目前公开信息，这条链路不是孤立的单点事故，而是一次供应链攻击的传导。

Checkmarx 的说法里有一个细节需要谨慎处理：原文引文中的日期存在上下文异常。按整条时间线看，更稳妥的理解是，它指向本轮 3 月以来的事件关联，而不是单独确认另一个年份的事件。

Bitwarden 这边，Socket 将其事件与同一 Trivy 攻击活动关联。依据是相同的 C2 端点和核心基础设施。

这只能说明基础设施和攻击活动存在重合线索。它不能直接证明 Bitwarden 客户已经发生大范围二次入侵。对企业安全团队来说，这个边界很重要：该紧张，但不能把未经证实的风险写成既成事实。

攻击者为什么盯上安全工具

恶意载荷的目标很直接：搜寻仓库 token、SSH key 和其他凭据。

这类东西比单台机器更值钱。拿到一台机器，攻击者还要横向移动；拿到仓库 token 或 CI/CD secret，可能直接进入代码仓库、构建系统、容器仓库，甚至云环境。

安全工具的位置又很特殊。它们通常被企业主动接入核心开发流程，权限比普通业务软件更靠近“门闩”。这也是攻击者愿意花力气打它们的原因。

和普通开源包投毒相比，攻击安全工具有几个更划算的点：

SolarWinds 事件早就说明过一个问题：可信更新机制一旦被滥用，攻击者不用逐个敲客户大门。近年的 npm、PyPI 包投毒也反复证明，开发者生态对安装源和自动化流程仍然高度信任。

这次的差别在于，Trivy、Checkmarx、Bitwarden 都贴近安全和开发流程。它们不是普通入口，而是很多企业用来“看门”的工具。门锁被拿来送包裹，风险自然放大。

企业现在该做什么，哪些结论还不能下

原文将 Trivy 攻击归于 TeamPCP。这个组织被描述为访问经纪人，模式是窃取凭据后转售访问权。

在 Checkmarx 事件中，TeamPCP 疑似将凭据访问权卖给 Lapsu$。Lapsu$ 与后续数据泄露相关，但目前信息不能把 Lapsu$ 写成 Trivy 的初始攻击者。

对企业安全负责人和 DevSecOps 团队，最现实的动作不是马上替换所有安全工具。更可行的是先把受影响窗口压住，把凭据风险清掉。

这里有一个现实约束：很多企业并不知道安全工具到底拿了多少权限。工具接入时是为了省事，出事后才发现 token、secret、构建权限散在不同平台里。

所以这次排查要盯三类记录：代码仓库访问、镜像发布与拉取、CI/CD 任务触发。只看终端告警不够，因为攻击目标本来就可能是凭据。

接下来最该观察三件事。

一是 Checkmarx 是否披露泄露数据类型和范围。没有这些信息，就不能判断客户和合作方的真实暴露面。

二是 Socket 或其他研究团队是否确认更多共享基础设施。相同 C2 和核心基础设施是强线索，但还需要更多样本来确认波及面。

三是下游是否出现可归因的二次攻击。只有出现可验证的客户侧事件，才能把“可能扩散”升级为“已经扩散”。

这也是本文的主线：安全工具现在不只是被保护对象，也可能变成攻击交付渠道和访问权商品。对企业来说，信任供应商不等于放弃验证发布链。这个成本，以后很难省。