依赖已经装进生产了怎么办：vibe 项目 90 分钟中毒 containment 实战

先说清楚：这篇指南管什么、不管什么

这篇指南只讲一种已经发生的情况：你已经把一个有问题的依赖装进了项目、跑进了生产环境，现在要把它 containment 住。它的起点是“已经装了”，终点是“重建完成、凭据换完、用户通知发出”。它不是事前预防手册。

边界必须先划清，以免和站内已有的几篇指南混淆。第一，站内已有的两篇依赖供应链安全指南讲的是事前预防：装包之前怎么识别幻觉包名、拼写劫持和依赖混淆，怎么养成安全的装包习惯——它们回答的是“怎么避免装错包”。本篇不重复那些内容，本篇假设你已经装错了，回答的是“装错之后 90 分钟内做什么”。第二，站内已有的凭据管理指南讲的是日常怎么做密钥管理：密钥放哪里、怎么分级、怎么避免把密钥交给 AI 工具——那是平时的制度。本篇只讲事故当天的轮换顺序：在什么顺序、以什么方式把可能已经泄露的密钥换掉。第三，站内已有的通用事故响应 Runbook 讲的是所有线上事故的通用流程：分级、止血、回滚、复盘——它适用于宕机、慢查询、配置错误等各种事故。本篇是它在“依赖投毒”这一种事故上的专用版本，步骤更具体，顺序不能打乱。第四，站内已有的 AI 功能降级与熔断指南讲的是第三方服务不可用时怎么让产品继续跑：超时、重试、熔断、降级阶梯——那是“服务挂了怎么办”。本篇讲的是“服务没挂，但它在偷东西怎么办”，两者的问题完全不同，处理方法也完全不同。简单记一句话：预防指南管装包之前，凭据指南管平时，通用 Runbook 管所有事故的大框架，降级指南管服务不可用；本篇只管装包之后、已经中毒的 90 分钟 containment。

第一原则：先隔离，再清理；先止血，再追责

收到“某个依赖版本被投毒”的消息时，独立开发者最容易犯的错误是立刻动手升级，以为升到新版本就没事了。错了。升级是在同一台可能已经被渗透的机器上、沿用同一条可能已经被污染的链路再跑一次安装。正确顺序永远是：先隔离，让坏东西停下来、让它接触不到新的凭据；再找落脚点，确认它到底改了什么、偷了什么；最后从一台干净的机器上重建、轮换、验证。隔离不是拖延，而是为了让后面每一步都不白做。

第二条原则是：把“可能泄露”当成“已经泄露”来处理。恶意依赖最常见的 payload 就是凭据窃取器：它在安装时或程序启动时读环境变量、读云厂商凭据文件、读 SSH 密钥、读浏览器凭据，然后外发。你无法靠“没看到外发记录”证明它没偷——日志可能被清，流量可能走了正常域名。只要中毒版本在装有真实凭据的环境里跑过，就按全部泄露处理。反过来也一样：如果中毒版本只在没有凭据的沙箱里跑过一次、从没接触过生产密钥，那就不用把全套轮换做满，但必须写下来你是怎么判断的，判断依据是什么。

第三条原则是：时间盒。一个人处理事故最怕无限发散：查着查着去翻三个月前的日志，或者在群里争论根因。给自己 90 分钟，90 分钟后必须有一个可用的干净版本、一个轮换完毕的凭据清单和一封发给用户的说明。查不完的线索写进待办，放到 90 分钟之后继续查，不要让它挡住止血。

第 0 步：先判断你到底有没有中招

别凭感觉，也别只看 package.json。package.json 里写的是范围，比如 ^1.2.0，真正装的是哪个版本要看锁文件。锁文件、安装日志和镜像标签三处对得上，才算判断完成。

先查锁文件。Python 项目看 requirements.txt、Pipfile.lock、poetry.lock 或 uv.lock；Node 项目看 package-lock.json、pnpm-lock.yaml 或 yarn.lock。搜的不是包名，而是“包名加可疑版本号”：

