你以为构建依赖锁了版本就安全了？今天 LiteLLM 用 40 分钟证明 CI/CD 的软肋根本不在你盯的那个环节

你以为构建依赖锁了版本就安全了？今天 LiteLLM 用 40 分钟证明了一件事——CI/CD 的软肋根本不在你盯的那个环节。

8 月 11 日，开源 LLM 网关工具 LiteLLM 的构建管道被污染，两个恶意版本（1.82.7 / 1.82.8）被推送至 PyPI，在线约 40 分钟后被下架。这 40 分钟里，恶意代码传播至 2500+ 个组织、434,000 条 CI/CD 管道运行。Nvidia、AWS、Samsung、Salesforce、Cisco、ServiceNow、Accenture Federal 等主要企业均在潜在暴露名单内。

这起事件的根子不在 LiteLLM 本身，而在一个看似无辜的上游工具——Trivy。

Trivy 是 Aqua Security 开发的开源容器和依赖漏洞扫描器。LiteLLM 的 CI/CD 构建流程集成 Trivy 做安全扫描，但构建环境没有对 Trivy 做严格版本锁定，安装的是最新版。TeamPCP 攻击者组织没有直接攻击 LiteLLM，而是先入侵了 Trivy 的发布流程，将恶意版本推进了 Trivy 的发布体系。LiteLLM 构建时自动装了被污染的 Trivy，进而污染了 LiteLLM 的构建和发布过程。

恶意 LiteLLM 包含有一个 Python 启动文件（.pth 扩展名），设计为在 Python 初始化时自动执行，无需等待 LiteLLM 被显式 import 就已激活。这个 payload 被命名为 SANDCLOCK，激活后立即在运行环境中全面搜刮凭证：云密钥、仓库令牌、SSH 密钥、Kubernetes 令牌、环境变量，以及 LLM API 密钥和 AI 服务网关配置。在 CI/CD 运行器环境中，SANDCLOCK 还尝试获取进程内存（/proc/<pid>/mem）中的敏感数据。被盗数据在发送前加密，或作为备选手段直接在受害者 GitHub 账户中创建公开仓库并上传为 release 资产——让数据外泄看起来像是受害者自己上传的。

虽然恶意包只存在了约 40 分钟，但 SANDCLOCK 的传播速度极快。CloudSEK 的重建数据显示 434,000 条 CI/CD 管道运行存在潜在暴露，2500+ 组织受影响。

为什么 LiteLLM 的构建系统没有锁 Trivy 版本？这恰恰是供应链攻击的典型路径——不正面攻击目标，而是攻击目标信任的上游工具链。LiteLLM 信任 Trivy 的发布体系，Trivy 被污染后，这个信任链把恶意代码直接送进了 LiteLLM 的构建管道。

这种模式并非孤例：tj-actions/changed-files、Nx、trivy-action 都曾因上游被入侵而导致下游受害。而 actions/checkout v7（2026 年 6 月 18 日 GA，7 月 16 日回溯至所有主要版本）防护的是 pull_request_target 工作流中恶意 fork 代码执行的问题——与本次攻击路径不同，不能互相替代。

AI 基础设施正在成为供应链攻击的首选目标，原因很直接：AI 系统深度连接着企业的数据、凭证、计算资源和自主操作。控制了 AI 控制点（如 LiteLLM 这类 LLM 网关），攻击者就能以单一入侵点辐射到周围的身份和系统。而且凭证rotation的窗口期远超恶意包下架的时间——缓存层、短暂运行器、依赖解析器的传播速度让受影响的时间跨度远大于 40 分钟。

如果你的 CI/CD 管道用到了 LiteLLM，现在立即做三件事：第一，检查是否装了 1.82.7 或 1.82.8 版本，隔离相关运行器和容器镜像，从可信来源重建环境；第二，假设所有可被 LiteLLM 库访问的凭证已泄露，立刻旋转云密钥、仓库令牌、SSH 密钥、Kubernetes 令牌和所有 LLM API 密钥，包括存储在进程内存中或通过实例元数据服务可检索的凭证；第三，开始重新审视构建依赖链——不仅是 LiteLLM，所有在构建流程中调用外部工具的服务都需要做同样的审计。

一个具体的落地方向：把 Trivy 换成固定 SHA 版本的 release（比如 aquasec/trivy-action@<commit-sha>），Dependabot 配置好自动更新，同时开启 GitHub Actions 的依赖图审计。如果构建管道里跑了 Docker 镜像，同样要锁镜像标签到 digest 而不是 tag。

这起事件没有涉及零日漏洞，也没有高深的绕过技术——根子就在”构建依赖链里信任了一个没有严格锁版本的上游扫描器”。而这恰恰是大多数团队没有意识到的 CI/CD 盲区。