总把软件升到最新版？是时候改改这个习惯了

Pengfei Ni — Thu, 26 Mar 2026 10:01:00 +0800

做技术的人大都有个习惯：看到依赖库有新版本，第一反应就是升上去。CI/CD 流水线里配好了 Dependabot、Renovate，小版本自动提 PR，有些团队甚至设了自动合并。一个 patch 版本号的变化，changelog 里写着几个 bug fix，看起来毫无风险，顺手就合了。

大版本升级倒是大家都知道要谨慎，毕竟 breaking changes 摆在那儿，不测不行。但小版本呢？一个 0.69.3 到 0.69.4 的变化，谁会仔细去审核上游的每个变更？

最近发生的三件安全事件，让我觉得这个“小版本放心升”的默认心态，得改一改了。

安全扫描工具自己被投毒了

3 月 19 日，安全圈炸了一个大雷：Trivy 被供应链攻击了。

Trivy 是 Aqua Security 开源的容器安全扫描工具，在 CI/CD 流水线里用得非常广，很多团队拿它来扫描容器镜像、检查依赖漏洞。结果这次，扫描工具自己成了攻击入口。

攻击者是一个叫 TeamPCP 的组织，手法相当老练。他们先是利用 Trivy GitHub 仓库里一个配置不当的pull_request_target 工作流，偷到了一个有特权的 Personal Access Token。Aqua Security 发现后做了密钥轮换，但轮换不彻底，攻击者手里还留着能用的凭证。

然后事情就失控了。3 月 19 日下午，攻击者用残存的凭证对trivy-action 仓库的 76 个版本标签做了 force-push，把所有 tag 指向了恶意代码。同时还触发了发布流程，把带后门的 v0.69.4 推到了 GitHub Releases 和容器镜像仓库。

恶意代码做的事情超乎你的想象：扫描 Runner 环境里的 AWS、GCP、Azure 凭证、SSH 密钥、Kubernetes Token、Docker 配置，加密后外传到一个伪装成 Aqua 官网的域名scan.aquasecurtiy.org（注意这个拼写错误，把 security 拼成了 securtiy）。而且整个过程不影响正常扫描，工作流看起来一切正常，你根本不知道自己的密钥已经被偷了。

更离谱的是，Aqua 团队在 3 小时内控制住了 GitHub Actions 的问题，但攻击者还留了后手。3 月 22 日，他们用另外获取的 Docker Hub 凭证，直接往 Docker Hub 推了 v0.69.5 和 v0.69.6 两个恶意镜像。Mandiant 后来确认，超过 1000 个云环境在这次攻击中被入侵。

如果你在用 Trivy，安全版本是 v0.69.3，trivy-action 升到 v0.35.0，setup-trivy 升到 v0.2.6。更重要的是，GitHub Actions 里所有第三方 Action 都应该锁定到 commit SHA，不要用可变的 tag，tag 是可以随时被 force-push 篡改的。

安全扫描工具把下游也拖下水了

Trivy 的故事还没完。3 月 24 日，LiteLLM 也中招了。

LiteLLM 是做 AI 开发的人应该都不陌生，它是一个统一的 LLM 代理网关，也是 Anthropic 官方推荐的 LLM Gateway 之一。月下载量 9500 万，CrewAI、DSPy、Browser-Use 这些主流框架都依赖它。

LiteLLM 的 CI/CD 流水线里用了 Trivy 做安全扫描（对，又是安全扫描），而且没有锁定版本。构建时从 apt 拉了最新的 Trivy，正好拉到了被污染的版本。被污染的 Trivy 在扫描过程中偷走了 LiteLLM 的 PyPI 发布密钥。

拿到密钥后，攻击者在 3 月 24 日上午连发了两个恶意版本。1.82.7 把恶意代码 base64 编码后藏在litellm/proxy/proxy_server.py 里，只要 import 了litellm.proxy 就会触发。1.82.8 更狠，往site-packages/ 目录塞了一个litellm_init.pth 文件。Python 的.pth 机制会在解释器启动时自动执行，也就是说只要你的环境里装了这个版本，哪怕你没 import litellm，跑个pip install 或者 IDE 的语言服务器启动一下，后门就已经在跑了。

后门做的事情和 Trivy 那个如出一辙：扫描 SSH 密钥、云凭证、加密钱包、Slack 和 Discord Token、各种.env 文件，打包加密后外传。如果检测到 Kubernetes 环境，还会在集群里部署特权 Pod 做更多恶意行为。