# Python：锁文件里有没有中毒版本（把 BAD-PACKAGE 换成实际包名，1.2.3 换成中毒版本）
grep -n "BAD-PACKAGE" poetry.lock requirements.txt uv.lock 2>/dev/null
grep -A3 'name = "BAD-PACKAGE"' poetry.lock | grep version
pip show BAD-PACKAGE 2>/dev/null | grep -E "Name|Version|Location"
pip freeze | grep -i "BAD-PACKAGE"

# Node：锁文件与实际安装树都要查
grep -n '"BAD-PACKAGE"' package-lock.json pnpm-lock.yaml 2>/dev/null
npm ls BAD-PACKAGE
cat node_modules/BAD-PACKAGE/package.json | grep '"version"'

再查安装日志和缓存。CI 日志会写明某次构建实际装了哪个版本、从哪个源装的；本地缓存里可能还留着中毒版本的安装包。重点看三件事：中毒版本是什么时候装的，在哪台机器或哪个 CI 任务里装的，那次运行有没有接触生产凭据。本地开发机装过一次和 CI 在生产部署里装过一次，严重程度完全不同。

# 构建日志与缓存里的痕迹（示例，按自己的 CI 与包管理器调整）
grep -rn "BAD-PACKAGE@".github/workflows/ 2>/dev/null
pip cache list 2>/dev/null | grep -i "BAD-PACKAGE"
ls ~/.cache/pip 2>/dev/null | head

最后查镜像标签，这是最容易漏的一处。如果你用 Docker 部署，光查代码里的包版本是不够的：中毒版本可能藏在镜像里，而镜像标签是浮动的。latest 今天指向的镜像和昨天指向的可能根本不是同一个。必须查摘要，也就是 digest，而不是只看标签名：

# 只看标签会骗人，必须看 digest
docker images --digests | grep -i "your-app"
docker image inspect your-app:latest --format '{{.RepoDigests}} {{.Id}}'
docker history your-app:latest 2>/dev/null | head -n 30

判断结果只有三种，写下来：第一种，确认中招——锁文件、日志或镜像里有中毒版本；第二种，确认没中招——锁文件版本干净、镜像 digest 对得上干净版本、安装时间在中毒窗口之外，且有证据；第三种，无法确认——日志缺失、锁文件没提交、镜像用的是浮动标签查不到历史。第三种按中招处理。写判断结论时附上命令输出截图或日志片段，不要只写“我查过了”。

90 分钟总清单

下面这张表就是全文的骨架。0 到 15 分钟只做隔离，15 到 45 分钟只找落脚点，45 到 90 分钟做轮换、重建、验证和通知。每一阶段结束时都有一个可检查的完成标准，达不到就不要进入下一阶段。

时间	目标	完成标准
0–15 分钟	隔离：让坏东西停下来	部署冻结、问题版本被钉住或屏蔽、受影响服务已停或已切到干净版本、证据已保留
15–45 分钟	找落脚点：它改了什么、偷了什么	启动钩子、异常文件、外发记录三项都查过，有清单，无“没查”项
45–90 分钟	轮换、重建、验证、通知	凭据按顺序换完、干净镜像已验证上线、用户说明已发出、待办已记录

0–15 分钟：隔离，不要“就地升级”

第一步，冻结部署。停掉自动部署，告诉自己也告诉协作者：接下来任何部署都要人工确认。正在跑的 CI 任务如果正在安装问题依赖，先停掉它，不要等它跑完。已经上线的服务不要立刻重启——重启可能触发恶意代码的启动钩子再次运行，也可能把内存里的证据清掉。先做决定：这个服务能不能先停？能停就停，不能停就先断掉它的出站敏感权限，比如只读数据库账号先降权、云厂商写权限先收回，但不要在中毒机器上改凭据，原因后面讲。

