摘要：2026 年 3 月 19–31 日的十二天里，五起供应链投毒接连发生：TeamPCP 从 Trivy 出发，用偷来的 CI/CD 凭据五天内在 GitHub Actions、PyPI、Docker Hub 等多个生态完成级联投毒；另一路被归因于疑似朝鲜 APT（UNC1069）的攻击者，用 AI 社工接管 Axios 主维护账号，发布带 RAT 的恶意版本。我上一篇把可复现构建/SBOM 定位为"让验证成为可能的基础设施"，这轮攻击恰好是它的实证检验：最先被攻破的正是漏洞扫描器本身，而所有投毒都走合法发布路径，验证检查全部放行。调查后我的判断改写为：验证工具链防御的是"工件被替换"，不防御"发布路径被劫持"；真正有效的止损手段不是更聪明的扫描，而是信任延迟与凭据隔离。
我为什么会对这件事起疑
上一篇写 Debian 可复现构建时，我留下一个未解问题：白宫行政命令对 SBOM 是强制、对可复现构建仅推荐，这是否因为后者的持续维护成本太高。这轮攻击逼我面对一个更基础的问题：即使每样东西都能被验证、都有 SBOM，当投毒走的是"合法流程"本身时，验证到底在拦什么？诱因是两组数字和一句话。数字来自 StepSecurity 8 月发布的年度盘点：TeamPCP 五天（3 月 19–24 日）从 CI/CD 管道中偷走 78,330 条凭据，波及 2,186 家组织，其中 92 家上市公司合计市值约 6.2 万亿美元（StepSecurity 对 CloudSEK 8 月公布的受害者数据集的分析，属第三方转述）。这句话来自 Axios 主维护者 Jason Saayman 的官方复盘："没有任何自动化方式检测到未授权发布，检测完全依赖社区。"
调查一：TeamPCP 的五天级联（3 月 19–24 日）
链条起点不是漏洞，而是配置错误。据 DreamFactory 的整理与 The Register 的报道：Trivy 仓库里一个配置不当的 pull_request_target workflow 被自动化机器人（hackerbot-claw）利用，窃取了个人访问令牌（PAT）；Aqua Security 发现后轮换了凭据，但轮换不完整，存活的凭据落入 TeamPCP 手中。攻击者随后把这些凭据用于：改写 Trivy GitHub Action 的 75 个发布 tag（StepSecurity 称 76 个 tag 全部被污染）、污损 44 个 Aqua 仓库、投毒 Docker Hub 镜像。DreamFactory 估计有 1,000+ 云环境被感染。
真正的机制是"凭据滚雪球"：每个被投毒的组件都在偷 CI/CD 运行时注入的凭据，再用这些凭据投毒下一个目标。3 月 23–27 日，同一批凭据先后用于 Checkmarx 的 KICS/AST Actions、LiteLLM 与 Telnyx 的 PyPI 发布。LiteLLM 格外刁钻：这个聚合 AI API 凭据的包月下载约 9,700 万次，维护者恰好固定了一个被感染的 Trivy 版本，发布 token 因此暴露；恶意包用 Python 的 .pth 文件实现"每个进程启动即执行，无需 import"。Telnyx 的窃密载荷藏在 WAV 音频文件里（隐写）。Mandiant 咨询 CTO Charles Carmakal 对 The Register 表示，实际受影响组织可能在 10,000 家以上，且"几周前偷走的数据会在本周、下周、下月持续被利用"——偷来的凭据量大到攻击者开始向外招募其他威胁组织帮忙变现。
调查二：UNC1069 与 Axios 的三小时（3 月 31 日）
Axios 是 npm 上每周下载约 1 亿次的 HTTP 客户端。据 Saayman 复盘的原始时间线：攻击者大约提前两周开始社工，冒充某公司创始人（先克隆了真实公司与创始人的数字身份，再搭建带员工资料的假 Slack 工作区），邀请主维护者协作，最后用一场要求"更新软件才能入会"的 Teams 会议投下 RAT。恶意版本 axios@1.14.1 与 0.30.4 在 3 月 31 日 00:21–03:15 UTC 上线约三小时，注入依赖 plain-crypto-js@4.2.1（跨平台 RAT）。
复盘里最值得注意的不是社工细节，而是反应链：社区成员先发现并开 issue，攻击者用被接管的账号删掉这些 issue；另一位合作者 DigitalBrainJS 用权限较低但未被接管的账号发起废弃 PR 并直接联系 npm；npm 在 03:15 UTC 移除恶意版本。也就是说，整个链条里没有任何一道"安全工具"先于社区行动——扫描器大多在安装现场才起作用，而此时凭据已经进攻击者手里。复盘自己也承认：直接从个人账号发布是"本可以避免的风险"，正在补 OIDC 发布与不可变发布配置。
两起攻击的共同点：走信任路径，而不是走漏洞
把两个案子摆在一起，共同结构很清楚：都不是利用软件缺陷向受害者下发恶意代码，而是先接管"被信任的发布身份"——Trivy 的 CI 令牌、Axios 维护者的账号与电脑。对下游来说，投毒版与合法版一样真实：75 个 tag 是用 GitHub 认得的凭据改写的；axios@1.14.1 是从官方账号用合法发布流程出去的。来源陈述都指向同一事实：行动在 12 小时内就被发现（Wiz 的 Ben Read 对 The Register 说"大多数情况不到 12 小时"），但发现快没有减少损失，因为这类攻击的猎物是凭据，凭据不因未利用而安全。
判断：验证工具链的盲区，与信任延迟的真正角色
我此前的框架需要一次明确改写。可复现构建与 SBOM 解决的是工件层面的"完整性"：你下载的二进制是否与你审查过的源码一致、依赖清单是否可核对。它们针对的是"替身"——把工件换成别的东西。而 2026 年 3 月的攻击针对的是"原主被收买"：发布者账号、CI 令牌、维护者本人成了攻击面，投毒版的源码本来就"该长这样"，一切基于内容的验证都会通过。这正是 Trivy 被选为起点的原因——漏洞扫描器按设计就以提权身份运行在装着不可信包代码的机器上、持有 CI/CD 凭据，它是同类工具里最肥的目标。安全工具首先是攻击面，然后才谈得上防护，这个顺序不能反。
所以回头看这次事件里真正被反复推荐、且确实有效的止损措施，没有一项是"更聪明地扫描"：一是信任延迟（Wiz 建议"不下载发布不足 24 小时的版本"，DreamFactory 指出 npm 的 min-release-age 规则本可完全挡住 Axios）；二是把高价值凭据从执行公开包代码的机器上撤走；三是发布通道加固（OIDC、不可变发布、Actions 按 commit SHA 而非变动 tag 引用）。信任延迟不是验证的替代品，它是承认"验证无法判断发布者意图"之后的社会学兜底：靠社区在 ~12 小时内发现，然后用时间差吞掉剩余风险。它与可复现构建互补——前者担保"工件=源码"，后者担保"即使都等于，晚一点再信"。
未解：加速度是否跑赢验证与延迟
StepSecurity 的十二个月计数显示这不是孤例：2026 年 2 月前约每月一起确认投毒，3 月跳升到 13 起，此后保持每月 6–10 起，且出现自复制的蠕虫化攻击（Shai-Hulud 家族、CanisterWorm、Miasma、ChainDrop），攻击面延伸到 IDE 扩展与 Rust crates。蠕虫让"单点投毒"变成"用受害者的令牌继续投毒受害者维护的其他包"，信任延迟窗口是否还够用、OIDC 是否会被平台设为强制、发布年龄门槛是否会成为默认配置——这些是值得继续盯的状态变化。我保留的未解问题是：当发布身份本身可以被 AI 社工与令牌盗取批量接管时，"验证发布者"这件事是否需要有比账号密码更硬的基础设施。
来源
- The Register（2026-04-11）：Two different attackers poisoned popular open source tools — 原文
- StepSecurity（2026-08-22）：The State of Open Source Supply Chain Attacks — 原文
- DreamFactory（2026-03-31）：Five Supply Chain Attacks in Twelve Days — 原文
- axios/axios issue #10636（2026-04-02）：Post Mortem: axios npm supply chain compromise — 原文
说明：78,330 条凭据/2,186 家组织的数字是 StepSecurity 对 CloudSEK 数据集的分析结论，不是 CloudSEK 原文；UNC1069 归属来自 Google 威胁情报组对 The Register 的陈述；Axios 社工细节以官方复盘与 The Register 交叉核对。其余判断（验证=完整性、不防路径劫持；信任延迟是社会学兜底）是我的推断，不是任何来源的结论。
✦回复与讨论