好在 PyPI 团队反应快，3 小时就把恶意版本下架了。但 LiteLLM 日均下载 340 万次，3 小时的窗口期也不短了。

当前 Li 特 LLM 的安全版本是 1.82.6。如果你在 3 月 24 日那个窗口期内跑过pip install litellm，建议当作一次完整的凭证泄露事件来处理：轮换所有密钥，检查site-packages/ 下有没有litellm_init.pth，排查系统里有没有可疑的进程服务等。

回过头看这条攻击链，一个安全扫描工具被攻陷，导致用它的项目被偷走发布密钥，进而污染了数千万下载量的 Python 包。如果 LiteLLM 的 CI 里锁定了 Trivy 的版本，这条链路就断了。

OpenClaw 大更新，微信飞书一起崩

第三个故事不是安全问题，但同样是急着升级惹的祸。

3 月 22 日，OpenClaw 发了 v2026.3.22 版本。这是个大版本，包含 12 个 breaking changes、一个新的默认插件商店 ClawHub、30 多个安全补丁。

然后，微信刚上线 72 小时的 ClawBot 插件直接崩了。飞书插件也崩了。DingTalk、WhatsApp 也没幸免。

根本原因是 OpenClaw 重构了插件 SDK 的导入路径，把原来的统一入口openclaw/extension-api 直接删了，要求所有插件迁移到新的路径openclaw/plugin-sdk/core。没有兼容层，没有过渡期，所有还在用旧路径的插件启动就报 Cannot find module。

同时，新版本把安全防御逻辑下沉到了执行管道最底层，原来用简单字符串过滤的第三方插件全部触发 dangerous code pattern detected 告警。

更尴尬的是，新版本的 npm 包里漏打了dist/control-ui/ 目录，Dashboard 直接 503。这个文件在 Git 仓库和 Docker 镜像里都有，就是 npm 发布的时候漏了。

OpenClaw 官方在 12 小时内发了 v2026.3.23 热修复，微信的 ClawBot 也跟着修了。但如果你当时已经升了 v2026.3.22，可能已经发现你的龙虾🦞压根就没法访问了。

升级的姿势，得讲究一些了

回过头看这三件事，问题不在“该不该升级”，而在“怎么升”。

Trivy 是小版本号的变化（0.69.3 → 0.69.4），看起来就是个 patch，但被投毒了。LiteLLM 也是小版本升级（1.82.6 → 1.82.7），CI 里没锁版本就自动拉了最新的。OpenClaw 是大版本带了 12 个 breaking changes，但很多人看到有新版就直接升了。

三个不同的故事，根源其实是同一个默认假设：新版本比旧版本好，修了很多安全问题，升就对了。

这个假设正在变得越来越危险。现在 AI 的能力越来越强，软件供应链攻击的手法也在跟着进化。这次 TeamPCP 用的 hackerbot-claw 就是一个自主运行的攻击机器人，能自动寻找 GitHub Actions 的配置漏洞、自动提取凭证、自动传播。当攻击本身都在用 AI 加速的时候，防御这边反而应该慢一拍，多一层验证。

与此同时，很多团队的安全策略还是“有 CVE 就修，有新版就升”。开源和闭源项目也都在推进自动安全扫描、自动更新依赖库版本，甚至要求任何 CVE 都必须第一时间修复。这个思路本身没错，但这周的事情暴露了一个盲区：你升级到的那个最新版本，未必是安全的，甚至可能正好是攻击者刚投毒的版本。

所以，不是说不该更新，而是更新的习惯得调一调。

依赖锁定是基本功。package-lock.json、poetry.lock、go.sum 这些锁文件要认真对待，不要随便npm update 或者pip install --upgrade。GitHub Actions 的第三方 Action 锁定到 commit SHA，不要用可变的版本标签。这次 Trivy 的事件已经证明了，tag 是可以被 force-push 篡改的。

生产环境的更新更要适当延迟。等个几天，让社区先踩一轮坑，再决定要不要跟进。自动升级的 PR 不要自动合并，小版本也不例外。

关注你依赖的关键项目的安全公告。Trivy 这次从发现到控制只用了 3 小时，但如果你没关注它的安全通告，可能两天后才知道自己中招了。

快速修补所有 CVE 这个策略听起来很安全，但你修补的速度，可能正好赶上攻击者投毒的窗口。稳一步，反而更安全。

LiteLLM | Feisky

总把软件升到最新版？是时候改改这个习惯了

安全扫描工具自己被投毒了

安全扫描工具把下游也拖下水了

OpenClaw 大更新，微信飞书一起崩

升级的姿势，得讲究一些了