第二步，把问题版本钉死、挡住。把锁文件里的版本钉到中毒之前最后一个已知干净版本，写死精确版本号，不要写范围；同时在包管理器或私有 registry 层面屏蔽中毒版本，防止某次缓存命中或某个同事的本地安装又把它装回来。Python 示例：

# 钉到干净版本，写死版本号，不要留 ^ 或 ~ 的范围
pip install "BAD-PACKAGE==1.2.2"
grep -n "BAD-PACKAGE" requirements.txt poetry.lock

Node 示例：

# 同样写死版本，并检查锁文件是否同步更新
npm install "BAD-PACKAGE@1.2.2" --save-exact
grep -n '"BAD-PACKAGE"' package-lock.json

第三步，保留证据。把中毒时间段的构建日志、应用日志、安装日志、镜像 digest 列表复制一份到事故文件夹；把中毒机器或容器的当前文件清单也留一份。不要急着删包、删容器、清缓存——删掉之后，落脚点就找不到了。证据保留的动作本身只要几分钟，但事后补不回来。

# 保留一份当前状态快照，再动手
pip freeze > incident-pip-freeze.txt
npm ls --all > incident-npm-ls.txt 2>/dev/null
docker ps -a > incident-containers.txt
ls -la > incident-workdir.txt

第四步，定好对外口径的底线：先不发公告，但先写好一句话内部状态——“某依赖版本疑似投毒，正在隔离，受影响范围待确认”。这句话的作用是防止你在信息不全时被追问得随口承诺，也防止你 90 分钟后写用户说明时从零开始。

15–45 分钟：找落脚点——启动钩子、异常文件、外发记录

恶意依赖的落脚点通常只有三类，挨个查，不要凭印象跳过任何一类。第一类是启动钩子：代码在程序启动时自动运行，不需要你 import 它。Python 里最典型的是.pth 文件和 sitecustomize 模块：解释器启动时会自动加载它们。Node 里最典型的是安装脚本和启动脚本：preinstall、postinstall、以及被改过的启动入口。查法是直接列出这些位置，看有没有不认识的文件：

