今天早上刷到 Karpathy 的警告推文，我第一反应是停掉正在跑的实验环境，开始逐一排查依赖。
作为长期在一线体验 AI 工具的产品经理，我越来越确信：现在的“风险点”不只在模型和数据，更多在我们看不见的依赖树。
这次 litellm 被投毒，是一个很直接的提醒。
核心结论
- 风险点：litellm 的 1.82.7 和 1.82.8 两个 PyPI 版本被植入恶意
.pth文件，任何 Python 进程启动都会执行窃密逻辑。 - 影响面：litellm 被超过 2000 个包依赖，月下载量约 9500 万；即使没直接安装，也可能通过其他工具被间接引入。
- 快速处置：检查版本 → 降级到 1.82.6 → 删除恶意文件 → 假设凭证泄露并全部轮换 → 检查所有环境。
- 与 OpenClaw：OpenClaw 核心调用 Anthropic 官方 SDK，不依赖 litellm；但安装的社区插件可能间接引入，需自查。
发生了什么：一次典型的供应链攻击
3 月 24 日（UTC），litellm 连续发布 1.82.7 与 1.82.8，两个版本内包含 litellm_init.pth。.pth 会在任意 Python 进程启动时自动执行，恶意代码会收集和外传以下敏感信息：
- SSH 私钥
- AWS/GCP/Azure 访问密钥
- Kubernetes 服务账户与集群令牌
- .env 环境变量文件
- 数据库配置文件
- 加密货币钱包相关文件
这次之所以被快速发现，是因为攻击者代码有缺陷，触发进程级“fork bomb”，导致本地内存暴涨，才被开发者注意到。
攻击链路（简要复盘）
- 3月19日：开源扫描工具 Trivy 仓库被攻陷
- 3月23日：Checkmarx KICS 被攻陷
- 3月24日：攻击者利用被污染的工具链，窃取 litellm 的 PyPI 发布令牌，推送带毒版本
要点：安全工具成为突破口，进而污染目标项目的发布流程，形成供应链连锁感染。
受影响范围：我实际排查关注的对象
- 直接依赖 litellm 的工具：Open Interpreter、DSPy、MLflow 等
- 任何“统一大模型 API 调用”的第三方库或脚手架
- 你的所有 Python 环境：本地 venv/conda、CI/CD Runner、Notebook 内核、容器镜像构建环境
数据点：litellm GitHub Star 4 万+，月下载量约 9500 万；超过 2000 个包依赖它。
快速自查与清理（我采用的步骤）
检查是否安装及版本
pip show litellm若版本为 1.82.7 或 1.82.8，判定中招；1.82.6 是最后的干净版本。
立即降级并删除恶意文件
pip install --upgrade --force-reinstall litellm==1.82.6
python -c "import site; print(site.getsitepackages())"
# 在上述目录中删除 litellm_init.pth（名称精确匹配）假设凭证已泄露，全部轮换（不要侥幸）
轮换 AWS Access Key/Secret、GCP Service Account Key、Azure 凭证
更换 SSH 密钥对（服务器端 authorized_keys 同步更新）
替换 .env 中的所有 API Key，并刷新相关服务端密钥
若使用 Kubernetes，轮换服务账户令牌、检查是否存在异常特权 Pod
检查所有环境（不仅是当前 venv）
本地多个虚拟环境、conda 环境、系统 Python
CI/CD、Notebook、容器镜像构建基线镜像
多机/集群节点一致性检查
OpenClaw 的情况与自查建议
- OpenClaw 核心依赖 Anthropic 官方 SDK，不直接使用 litellm；本体不受此事件直接影响。
- 若通过 ClawHub 安装社区插件，建议对插件依赖树做一次扫描，确认是否间接引入 litellm。
实践建议：
# 在 OpenClaw 运行的同一 Python 环境（若有）执行
pip show litellm || echo "litellm 未安装"
pip freeze | grep -i litellm || echo "依赖树未检测到 litellm"
为什么这次值得重视：使用方式的取舍
Karpathy 的观点很务实：能用少量自写代码完成的功能，不一定需要引入依赖。对我来说，选择策略更像是“适配性”问题：
| 方案 | 功能范围 | 技术特征 | 使用门槛 | 适合人群/场景 | 主要风险点 |
|---|---|---|---|---|---|
| 统一调用库（如 litellm） | 多厂商模型接口统一 | 单一抽象层适配多 API | 低-中 | 需要频繁切换模型/供应商的团队 | 供应链风险、依赖树复杂 |
| 官方 SDK（如 Anthropic/OpenAI 官方） | 单厂商功能完整 | 与官方更新同步 | 中 | 模型与供应商较稳定的项目 | 厂商锁定、迁移成本 |
| 小功能自写代码（借助 LLM 生成） | 定制化，满足特定小需求 | 最小依赖、可读可控 | 中-高（需代码审阅） | 安全敏感、长生命周期的核心路径 | 维护成本在团队侧 |
我补充的加固清单
- 包版本管理：在生产和 CI 使用锁定文件（pip-tools/poetry/uv），固定版本与哈希；禁用未审计的“浮动升级”。
- 最小权限发布：PyPI 发布使用短期令牌或 OIDC Trusted Publishing；撤销长生命周期令牌。
- 隔离：强制虚拟环境；构建-运行隔离；容器镜像基础层定期安全审计。
- 出口审计：CI/生产环境限制外网出口，按域名白名单放行；对异常外联进行告警。
- 凭证策略：默认短期可轮换、集中管控（如 AWS IAM、GCP IAM、Vault）；避免将密钥落盘。
- 监控：为 Python 运行时添加可观测性，对异常子进程/文件访问/网络请求做基线比对。
时间线速览
| 时间（UTC） | 事件 |
|---|---|
| 3/19 | Trivy 仓库被攻陷 |
| 3/23 | Checkmarx KICS 被攻陷 |
| 3/24 10:39 | litellm 1.82.7 发布（含恶意 .pth） |
| 3/24 10:52 | litellm 1.82.8 发布（含恶意 .pth） |
我的体验与观察
- 本地与 CI 环境中，间接依赖常常“悄悄”进入；使用
pip freeze和依赖树可视化比只看requirements.txt更可靠。 - 降级与清理很快，但凭证轮换才是关键步骤，尤其是云账号与 Kubernetes。
- 这次事故再次验证：把“依赖最小化”作为产品与工程共同决策项，能显著降低不必要的暴露面。
总结
这次 litellm 投毒不是个例，而是供应链攻击在 AI 开发生态的常态化表现。
我的做法会坚持三点：第一，关键路径尽量用官方 SDK 或少量自写代码，控制依赖面；第二，给团队配齐“可被执行的”自查与轮换流程；第三，把“依赖风险”前置到方案评审里，和性能、成本并列考虑。
OpenClaw 本体未受影响，但插件生态仍需自查。
与其事后排查，不如把可观测、可回滚、可轮换设计在前。