编者按：继去年OneAPI镜像投毒事件后，近日流行的AI模型调用工具LiteLLM在PyPI官方仓库也遭到恶意投毒。这类针对“模型调用总闸门”的攻击为何总能得手？我们又该如何有效防范？
北京时间 3 月 24 日 19 点，PyPI 仓库悄然出现了 LiteLLM 1.82.7 版本。仅仅 13 分钟后，版本号变为 1.82.8。蹊跷的是，这两个版本并未经过 GitHub 上官方仓库的常规 PR 流程，在源码中根本找不到对应的提交记录。随后，第三方安全情报中心监测到这两个版本中混淆了恶意代码。
隐藏在包内的恶意代码就像一个“数字窃贼”，它会扫描并窃取受害系统的各种敏感数据，包括系统环境变量、SSH 密钥、AWS/Azure 等云服务凭据、K8s/Git/Docker/数据库配置、SSL 证书私钥，乃至加密钱包的配置及密钥。所有这些信息被 RSA 加密打包后，悄悄外传到攻击者的服务器。更危险的是，它还会在目标系统中植入脚本后门，并利用系统服务实现持久化驻留，以便长期控制。
LiteLLM 作为一个旨在统一各类大模型 API 调用的 SDK，在 PyPI 上的历史总下载量已超过 4.8 亿次，许多知名的开源项目如 OpenClaw 也深度依赖它。因此，这次投毒事件波及范围极广。
事件发生后，AI 领域的知名人物 Karpathy 在 X 平台上警告：“像这样的供应链攻击基本上是现代软件中最令人恐惧的事情。”马斯克也转发并评论了“Caveat emptor”（买者自负）。这无疑给所有依赖开源生态的开发者敲响了警钟。
为何 PyPI 会成为攻击目标？
要理解这次攻击，我们得先看看 PyPI 的运作机制。PyPI 是 Python 官方的包管理仓库，绝大多数 Python 项目的维护者都会把新版本发布到这里。当企业项目需要依赖某个开源库时，开发者通常会简单地运行 pip install -r requirements.txt，pip 便会自动从 PyPI 拉取所有依赖。
PyPI 官方会对发布包进行格式验证、元数据完整性检查等基础技术审查，并辅以 Token 身份验证和恶意软件扫描。但像代码审计、源码一致性验证这类深度、耗时的检查，则无法完全覆盖。
因此，整个生态的运转建立在多重信任之上：我们相信 PyPI 上的包总体是安全的，相信包维护者不会上传恶意代码，也相信维护者的发布凭证（Token）不会泄露。
然而，正是这种便利性与普及性，使 PyPI 成为了攻击者的“理想靶场”。攻击链条可以非常短：
- 窃取一个有效的 PyPI 发布 Token。
- 向 PyPI 推送一个包含恶意代码的版本。
- 静待全球开发者的自动化流水线或手动安装命令将其下载到生产环境。
而开发者这边几乎难以察觉，因为：
pip install 过程高度自动化，很少有人会去逐个检查安装的包。- 项目的依赖树往往非常深，进行全面的代码审计几乎不现实。
- 大家对 PyPI 官方仓库有着习惯性的信任。
此次 LiteLLM 事件，初步推测正是由于项目维护者的 PyPI Token 被盗所致。这并非孤例，此前 DockerHub 上也发生过类似的 OneAPI 镜像被投毒事件。这些事件共同指向了一个严峻的问题：我们该如何构建可靠的防线？
如何防范镜像投毒？
作为另一款开源 AI 网关项目 Higress 的维护者，我们在关注此次事件的同时，也分享一下在防范类似风险上的一些实践。
Higress 是一款由阿里云开源的云原生网关，其内核也被用于阿里云 API 网关产品。它一直使用阿里云容器镜像服务（ACR）进行镜像存储，并维护着自己的官方 Helm 仓库。这么做至少有两个好处：
- 对国内开发者更友好，镜像拉取速度快，且不受国际网络波动影响。
- 可以利用 ACR 的镜像安全扫描能力，自动拦截有风险的镜像提交。
这第二点，正是防范开源镜像投毒的核心。通过配置云原生交付链，我们可以在镜像构建并推送后，立即触发自动化的安全扫描。
如图所示，一旦扫描引擎发现镜像中包含后门文件、木马程序、挖矿程序等恶意样本，可以依据策略自动阻断该镜像的下载和后续流程，甚至直接删除高危镜像，防止其流入生产环境。
此外，自动化、无人为干预的发布流程也至关重要。Higress 社区在每次版本发布后，都通过 GitHub Actions 自动构建容器镜像和安装包。镜像仓库的密钥通过 GitHub Secrets 管理，发布版本的权限可以开放给社区合作者，但无需向他们暴露仓库的密码，从流程上降低了凭证泄露的风险。
如何防范 PyPI 包投毒？—— 构建三重纵深防线
镜像投毒尚可通过私有镜像仓库和安全扫描来应对，但 PyPI 这类公共仓库的包投毒，则需要从更根本的软件架构和安全体系上着手。以阿里云 API 网关（基于 Higress）为例，其设计将安全性置于最高优先级，针对凭证泄露、恶意攻击、插件风险等威胁，构建了三重纵深防线。
第一重防线：KMS 密钥托管，凭证从不明文落地
在 LiteLLM 事件中，攻击者窃取的重点就是环境变量和配置文件中的明文密钥。API 网关作为流量入口，管理着大量此类敏感凭证。
阿里云 API 网关深度集成阿里云密钥管理服务（KMS）。所有敏感凭证（如 API Key）均由 KMS 加密托管，网关配置中只保存加密后的密文引用，而真正的明文字段则由 KMS 统一安全保管。这套机制带来了多重保障：凭证不会以明文形式出现在任何配置文件、环境变量或日志中，从源头切断泄露可能；对凭证的任何访问都需经过 KMS 和 RAM（资源访问管理）的严格权限校验；不同消费者凭证相互隔离，即使单一凭证泄露，影响范围也被严格限制。
第二重防线：WAF 防火墙联动，在流量入口筑起屏障
网关是所有请求的入口，自然也直面各类网络攻击。阿里云 API 网关可一键对接阿里云 Web 应用防火墙（WAF），为流量增加一道强大的“安检门”。
所有进入网关的请求都会先经过 WAF 的深度检测与过滤，包括：
- 恶意请求拦截：基于实时威胁情报库，自动阻断 SQL 注入、XSS、命令注入等常见攻击。
- 异常流量检测：分析请求内容与模式，识别潜在的攻击特征。
- CC攻击防护：防止恶意高频调用打垮后端服务。
- Bot管理：识别并阻拦自动化爬虫或扫描工具。
第三重防线：Wasm 沙箱插件，实现能力扩展与风险隔离
网关需要强大的扩展能力，但传统插件模式往往与核心进程共享内存空间，一个有问题的插件就可能危及全局。
阿里云 API 网关采用 Wasm（WebAssembly）沙箱插件 机制来解决这一矛盾。每个插件都运行在独立的沙箱环境中：
- 内存隔离：插件无法访问网关核心或其他插件的内存空间。
- 系统调用受限：沙箱严格限制插件的系统调用权限，防止其随意读写文件、扫描环境变量。
- 热更新无损：插件的安装、更新无需重启网关，对业务流量零影响。
- 多语言与开源：支持使用 Go、Rust 等多种语言开发，社区插件代码开源可审计。
这意味着，即使某个第三方 Wasm 插件被恶意投毒或存在漏洞，其破坏力也被牢牢锁在沙箱之内，无法窃取网关管理的核心凭证或影响其他组件。
值得一提的是，阿里云 API 网关提供了内置的 WebIDE 用于插件开发，并集成云效构建流水线。整个构建过程在云效托管的 VPC 专有网络内完成，代码拉取、依赖下载与制品产出均与公网隔离，这从根本上降低了在 CI/CD 环节引入类似被投毒构建工具（如事件中涉及的 Trivy）的风险。
更多安全能力
除了上述核心防线，围绕 云原生 架构还提供了一系列增强安全的能力：
- mTLS双向认证：确保网关与后端服务间通信的真实性与机密性。
- 标准化认证集成：内置 JWT、OIDC 等协议，轻松对接企业身份体系。
- 精细化访问控制：基于消费者、API 路由等多维度实施调用权限与配额管理。
- 全方位可观测性：实时监控接口流量与延迟，快速发现异常调用模式。
目前，涉事的 LiteLLM 1.82.7 和 1.82.8 版本已被 PyPI 官方下架。
这次事件再次凸显了软件供应链安全的极端重要性。作为开发者，我们除了要时刻保持警惕，及时更新信息，更需要从架构和流程上系统性地构建防御能力。通过采用密钥托管、流量清洗、沙箱隔离等纵深防御策略，才能在现代复杂且充满挑战的数字环境中，真正守护好应用与数据的安全之门。
发表于 3 小时前
|
查看: 2|
回复: 0
