Trivy 供应链攻击：当安全扫描器成为武器

Trivy，作为云原生生态系统中最广泛使用的开源漏洞扫描器之一，其核心目标是识别软件供应链中的安全弱点。然而，近期爆发的供应链攻击事件（CVE-2026-33634）揭示了一个令人警醒的现实：当旨在保护软件供应链的安全工具本身被武器化时，其所产生的级联效应可能远超预期，将数千个下游组织暴露在严重风险之中。

Trivy: 供应链安全基石

Aqua Security开发的Trivy是一款功能全面且易于使用的安全扫描工具，致力于帮助开发者和运维人员发现并修复各种环境中的安全问题。 它能够扫描多种目标，包括容器镜像、文件系统、Git仓库、虚拟机镜像、Kubernetes集群以及AWS等云环境。 Trivy的检测能力涵盖已知漏洞（CVE）、基础设施即代码（IaC）配置错误、敏感信息泄露以及软件许可证问题。 其设计初衷是快速且准确地融入CI/CD流程，为软件开发生命周期的早期阶段提供安全保障。

一个典型的Trivy镜像扫描命令示例如下：

trivy image nginx:1.21

此命令将扫描nginx:1.21镜像中的操作系统包和应用程序依赖项中的漏洞。 此外，Trivy也支持扫描配置文件以发现潜在的错误配置：

trivy config --format json .

这将以JSON格式输出当前目录下配置文件的扫描结果。

TeamPCP 供应链攻击：Trivy 被武器化始末 (CVE-2026-33634)

2026年2月下旬至3月，名为TeamPCP（也被追踪为DeadCatx3、PCPcat、ShellForce和CipherForce）的威胁组织发起了一场多阶段供应链攻击，成功地将Trivy这一受信任的安全工具转变为窃取凭证的武器。 该事件被分配了CVE-2026-33634，CVSS评分为9.4，凸显了其高危影响。

初始入侵与凭证窃取

攻击始于利用Trivy GitHub Actions环境中的一个错误配置，特别是pull_request_target GitHub Actions工作流的滥用。 一份报告指出，一个名为“hackerbot-claw”的AI驱动自主代理在此次攻击中发挥了作用，利用该漏洞窃取了特权Personal Access Token (PAT)和CI/CD密钥。

尽管Aqua Security在2026年3月1日发现并尝试通过凭证轮换来阻止入侵，但轮换操作并未完全彻底，导致攻击者保留了对有效凭证的残余访问权限。 这种不完全的遏制为后续的攻击埋下了伏笔。

Trivy 组件的恶意篡改

2026年3月19日，攻击者利用这些窃取的凭证发布了恶意版本的Trivy v0.69.4二进制文件。 同时，他们对aquasecurity/trivy-action的77个版本标签中的76个，以及aquasecurity/setup-trivy的所有7个标签进行了强制推送（force-push），将其指向恶意提交。 许多CI/CD管道依赖版本标签而非 pinned commits，这意味着这些管道在执行时并未察觉到底层代码已被恶意更改。

被篡改的Trivy二进制文件和GitHub Actions中嵌入了信息窃取恶意软件，能够从构建环境中收集敏感数据。 窃取的数据类型包括：

  • 环境变量
  • 云服务令牌 (AWS, GCP, Azure)
  • SSH密钥
  • Kubernetes令牌
  • Docker注册表凭证
  • 数据库密码
  • TLS私钥
  • 加密货币钱包文件

攻击者采用了复杂的隐蔽手段。恶意代码在正常的Trivy扫描执行之前运行，使得CI/CD管道的输出看起来完全正常，从而掩盖了窃密行为。 窃取的数据使用AES-256-CBC加密，并用RSA-4096包裹，使其难以通过网络层检查被发现。

数据外传与横向扩散

数据外传的初步目标是使用了一个错拼的域名scan.aquasecurtiy[.]org。 作为备用方案，恶意软件还利用受害者的GitHub PAT创建公共存储库（例如tpcp-docs）来暂存数据，从而利用了受信任的基础设施进行数据外传。

此次攻击不仅限于Trivy本身，还表现出强大的横向传播能力：

  • **Docker Hub 镜像：** 恶意Trivy Docker镜像在Docker Hub上被发现，并持续在全球镜像源中扩散。
  • **npm 蠕虫 (CanisterWorm)：** 攻击者利用被盗的npm令牌，部署了一个自传播蠕虫（CanisterWorm），该蠕虫能够利用暴露的SSH密钥、不安全的Docker和Kubernetes API以及受损的npm包，在连接的系统之间进行传播。 恶意npm包的发布使供应链风险从单点跳跃转变为指数级扩散。
  • **其他安全工具：** 攻击活动甚至蔓延到其他安全工具，如Checkmarx GitHub Actions和PyPI上的LiteLLM Python包。 LiteLLM攻击中，恶意软件使用Python .pth文件实现自动执行，无需显式导入，任何Python解释器启动都会触发窃密程序。
  • **区块链C2：** TeamPCP还首次使用了基于Internet Computer Protocol (ICP) 的区块链容器作为死信投递C2（Command and Control）服务器，这使得传统的取证和阻断方法难以奏效。

关键技术细节分析

GitHub Actions `pull_request_target` 误配置