# Python 启动钩子：.pth 与 sitecustomize 是重点
python -c "import site; print(site.getsitepackages())"
ls -la $(python -c "import site; print(site.getsitepackages()[0])") | grep -E "\.pth|sitecustomize|usercustomize"
cat $(python -c "import site; print(site.getsitepackages()[0])")/*.pth 2>/dev/null

# Node 安装脚本与启动入口
cat node_modules/BAD-PACKAGE/package.json | grep -A5 '"scripts"'
grep -rn "preinstall\|postinstall" package.json node_modules/BAD-PACKAGE/package.json 2>/dev/null

第二类是异常文件：中毒时间段内被新建或改动的文件。先用版本控制看工作区有没有未提交的改动，再按时间找中毒窗口内被改过的文件，最后看系统级落脚点：定时任务、系统服务、Shell 启动文件。独立开发者自己的机器尤其要查 Shell 启动文件和定时任务，因为很多窃取器会往那里写持久化：

# 工作区与中毒窗口内的文件变化
git status --short
git diff --stat
find. -type f -newermt "2026-10-21 00:00"! -newermt "2026-10-22 00:00" 2>/dev/null | head -n 100

# 系统级落脚点（按需查，不要照搬不相关的路径）
crontab -l 2>/dev/null
ls -la ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null
systemctl --user list-unit-files 2>/dev/null | grep enabled

第三类是外发记录：它到底连过哪里。看应用日志里的出站请求、云厂商的审计日志、以及中毒时间段内的异常域名。重点不是“有没有外发”，而是“外发的目的地是不是你认识的服务”。不认识的域名、平时没有的区域调用、深夜的批量密钥调用，都是信号。把这三类查完，写成一张清单：发现了什么、没发现什么、哪项因为日志缺失无法确认。清单里“无法确认”那一项，决定了轮换范围要按最坏情况做。

45–90 分钟：从干净机器上轮换，顺序不能乱

轮换的第一条铁律：不要在中毒机器上生成新凭据，也不要在中毒机器上登录云控制台去吊销旧凭据。原因很简单：如果落脚点还在，新凭据生成的那一刻就可能被偷走，你等于白换。找一台干净的机器：可以是你确认没装过中毒版本的另一台电脑，也可以是一台全新开的云主机。所有吊销、生成、填入新凭据的操作都在这台干净机器上做，中毒机器只负责被隔离、被检查、最后被重建。

轮换顺序按“先止血，再补血；先云端控制权，再应用层密钥”排。推荐顺序如下，每一步都在提供商一侧先吊销旧的、再生成新的，不要先生成新的再慢慢吊销旧的，中间的时间差就是攻击窗口。

1. 云厂商根权限与 IAM 角色：先吊销可能泄露的访问密钥，收回可疑角色的写权限和控制台登录会话。这一步最先做，因为拿到云权限的人可以顺着去拿其他所有东西。
2. CI 与代码托管令牌：GitHub、GitLab、CI runner、容器 registry 的令牌和部署密钥。攻击者拿到这些就能往你的仓库和镜像里再推一次坏东西。
3. 数据库与基础设施凭据：数据库密码、缓存密码、对象存储密钥、消息队列凭据。改完后要确认旧凭据确实连不上了，不要只改配置不验证。
4. 第三方 API 与模型服务密钥：支付、短信、邮件、模型厂商的 API Key。按调用量从大到小换，先换生产正在用的。
5. 会话与登录态：用户会话 Cookie、OAuth 刷新令牌、单点登录会话。很多窃取器专门偷浏览器 Cookie 和会话，换 API Key 不换会话等于门还开着。必要时强制全站用户重新登录。
6. 签名与回调密钥：Webhook 签名密钥、JWT 签名密钥、加密密钥。换完要同步更新验签方，否则自己的回调会先断掉——提前写好验证步骤。
7. 最后才是个人账号密码：如果你本人的邮箱、代码托管账号在中毒机器上登录过，按提供商的流程改密码并检查登录历史和新加的授权应用。

轮换时记一张表：凭据名称、旧的是否已吊销、新的是否已在干净机器生成、哪些服务已更新、哪些服务验证通过。不要凭记忆，90 分钟后你一定记不全。表里任何一行停在“已生成但未更新”都算未完成。

重建与验证：从干净镜像开始，不要复用旧锁文件

重建不是“把坏包换掉再部署一次”。正确做法是：从干净的基础镜像开始，用钉死的干净版本重新生成锁文件，在干净的构建环境里重新构建，最后按摘要部署。旧锁文件不要直接复用——如果中毒版本曾经写进锁文件，或者锁文件里的哈希被动过，复用就等于把问题带回来。同样，Docker 镜像不要复用旧标签：latest、main-latest 这类浮动标签指向过中毒镜像，部署时必须写死 digest，确认 digest 对应的是干净构建。

# 干净重建的检查顺序：先删旧环境，再按干净版本重装，最后核对
rm -rf node_modules.venv
npm ci
pip install -r requirements.txt
npm ls BAD-PACKAGE
pip show BAD-PACKAGE | grep Version

验证至少做五项：第一，启动钩子位置没有残留文件；第二，锁文件版本与预期干净版本一致，镜像 digest 与干净构建一致；第三，服务能正常启动并通过冒烟测试；第四，中毒时间段内出现过的异常外发目的地不再出现；第五，旧凭据确实失效——拿旧 Key 调一次应该被拒绝，而不是还能用。五项都通过，才能说重建完成。任何一项不过，就回到对应步骤，不要为了赶 90 分钟而放行。

一个真实例子：LiteLLM 1.107.0（只作例证，不作新闻）

2026 年 10 月 21 日，Python 的 LLM 网关库 LiteLLM 的 1.107.0 版本在 PyPI 上线约两小时后被下架，同时受影响的还有 Docker Hub 与 GHCR 上 v1.107.0、latest、main-latest、main-stable 这几个标签指向的镜像。该版本含凭据窃取代码与远程代码加载后门，且相关启动钩子文件在卸载包之后仍可能残留，因此只卸载是不够的；官方建议的干净版本是 1.106.2。这个例子恰好说明了本篇的三个要点：第一，浮动标签会把中毒镜像扩散到所有没写死 digest 的部署；第二，启动钩子残留意味着“删包”不等于“干净”；第三，凭据窃取类 payload 必须按“已经泄露”处理，而不是等外发证据。把它当成一面镜子对照自己的项目就够了，不需要也不应该从这个例子里推断你自己的受害范围。

写给用户的事故说明：说清楚四件事

90 分钟结束前，把用户说明发出去。用户不需要技术细节，但需要四个明确答案：发生了什么、影响窗口是多久、你已经做了什么、用户自己需要做什么。写不确定的部分时直接写“尚未确认，正在查”，不要用“可能没有影响”来安抚。模板如下，填空即可：

我们在 [日期与时间段] 发现项目使用的 [包名与版本]
存在恶意代码，已于 [时间] 隔离并下线受影响版本。
已完成：重建干净版本、吊销并轮换可能受影响的凭据、验证旧凭据已失效。
对你的影响：[是否需要你重新登录 / 更换 API Key / 检查账单]。
尚未确认：[列出仍在查的项与预计更新时间]。
下一次更新时间：[具体时间]。

如果用户数据可能被波及，说明里必须写用户该做什么、做到哪一步算完成，而不是只写“我们深表歉意”。如果最后确认用户数据没有被波及，也要写你是怎么确认的、依据是什么。事故说明发出去之后，把时间线、判断依据、轮换表和验证结果归档到事故文件夹——下一次再遇到同类问题，你的第一反应就不是慌，而是翻这份档案。

六个常见错误，对照自查

1. 在中毒机器上轮换凭据：新密钥刚生成就可能被仍在运行的窃取器偷走。必须换到干净机器上做。
2. 只升级、不隔离：直接升到新版本，旧的启动钩子、异常文件和被偷的凭据一个都没处理，等于给中毒环境换了件外套。
3. 信任旧锁文件：锁文件本身可能就是中毒链路的一部分。重建时重新生成并核对，不要直接复用。
4. 忘记浮动 Docker 标签：代码里的包版本查干净了，但部署用的 latest 标签仍指向中毒镜像，下一次重启就又中招。部署一律写死 digest。
5. 删证据再查：删包、清缓存、删容器一时爽快，落脚点和时间线就再也找不回来了。先快照，再动手。
6. 过早宣布“没事了”：外发日志没查、旧凭据没验证失效、会话没强制失效，就急着发“已修复”公告。验证五项没全过，就不要写“已修复”。

收尾：一页纸自查清单

把下面这张清单打印出来或存成事故模板，下次直接打勾。每一项都要有负责人和完成时间，只打勾不写证据不算完成。

[] 锁文件 / 安装日志 / 镜像 digest 三处已查，结论已写下
[] 部署已冻结，问题版本已钉死并屏蔽
[] 证据快照已保留（日志、文件清单、容器清单）
[] 启动钩子 / 异常文件 / 外发记录三项已查，有清单
[] 轮换在干净机器上按顺序完成，旧凭据已验证失效
[] 干净镜像按 digest 重建并通过五项验证
[] 用户事故说明已发出，含影响、已做事项、用户动作、下次更新时间
[] 待办与时间线已归档，90 分钟后继续查的项已列出

依赖投毒最可怕的地方不是那两小时的中毒窗口，而是之后的每一次“以为已经干净了”。90 分钟 containment 的目标从来不是证明你没事，而是用隔离、证据、顺序轮换和可验证的重建，把“以为”换成“确认”。做完这 90 分钟，你的项目不一定立刻恢复到事发前的样子，但它一定处在一个你能说清楚、能验证、能负责的状态——对独立开发者来说，这就是事故处理最重要的成果。