LitellM供应链投毒实战复盘：40分钟击穿43\.4万CI/CD流水线 检测与防御全方案

前言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本次攻击是典型的三级级联供应链攻击区别于单一包投毒攻击从底层安全工具渗透逐层向上劫持信任链路复杂度远超常规供应链攻击。攻陷官方渠道自动更新扩散环境窃取伪造官方身份40分钟公开窗口恶意载荷执行持久化留存攻击者TeamPCPTrivy安全工具投毒LitellM官方CI/CD RunnerPyPI官方发布TokenPyPI上架恶意LitellM包全球企业CI/CD流水线拉取依赖流水线凭证、密钥批量泄露企业长期权限失守风险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-Elitellm# 检索全局依赖锁文件find.-typef\(-namerequirements.txt-o-namerequirements-lock.txt-o-namepoetry.lock-o-namepyproject.toml\)-execgrep-lE1\.82\.7|1\.82\.8{}\;echo 自查结束 echo若上方输出存在对应版本证明环境已暴露需立即执行应急处置5.2 批量仓库全局检索脚本适配企业代码仓库批量扫描排查所有项目的依赖文件避免遗漏间接依赖#!/bin/bash# 批量扫描当前目录下所有代码仓库的恶意LitellM版本TARGET_VER1.82.7|1.82.8FILE_LIST(requirements.txtrequirements-lock.txtpoetry.lockpyproject.tomlPipfile.lock)forfilein${FILE_LIST[]};dofind.-name$file|xargsgrep-lE$TARGET_VERlitellm_risk_scan_result.txtdoneecho扫描完成结果已保存至 litellm_risk_scan_result.txtecho风险文件数量$(wc-llitellm_risk_scan_result.txt)5.3 CI流水线日志自查方法重点筛查2026年3月24日 UTC 08:30-09:10时间段的所有构建日志检索是否存在LitellM版本安装记录# GitLab CI 日志检索grep-rlitellm1.82.7\|litellm1.82.8/var/log/gitlab-ci/# Jenkins 日志检索grep-rlitellm1.82.7\|litellm1.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小时自动轮转禁用永久TokenRunner环境启用资源隔离、权限降级禁止root权限运行构建任务构建缓存定时清空禁止长期留存依赖缓存、镜像缓存8.3 新增异常监测规则在主机安全、流水线审计平台新增监测策略监控Python环境.pth文件的新增、修改、写入行为一旦出现非人工操作的变更立刻触发告警并阻断构建任务。8.4 凭证常态化轮转机制建立企业凭证生命周期管理制度云密钥、Git Token、API密钥按月自动轮转核心生产凭证按周轮转留存轮转日志杜绝永久有效凭证。8.5 依赖安全常态化扫描将供应链安全扫描纳入CI门禁构建前强制检测恶意版本、高危依赖、间接投毒风险扫描不通过直接阻断构建发布。9. 事件终极复盘与行业前瞻性思考LitellM本次40分钟极速投毒事件标志着软件供应链攻击进入全新阶段。以往攻击者主攻外网入口、业务漏洞现在攻击重心全面下沉至底层工具链、依赖生态、自动化流水线。AI行业的快速迭代让企业对开源依赖的依赖度达到顶峰。绝大多数AI业务从零搭建完全依托开源网关、开源模型、开源框架供应链节点极多、链路极长任何一个上游节点沦陷都会引发全域风险。更关键的是这类攻击的隐蔽性会持续升级。后续攻击者会持续利用.pth、环境变量、缓存劫持等隐形机制制作后门规避常规安全扫描短暂投毒窗口、静默数据窃取、长期权限驻留会成为供应链攻击的主流模式。企业传统的边界防御、漏洞扫描、病毒查杀体系已经完全无法适配新型供应链风险。安全防护必须从“事后应急”转向“事前信任校验、事中实时监测、事后闭环溯源”彻底打破对开源工具、第三方依赖的无条件信任。互动讨论1. 你的企业CI流水线是否还在使用 latest 动态版本的安全扫描工具、第三方Action2. 你在日常运维中是否遇到过Python依赖间接投毒、隐性后门的安全风险欢迎在评论区分享你的排查和加固经验。