pull_request_target是一个强大的GitHub Actions触发器，它在目标仓库的上下文中运行，并具有对仓库密钥的读写访问权限。如果配置不当，例如允许来自分支的恶意代码在没有适当隔离的情况下运行，攻击者就可以利用此机制窃取凭证。此事件中，攻击者正是利用了这种误配置，窃取了高权限的PAT。

标签投毒 (Tag Poisoning)

攻击者通过强制推送（force-push）对GitHub Actions的版本标签进行篡改，将这些标签重定向到包含恶意代码的提交。 许多CI/CD管道习惯于引用版本标签（如v1.0），而非特定的commit SHA。当攻击者更改了标签指向的commit时，下游用户在拉取该标签时，实际上会获取并执行恶意代码，而不会有任何可见的警告或错误。

例如，一个CI/CD工作流可能会包含以下步骤：

- uses: aquasecurity/[email protected]
  with:
    image-ref: 'my-app:latest'
    format: 'table'

当v0.69.4标签被恶意篡改后，任何运行此工作流的用户都将无意中执行恶意负载。

凭证窃取恶意软件 (Infostealer)

该恶意软件旨在尽可能多地收集构建环境中的敏感信息。它不仅通过dump Runner.Worker进程内存来窃取CI/CD密钥，还会扫描50多个文件系统路径，以获取SSH密钥、云服务凭证（AWS、GCP、Azure）、Kubernetes令牌、Docker注册表凭证、数据库密码和加密货币钱包文件。

以下是一个模拟恶意软件可能尝试扫描凭证的路径的简化示例 (概念性代码，非实际攻击代码)：

#!/bin/bash
# 简化示例：模拟凭证路径扫描
echo "Searching for sensitive files..."
find /root/.ssh /home/*/.ssh /etc/kubernetes/pki ~/.kube ~/.docker/config.json -name "*.pem" -o -name "id_rsa*" -o -name "config.json" -o -name "kubeconfig" 2>/dev/null

收集到的数据经过AES-256和RSA-4096加密后，通过HTTP/HTTPS请求外传到攻击者控制的C2服务器，或者作为备用方案，被推送到攻击者创建的GitHub公共存储库。

影响范围与深远后果

Trivy供应链攻击已导致超过1000个SaaS环境被攻陷，Mandiant警告称，下游受害者数量可能扩大到10,000个。 更令人担忧的是，即使在Docker Hub、GitHub Container Registry等主流平台下架恶意Trivy镜像后，仍有1,283个公共镜像仓库缓存着受污染的版本，其中37%位于亚太地区。

攻击事件还暴露出企业在软件供应链安全实践中的普遍弱点：高达92%的企业采用“拉取-运行”（pull-run）而非“拉取-签名验证-运行”（pull-sign-verify-run）的流程。 这意味着恶意镜像在进入生产环境之前缺乏有效的检测机制，从而加速了恶意代码的泛滥。

此次攻击标志着勒索经济进入了供应链协同时代，Lapsus$等勒索组织也介入其中，将事件升级为双重勒索。 为了应对这一威胁，多家国际评级机构（如MSCI、Sustainalytics）已宣布，从2026年起，将在其ESG评级中新增“开源组件治理成熟度”和“第三方工具供应链审计覆盖率”两项量化指标。 这将促使企业将供应链安全投入从“成本中心”转变为“价值中心”，并倒逼其重构DevSecOps信任模型，将供应链安全纳入ESG硬性披露范畴。

安全防护与启示

Trivy攻击事件是云原生时代软件供应链脆弱性的系统性崩溃，它强调了对CI/CD管道和第三方工具进行深度安全审计的迫切性。

加强 CI/CD 管道安全

鉴于CI/CD管道已成为主要的攻击面，组织必须实施更严格的安全控制。 这包括但不限于：

  • 凭证管理： 采用最小权限原则，确保CI/CD环境中的凭证仅具有所需的最少权限。 定期、彻底地轮换所有凭证，并确保轮换过程的原子性，防止攻击者在轮换过程中保留访问权限。
  • GitHub Actions 硬化： 避免使用容易被滥用的pull_request_target配置，或者在必须使用时，采取严格的沙箱和输入验证措施。
  • 引用固定提交： 在GitHub Actions中，应始终使用commit SHA来引用动作，而不是可变的版本标签，以防止标签投毒攻击。
# 推荐：使用 commit SHA
- uses: aquasecurity/trivy-action@a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
  with:
    image-ref: 'my-app:latest'

# 避免：使用可变标签
# - uses: aquasecurity/[email protected]
#   with:
#     image-ref: 'my-app:latest'

强化软件供应链完整性

仅仅扫描代码中的漏洞是不够的，还需要验证用于构建和部署软件的工具和流程本身的完整性。

  • 软件物料清单 (SBOM)： 生成和验证所有软件组件的SBOM，以便在出现漏洞时快速识别受影响的组件。
  • 签名验证： 实施强制性的签名验证流程，确保只有经过签名的、可信的artifact才能在生产环境中运行。
  • 运行时行为监控： 对CI/CD流水线中的关键安全工具（如Trivy）进行运行时行为监控，及时发现异常活动。

此次Trivy事件是供应链安全领域的一个转折点，它明确表明，攻击者不再仅仅绕过防御，他们正在武器化防御工具。对任何依赖开源项目和CI/CD流程的组织来说，理解并吸取此次攻击的教训至关重要。