前言
2026年3月24日的LitellM投毒事件，彻底打破了很多企业的安全认知盲区。过往团队的安全防护重心，大多放在业务代码漏洞、外网入侵、主机木马这类显性风险上，所有人都默认：合规的开源安全工具、主流公共包管理器的第三方依赖，是绝对可信的。
这次攻击用最直白的结果证明：现代软件供应链的最薄弱点，从来不是自研业务代码，而是自动化流水线依赖的底层工具链。攻击者没有爆破任何企业内网、没有突破任何防火墙、没有挖掘业务漏洞，仅仅利用安全工具Trivy的供应链沦陷，层层劫持上下游信任关系，耗时20天潜伏、40分钟集中爆发，直接污染全球43.4万条CI/CD流水线、2500余家企业的生产构建环境。
更致命的是，绝大多数中招企业在事件曝光前，完全没有感知。恶意载荷不触发常规杀毒告警、不篡改业务代码、仅静默窃取全量密钥凭证，且包下架、版本升级后，泄露的密钥、API凭证、云权限依然永久有效。
本文从攻击底层逻辑出发，用第一性原理拆解完整攻击链路，结合对抗式审查思维复盘防御漏洞，同时提供全套可落地的自查脚本、环境清理方案、流水线加固配置，让开发者和安全运维人员能直接落地整改，彻底规避同类供应链投毒风险。
1. 事件核心基础：读懂LitellM与攻击前置条件
1.1 LitellM项目真实业务定位
LitellM是目前生态最完善的开源AI网关，核心作用是统一封装百余家大模型厂商的接口，包括OpenAI、阿里云通义、百度文心、字节豆包、 Anthropic 等。开发者无需适配各家模型的私有协议，仅通过LitellM统一调用、统一鉴权、统一限流，极大降低了AI业务开发成本。
依托极简的接入方式，LitellM形成了超大的安装体量：月度PyPI下载量突破9500万次。覆盖场景不止是企业生产服务，还包含开发者本地调试环境、个人AI项目、云原生容器流水线、自动化测试平台、开源项目CI构建节点。
这种全覆盖的部署特性，让LitellM成为供应链攻击的最优靶标。一旦投毒成功，恶意代码可以无差别渗透个人开发者、中小企业、头部互联网公司的各类环境，传播效率远超普通业务包。
1.2 企业普遍存在的致命信任误区
绝大多数团队的流水线设计，都存在一个默认信任逻辑：安全工具绝对可信。
本次事件的前置漏洞，不是LitellM本身代码存在漏洞，而是企业CI流水线默认自动拉取最新版Trivy漏洞扫描工具。Trivy作为业界主流的容器、依赖漏洞扫描工具，被所有团队归类为“安全可信组件”，全程不做版本锁定、不做哈希校验、不做执行权限管控。
攻击者正是抓住了这个核心误区。攻陷Trivy官方供应链后，利用LitellM流水线的自动更新机制，让恶意扫描工具长期潜伏在构建环境中，静默窃取核心权限凭证，最终完成上游投毒、下游全覆盖的攻击闭环。
1.3 事件核心数据汇总
攻击组织：TeamPCP
恶意包版本：litellm 1.82.7、1.82.8
恶意载荷代号：SANDCLOCK（沙漏持久化后门）
PyPI恶意包存活窗口：40分钟
影响规模：43.4万条CI/CD流水线、2500+企业组织
泄露数据体量：195TB各类密钥、Token、API凭证
潜伏周期：20天（3月19日-3月24日）
2. 完整攻击时间线与链路架构拆解
2.1 精准时间线（UTC标准时间）
很多复盘文章只记录了3月24日的投毒爆发环节，但真正的攻击核心是前期20天的静默潜伏，这也是多数企业防御体系完全缺失的环节。
3月19日：上游安全工具沦陷
TeamPCP组织攻破Trivy官方发布渠道，推送携带恶意代码的Trivy新版本。全球所有开启自动更新、未锁定Trivy版本的CI/CD流水线，全部自动拉取并执行了恶意程序，其中包含LitellM官方项目的构建流水线。
恶意Trivy程序运行后，主动扫描当前Runner环境内存与文件，精准抓取到LitellM项目维护者的PyPI发布Token。该Token具备包版本上传、更新、推送的最高权限，且长期有效、未配置自动轮转，攻击者直接留存凭证，开启20天潜伏窗口。
3月24日 08:30：正式投毒发布
攻击者利用窃取的合法PyPI Token，伪造官方身份，上传植入SANDCLOCK载荷的litellm 1.82.7、1.82.8两个版本。PyPI平台未触发异常发布风控，恶意包成功公开上架。
3月24日 09:10：紧急下架隔离
安全厂商监测到异常包行为，联动PyPI官方紧急下架恶意版本，封禁违规账号。从上架到下架，恶意包仅存活40分钟。
但全球自动化流水线是7×24小时不间断构建，40分钟的窗口期，足够数十万流水线完成依赖拉取、镜像构建、环境部署，恶意代码完成批量落地。
8月11日：完整攻击链路公开
CloudSEK、Hudson Rock两家安全厂商联合披露本次事件完整复盘报告，公开外泄凭证数据集、攻击技术细节，确认43.4万条流水线存在明确暴露风险。
2.2 攻击链路架构图（Mermaid）
本次攻击是典型的三级级联供应链攻击，区别于单一包投毒，攻击从底层安全工具渗透，逐层向上劫持信任，链路复杂度远超常规供应链攻击。
2.3 攻击核心逻辑（第一性原理拆解）
抛开所有表面现象，本次攻击的底层逻辑只有两点，也是所有供应链攻击的通用核心：
第一，行业默认的信任传递机制无校验。企业信任Trivy这类安全工具，Trivy被投毒后，企业流水线无条件承接风险；LitellM信任自身CI工具链，最终让上游风险直达终端业务环境。信任单向传递，无任何反向校验、无权限隔离、无异常拦截。
第二，自动化机制放大安全风险。人工操作存在审批、核查环节，而CI/CD流水线全自动执行、无人工干预、高频次构建，极短的投毒窗口就能完成全域扩散，风险传播速度呈指数级增长。
3. SANDCLOCK恶意载荷技术深度解析
本次投毒的核心亮点（高危点）是SANDCLOCK载荷的免杀、无感执行机制。它避开了绝大多数常规代码检测、依赖扫描、主机杀毒规则，这也是大量企业无法提前发现入侵的核心原因。
3.1 核心突破点：.pth文件无导入自执行机制
常规Python后门，需要业务代码import对应包才能触发执行，只要开发者不主动引用，后门就无法运行。
SANDCLOCK载荷利用了Python的site-pth持久化机制。攻击者在打包LitellM恶意版本时，植入自定义.pth路径文件。Python环境在启动、加载依赖、初始化路径的全过程中，会自动解析并执行.pth文件内的代码，无需业务代码导入、无需手动调用，只要环境加载Python，后门自动触发。
这是绝大多数安全扫描工具的盲区：常规扫描只检测py、pyc可执行文件，忽略.pth路径配置文件，导致后门完全免杀隐蔽。
3.2 载荷三阶段攻击行为
阶段一：全域凭证搜刮
后门启动后，不会立刻发起网络请求规避检测，而是先静默扫描当前环境所有敏感资源，扫描范围覆盖全场景流水线权限：
系统环境变量：抓取所有密钥、Token、账号密码变量
Proc内存文件：读取运行中进程的内存明文凭证
服务器密钥：SSH私钥、known_hosts认证文件
云原生资源：K8s Secret、ConfigMap敏感配置
研发凭证：GitHub/GitLab个人Token、PyPI发布密钥
AI业务凭证：所有大模型服务商API Key、调用密钥
阶段二：加密数据外渗
载荷完成凭证收集后，会对所有数据进行对称加密处理，规避明文传输检测，再通过HTTPS隧道回传至攻击者管控的恶意域名。整个传输过程遵循正常网络协议，无异常流量特征，流量审计系统无法识别。
阶段三：环境持久化与横向潜伏
数据外渗后，载荷不会自动退出，而是在当前Runner容器、开发者主机、生产节点中完成持久化配置。它会修改Python环境全局路径，保证后续每次Python启动都会重新加载恶意逻辑，同时尝试遍历内网环境，扫描同网段其他流水线节点，实现横向渗透。
3.3 最大认知误区纠正
很多企业的应急操作只做两步：卸载LitellM包、升级至最新安全版本。这是完全无效的补救方式。
恶意代码的核心危害不是本地驻留，而是凭证数据外泄。只要密钥、Token、API Key被窃取，即便彻底删除恶意包，被盗凭证依然具备完整权限，攻击者可随时远程登录、调用接口、操控企业资源。唯一有效的补救方式是全量轮转所有泄露凭证。
4. 精准影响范围判定与场景梳理
43.4万条流水线是潜在暴露总量，并非所有流水线都被成功窃取数据，但只要在攻击窗口期内执行过LitellM依赖安装的环境，全部存在高危风险。本次风险覆盖四类核心场景，包含大量间接中招的隐蔽场景。
4.1 直接风险场景
GitHub Actions、GitLab CI、Jenkins 自动化流水线：3月24日UTC时段自动构建、自动安装litellm依赖的任务
企业生产AI服务：部署了1.82.7、1.82.8版本LitellM网关的线上节点
开发者本地环境：该时间段内手动安装、更新过LitellM的个人开发机
4.2 间接风险场景（最容易被遗漏）
很多业务项目代码中没有直接写入litellm依赖，依然会中招。大量AI上层框架、智能运维工具、LLM应用脚手架，会将LitellM作为二级、三级间接依赖。项目打包构建时，会自动递归安装依赖链中的LitellM恶意版本，全程无感知触发后门执行。
这类间接依赖风险，是企业自查的最大盲区，常规关键词检索无法发现，必须通过锁文件全局检索才能排查。
5. 企业落地级自查方案（完整可复制脚本）
本节提供全套可直接部署的自查脚本，支持单节点自查、批量仓库检索、流水线日志筛查，适配所有Linux、MacOS环境，Windows环境可通过PowerShell适配执行。
5.1 本地环境版本自查脚本
用于检测当前机器、构建节点是否安装过恶意版本LitellM
#!/bin/bashecho"========== LitellM 恶意版本自查开始 =========="# 检测已安装版本pip list|grep-E"litellm"# 检索全局依赖锁文件find.-typef\(-name"requirements.txt"-o-name"requirements-lock.txt"-o-name"poetry.lock"-o-name"pyproject.toml"\)-execgrep-lE"1\.82\.7|1\.82\.8"{}\;echo"========== 自查结束 =========="echo"若上方输出存在对应版本，证明环境已暴露，需立即执行应急处置"5.2 批量仓库全局检索脚本
适配企业代码仓库批量扫描，排查所有项目的依赖文件，避免遗漏间接依赖
#!/bin/bash# 批量扫描当前目录下所有代码仓库的恶意LitellM版本TARGET_VER="1.82.7|1.82.8"FILE_LIST=("requirements.txt""requirements-lock.txt""poetry.lock""pyproject.toml""Pipfile.lock")forfilein"${FILE_LIST[@]}";dofind.-name"$file"|xargsgrep-lE"$TARGET_VER">>litellm_risk_scan_result.txtdoneecho"扫描完成，结果已保存至 litellm_risk_scan_result.txt"echo"风险文件数量：$(wc-l<litellm_risk_scan_result.txt)"5.3 CI流水线日志自查方法
重点筛查2026年3月24日 UTC 08:30-09:10时间段的所有构建日志，检索是否存在LitellM版本安装记录：
# GitLab CI 日志检索grep-r"litellm==1.82.7\|litellm==1.82.8"/var/log/gitlab-ci/# Jenkins 日志检索grep-r"litellm==1.82.7\|litellm==1.82.8"/var/jenkins_home/logs/6. 分级应急处置落地流程
根据自查结果，将风险分为无风险、低风险、高危暴露三级，对应不同处置方案，避免过度操作或处置不全。
6.1 无风险场景
自查脚本无任何恶意版本输出，流水线对应时间段无构建记录、无依赖安装记录。只需执行常规加固，无需密钥轮转。
6.2 低风险场景
仅测试环境、个人开发机安装过恶意版本，无生产凭证、无云权限、无流水线核心Token。处置方式：清理本地依赖、重启环境、更新依赖版本。
6.3 高危场景（生产/流水线命中）
只要CI流水线、生产环境命中恶意版本，必须严格执行以下全流程操作，缺一不可：
第一步：全量轮转所有敏感凭证（最高优先级）
轮转范围包含：云服务商AccessKey、GitHub/GitLab CI Token、PyPI/NPM发布密钥、所有大模型API Key、SSH私钥、K8s集群Secret、数据库账号密码、运维后台凭证。禁止遗漏任何一类权限凭证。
第二步：重建所有受影响构建环境
删除CI Runner所有容器缓存、镜像构建缓存、依赖缓存，销毁旧构建节点，重新初始化全新环境。恶意载荷会驻留缓存文件，仅卸载包无法清除残留风险。
第三步：全量审计权限操作日志
核查所有密钥、Token的登录记录、接口调用记录、资源操作记录，排查是否存在异常外网访问、越权操作、数据外渗行为。留存审计日志用于合规溯源。
第四步：统一升级安全依赖版本
全局卸载恶意版本，锁定LitellM官方稳定安全版本，写入项目依赖锁文件，禁止自动更新。
第五步：流水线组件合规校验
排查所有第三方Action、安全扫描工具、CI依赖组件，取消latest动态版本，全部固定具体版本并配置哈希校验。
7. 对抗式审查：深挖企业防御体系底层漏洞
用对抗思维复盘本次事件，所有中招企业的防御体系，都存在三个共性底层漏洞，也是绝大多数企业供应链安全的通用短板。
7.1 可信组件白名单机制缺失
企业安全策略只防护外部陌生流量、陌生程序，对Trivy、GitHub Action、开源依赖这类“知名工具”默认放行，无任何校验机制。攻击者只需要攻陷一个主流可信工具，就能绕过所有边界防护，实现内网全域渗透。
7.2 CI权限过度授信，无最小权限约束
绝大多数企业的CI/CD Runner配置永久有效Token、全局云权限、集群管控权限。流水线本身只需要构建、打包、推送权限，却被赋予了密钥读取、资源修改、集群操控等超范围权限。一旦流水线被劫持，攻击者直接获取最高业务权限。
7.3 依赖管控机制形同虚设
大量项目使用动态版本依赖、不启用锁文件、不校验包哈希，任由构建环境自动拉取最新版本。公共包管理器的开源包一旦被投毒，企业会无条件自动中招，无任何拦截能力。
7.4 隐蔽文件监测能力空白
现有主机安全、代码扫描工具只检测常规可执行文件，忽略.pth、.cfg、.ini这类配置型文件的执行风险，导致新型持久化后门长期隐身。
8. 企业长期供应链安全加固方案（可落地配置）
8.1 Python依赖强制校验配置
开启pip哈希校验，禁止未校验依赖安装，在全局pip配置中写入强制校验规则：
# 全局开启pip哈希校验pip configsetglobal.require-hashestrue# 锁定依赖版本，禁用动态更新pip configsetglobal.disable-pip-version-checktrue8.2 CI流水线标准化加固规则
所有第三方工具、Action、扫描组件禁止使用latest标签，固定具体迭代版本
所有流水线凭证使用短时临时Token，有效期不超过24小时，自动轮转，禁用永久Token
Runner环境启用资源隔离、权限降级，禁止root权限运行构建任务
构建缓存定时清空，禁止长期留存依赖缓存、镜像缓存
8.3 新增异常监测规则
在主机安全、流水线审计平台新增监测策略：监控Python环境.pth文件的新增、修改、写入行为，一旦出现非人工操作的变更，立刻触发告警并阻断构建任务。
8.4 凭证常态化轮转机制
建立企业凭证生命周期管理制度，云密钥、Git Token、API密钥按月自动轮转，核心生产凭证按周轮转，留存轮转日志，杜绝永久有效凭证。
8.5 依赖安全常态化扫描
将供应链安全扫描纳入CI门禁，构建前强制检测恶意版本、高危依赖、间接投毒风险，扫描不通过直接阻断构建发布。
9. 事件终极复盘与行业前瞻性思考
LitellM本次40分钟极速投毒事件，标志着软件供应链攻击进入全新阶段。以往攻击者主攻外网入口、业务漏洞，现在攻击重心全面下沉至底层工具链、依赖生态、自动化流水线。
AI行业的快速迭代，让企业对开源依赖的依赖度达到顶峰。绝大多数AI业务从零搭建完全依托开源网关、开源模型、开源框架，供应链节点极多、链路极长，任何一个上游节点沦陷，都会引发全域风险。
更关键的是，这类攻击的隐蔽性会持续升级。后续攻击者会持续利用.pth、环境变量、缓存劫持等隐形机制制作后门，规避常规安全扫描，短暂投毒窗口、静默数据窃取、长期权限驻留会成为供应链攻击的主流模式。
企业传统的边界防御、漏洞扫描、病毒查杀体系，已经完全无法适配新型供应链风险。安全防护必须从“事后应急”转向“事前信任校验、事中实时监测、事后闭环溯源”，彻底打破对开源工具、第三方依赖的无条件信任。
互动讨论
1. 你的企业CI流水线是否还在使用 latest 动态版本的安全扫描工具、第三方Action？
2. 你在日常运维中，是否遇到过Python依赖间接投毒、隐性后门的安全风险？欢迎在评论区分享你的排查和加固经验。
 核心原理与实战：从编码乱码到海量数据处理)
