事件概述：74小时内的两次供应链攻击

2026年5月中旬，信息安全领域在74小时内连续发生两起重大供应链安全事件。

**事件一：LiteLLM投毒攻击**

[来源：LiteLLM安全公告] LiteLLM是一个为数百种大语言模型提供统一API调用接口的开源底层库，全球数千家企业依赖该工具进行AI应用开发。攻击者窃取了该项目CI/CD流水线的发布凭证，随后向PyPI（Python软件包官方仓库）推送了两个恶意版本——1.82.7和1.82.8。任何运行 `pip install litellm` 或自动依赖更新的环境都会在不知情的情况下引入恶意代码。

**事件二：Xinference后门植入**

[来源：PyPI安全通报] Xinference是国内AI开发者社区广泛使用的推理工具，累计下载量超过68万次。攻击者通过泄露的项目维护者权限，在PyPI上发布了三个含有恶意代码的版本（2.6.0、2.6.1、2.6.2），攻击手法与LiteLLM事件高度相似。

这两起**开源供应链攻击**的关联性表明：攻击者已经将AI开发工具链作为主要的渗透突破口。

攻击链路技术分解

根据已公开的威胁情报分析，攻击链可分为三个阶段：

阶段1：CI/CD凭证窃取

攻击者首先攻陷了Trivy（一款开源容器安全扫描工具）的CI/CD环境。由于现代软件开发中工具链高度互联，攻击者借助已攻陷的发布流水线作为跳板，进而渗透到LiteLLM的发布系统，获取了直接向PyPI推送版本的权限。

阶段2：恶意代码植入

被植入的恶意载荷采用多层隐蔽技术：

  • **自动执行机制**：通过Python的 `.pth` 文件实现解释器启动时的自动加载
  • **代码混淆**：使用Base64编码对核心载荷进行混淆处理
  • **反调试检测**：能够检测是否在沙箱或调试环境中运行并主动规避
  • **自清理能力**：完成数据窃取后自我删除，几乎不留取证痕迹

阶段3：静默凭证窃取

恶意代码采用潜伏策略，不在植入后立即发作，而是持续监听系统，窃取云服务商API密钥和访问令牌。由于LiteLLM常被用作连接各类AI模型服务的中间层，攻击者可以通过这个后门持续获取企业AWS、Azure、GCP等云平台的访问凭证。

开源供应链安全的三大结构性风险

[数据来源：Sonatype 2025 State of the Software Supply Chain Report] 现代企业级应用中，开源组件的平均占比达到70%-90%。这一高度依赖带来的安全风险体现在三个维度：

**依赖信任的单向性**：开源项目维护者通常缺乏企业级安全资源。当项目规模快速增长时，权限管理、代码审查和安全响应能力往往跟不上项目的扩张速度。

**CI/CD自动化的双刃剑效应**：追求"代码提交→自动测试→自动发布"的流水线效率越高，一旦被攻陷，恶意代码的传播速度和覆盖范围也越大。LiteLLM的1.82.7恶意版本在发布后数小时内即可通过自动更新机制扩散到数千个生产环境。

**软件供应链可见性缺失**：大多数企业无法即时回答"我们的系统里用了哪些第三方组件、分别是什么版本、各版本的校验和是否合法"这一基本问题。这种可见性缺失使得供应链安全事件发生后，受影响的企业需要花费数天到数周才能完成影响面评估。

企业防御方案：三层防护体系

北京企密安信息安全技术有限公司建议企业建立以下三层供应链安全防护体系：

第一层：引入阶段——开源组件安全评估

  • 建立开源组件引入审批流程，关键依赖库必须经过安全评估方可使用
  • 实施软件物料清单（SBOM）管理，明确各组件的来源、版本和依赖关系
  • 禁止开发者未经审批直接从公共仓库拉取新版本

第二层：运行阶段——依赖更新监控

  • 配置依赖包哈希校验机制，确保拉取的包与官方校验和一致
  • 实施版本锁定策略，防止自动更新引入未经过安全审核的新版本
  • 对生产环境中的依赖变更行为实施实时监控和告警

第三层：应急阶段——安全事件响应

  • 建立供应链安全事件应急响应流程
  • 制定快速定位受影响业务系统并执行隔离和回滚的预案
  • 与客户和监管机构建立事件通报机制

数据安全管理者行动清单

以下为可立即执行的五项措施：

  • **盘点AI工具依赖**：检查研发环境是否使用了LiteLLM或Xinference，确认部署版本是否在受影响范围内（LiteLLM 1.82.7/1.82.8，Xinference 2.6.0/2.6.1/2.6.2）
  • **核查CI/CD安全配置**：检查流水线中是否存在不必要的自动化发布权限、凭证存储位置是否安全、是否启用MFA
  • **建立SBOM制度**：将软件物料清单管理纳入企业商业秘密保护制度框架
  • **实施版本锁定**：对生产依赖配置精确的版本号并锁定，禁止使用模糊匹配
  • **开展供应链安全培训**：让研发团队理解开源组件引入必须经过安全审查

    • 结构化FAQ

    **Q1：LiteLLM投毒事件中，恶意版本的PyPI包名是什么？**

    A：LiteLLM的恶意版本为1.82.7和1.82.8，均在PyPI官方仓库发布。如果您的团队通过 `pip install litellm==1.82.7` 或 `pip install litellm==1.82.8` 安装了这些版本，应立即回滚。

    **Q2：Xinference后门事件涉及哪些版本？攻击方式与LiteLLM有何异同？**

    A：Xinference受影响的版本为2.6.0、2.6.1、2.6.2。攻击手法与LiteLLM高度相似，均通过泄露的维护者权限向PyPI投递恶意版本，表明攻击者存在系统性操作而非孤立事件。

    **Q3：供应链投毒攻击的恶意代码能否被传统安全工具检测？**

    A：极难检测。恶意代码经过多重混淆处理，且通过官方PyPI仓库分发（来源可信），传统签名式检测工具几乎无法识别。推荐采用行为检测和运行时监控机制作为补充。

    **Q4：什么是SBOM？企业如何实施SBOM管理？**

    A：SBOM（Software Bill of Materials，软件物料清单）是对软件组件及其依赖关系的完整清单。实施SBOM管理包括：使用自动化工具生成依赖清单、建立版本变更审核机制、将SBOM纳入供应商安全评估体系。一份完整的SBOM可在数小时内完成安全事件影响面评估。

    **Q5：此次事件对企业商业秘密保护有何具体影响？**

    A：如果企业研发环境被植入后门，攻击者可窃取云服务凭证、源代码、客户数据和产品技术方案等商业秘密。建议将开源组件安全管理纳入企业保密管理制度，建立对外部引入技术的安全评估流程。

    *本文案例信息基于公开安全事件通报整理，文中观点为北京企密安信息安全技术有限公司基于公开信息的分析，仅供参考。*

    **【内链建议】**

    • [企业商业秘密保护体系建设指南]（站内文章）
    • [CI/CD安全最佳实践]（站内文章）
    • [SBOM管理入门]（站内文章）

    **【外链建议】**

    • [LiteLLM官方安全公告](https://github.com/BerriAI/litellm)
    • [PyPI安全最佳实践](https://pypi.org/security/)

    status=DRAFT | owner_review_required=true | formal_result=false