软件供应链安全
LiteLLM 事件里的 CI/CD 供应链风险
图｜Cyber Security News 对 LiteLLM 供应链攻击事件的报道 图源：Cyber Security News
一次短窗口事件的影响面
近期，LiteLLM 供应链事件让软件供应链安全又被重新拉回视野。公开信息显示，受影响的 PyPI 版本为 1.82.7 和 1.82.8，发布时间在 2026 年 3 月 24 日，恶意包短暂存在约 40 分钟。官方随后删除受影响版本，并说明使用官方 Docker 镜像、LiteLLM Cloud，或没有在窗口期升级到相关版本的用户不受影响。
如果只看这些处置动作，这像一件已经结束的事。但后续研究把问题放大了：潜在影响面可能涉及 2500+ 组织、434000 条 CI/CD pipeline。
这个数字不必被理解成最终受害名单。更准确地说，它提醒我们：一次依赖污染投毒，可能顺着自动化发布链路进入更多环境。
图｜LiteLLM 官方安全更新页面 图源：LiteLLM
依赖如何进入自动化流程
过去，很多团队习惯把开源依赖当成开发侧问题：锁版本、做扫描、发通报、等整改。
现在的问题是，依赖包可能被 CI 机器人自动拉取，也可能被镜像构建缓存，还可能被 AI 网关、模型服务、内部工具同时使用。安全团队看到告警时，包可能已不存在于当前环境，但曾经执行过的 runner、构建镜像、临时 token 和云凭据仍然要排查。
这类事件的麻烦，不在于漏洞本身有多新，而在于信任路径太长。开发者信任包管理器，CI/CD 信任 lockfile 和缓存，生产发布信任构建结果，AI 应用再信任网关转发模型调用。
任何一环把恶意依赖当成正常更新，后面都不会再问一次：它该不该进来？
版本修复之外的排查工作
LiteLLM 官方给出的安全边界很清楚：受影响版本集中在两个 PyPI release，部分安装方式不受影响。但企业内部排查不能只问当前是不是安全版本。
图｜LiteLLM 官方披露的 IoC 指标表 图源：FreeBuf
实际排查时，顺序可以更朴素一点：
先看依赖历史：3 月 24 日前后，是否拉取、安装、缓存或构建过 1.82.7 / 1.82.8。 再看执行位置：开发者工位、CI runner、镜像构建节点、AI 服务网关是否运行过相关包。 然后看凭据影响：云密钥、Git token、Kubernetes secret、模型 API key 是否在同一环境可读。 最后看后续行为：旧镜像、构建日志、异常外联、token 使用记录是否出现异常。
真正的闭环，是把“有没有装过”推进到“装过之后能碰到什么、有没有被用过”。
从事件通报到内部复盘
这类事件真正考验的，不是安全团队会不会转发一条通报，而是能不能在半天内把影响面说清楚。
第一反应通常是查版本：有没有项目装过 1.82.7 或 1.82.8。这个动作必要，但不够。因为很多包并不只存在于代码仓库里，它可能被装在开发者本机，也可能被 CI runner 拉过一次，还可能留在旧镜像、缓存目录或临时构建环境里。
下一步要看它经过了哪些自动化链路。谁触发了构建，哪条流水线拉取过依赖，构建环境里能不能读到 Git token、云密钥、Kubernetes secret 或模型 API key。供应链事件的影响面，往往不是由包本身决定，而是由它落地时拿到的权限决定。
再往后，才是防护能力的复盘。私有仓库有没有挡住，SCA 有没有报出来，流水线扫描有没有截停，SOC 有没有看到异常外联或异常凭据使用。如果这些问题只能靠人工逐项追，说明供应链安全还停在事后排查阶段。
这背后其实对应三类能力：情报要先把恶意包、可疑版本、关联仓库和 IoC 沉淀下来；制品进入企业流程前要有准入判断；防护动作做完后，还要能用验证场景确认它是否真的生效。塞讯的威胁情报、软件供应链防投毒网关和安全验证平台，放在这里更像一条工作链路，而不是三个孤立产品。
这样写，不是为了把产品摆在事件后面，而是为了回答一个更具体的问题：下一次恶意包只出现几十分钟时，你的流程能不能在它进入内网前做出判断？
供应链治理需要前置
LiteLLM 事件不该只被当作 AI 工具安全新闻。它更像一次工具链演练：当 AI 基础组件、开源依赖、CI/CD、云凭据和模型服务连在一起，供应链风险会比过去更快穿透组织边界。
一个比较现实的判断是：未来供应链安全的重点，不只是“有没有恶意包”，而是“恶意包能不能进来、进来后能走到哪里、出现问题后能不能用数据验证影响面”。
如果你们最近也在梳理 AI 工具链和 CI/CD 凭据边界，可以先从一件事开始：把依赖准入、历史构建、凭据轮换和流水线验证放到同一张检查表里。
参考来源：LiteLLM 官方安全更新、CybersecurityNews、SecurityWeek、CloudSEK 公开研究。
