过去30天内，4起供应链攻击事件共享同一套攻击逻辑。攻击者不再寻找零日漏洞，而是劫持你信任的第三方集成。

Vercel的工程师只是正常登录了一个AI工具。三个月后，攻击者拿着偷来的OAuth令牌，畅通无阻地走进了Vercel的内部系统。

打开网易新闻 查看精彩图片

攻击链还原：信任继承如何发生

这次入侵的起点不在Vercel，而在Context.ai——一家提供AI分析服务的第三方工具。Hudson Rock的安全团队在Vercel公开披露前一个多月，就已经在信息窃取日志中发现了相关凭证。

攻击路径极其干净：

第一步，Context.ai被攻破，员工凭证泄露。第二步，攻击者继承OAuth令牌，获得对Vercel内部系统的访问权限。第三步，利用Vercel平台对"非敏感"环境变量的明文存储策略，横向移动。

没有零日漏洞，没有容器逃逸。只是信任边界的连续传递。

OAuth令牌的本质是"可移植的身份捆绑包"。2026年的攻击者不需要钓鱼密码，他们只需要找到那个被过度授权的集成，然后让OAuth协议自己完成剩余工作。

Vercel在事后声明中确认：标记为敏感的环境变量确实加密存储，但"非敏感"变量以明文保存。攻击者正是利用这一分类策略，完成了权限提升。

四起事件，同一模式

Vercel并非孤例。过去30天内，另外三起事件遵循了相似的信任继承逻辑：

Axios后门事件。攻击者窃取了项目维护者jasonsaayman的长期有效npm令牌，发布两个恶意版本（1.14.1和0.30.4）。这些版本引入了一个幽灵依赖plain-crypto-js@4.2.1，通过postinstall钩子向macOS、Windows、Linux三平台静默部署远程访问木马。

关键细节：Axios的CI/CD管道本已配置OIDC（开放式身份连接）认证——一种更安全的短期令牌机制。但攻击者没有尝试破解OIDC，而是绕过了它。遗留的长期令牌与新版安全栈并存，"正确"的安全措施形同虚设。

Trivy-LiteLLM两阶段攻击。这是一起更复杂的跨项目污染：

3月19日，威胁组织TeamPCP利用trivy-action的pull_request_target工作流配置错误，窃取了Aqua Security机器人的个人访问令牌。他们用该令牌重写发布标签，向Trivy——一款广泛使用的开源安全扫描器——注入凭证收集器。

3月24日，LiteLLM的CI/CD管道正常运行Trivy扫描。被污染的Trivy动作窃取了LiteLLM的PyPI发布令牌，攻击链完成闭环。

安全工具本身成为攻击载体。这是最讽刺的供应链攻击形态。

为什么你的日志发现不了

传统安全监控的设计假设正在失效。

第一，根感染点位于第三方。Vercel的日志只会显示"合法的OAuth登录"，不会标记Context.ai的泄露。信任继承在日志层面是不可见的。

第二，攻击行为符合正常用户模式。Vercel员工的操作——用工作账号注册AI工具——是数百万开发者的日常。没有异常登录地点，没有暴力破解痕迹，没有触发告警的阈值。

第三，静态敏感分类的滞后性。环境变量在创建时被标记为"非敏感"，但六个月后的访问路径可能已完全改变。集成授权范围扩大、新服务加入网络、OAuth令牌被更多系统继承——这些动态变化不会被静态标签捕捉。

Hudson Rock的发现时间线暴露了响应缺口：信息窃取日志早在公开披露前一个多月就已存在。如果Vercel能实时获取第三方泄露情报，整个攻击链可以在第一步被切断。

2026供应链攻击的新形状

四个事件共同勾勒出威胁形态的迁移：

攻击目标从"你的代码"转向"你的集成"。 weakest link（最薄弱环节）不再是内存安全漏洞或依赖项版本，而是第三方服务之间的信任关系。

攻击媒介从"技术缺陷"转向"配置债务"。Trivy事件中的pull_request_target误配、Axios事件中的遗留令牌共存——这些都是已知风险，但在快速迭代的工程实践中被持续累积。

攻击窗口从"瞬时利用"转向"长期潜伏"。恶意npm版本在官方仓库中存在数日，被下载次数未被披露；Trivy的污染标签在被发现前已完成多轮CI/CD调用。供应链攻击的检测延迟正在以"天"为单位计量。

防御责任从"单方控制"转向"网络协同"。Vercel无法单方面阻止Context.ai的泄露，LiteLLM无法预审Trivy-action的每个发布标签。安全边界正在变得模糊且相互依赖。

现有安全栈为何失效

每个事件都暴露了"正确配置"与"有效防御"之间的鸿沟。

Axios配置了OIDC，但遗留令牌未被清理。安全团队引入了现代认证机制，却没有退役旧机制——这种"叠加式"安全改造创造了绕过路径。

Trivy-action使用了标准的GitHub Actions工作流，但pull_request_target的权限模型在fork场景下存在固有陷阱。这是一个被文档记录的风险，却在实际配置中被反复忽视。

Vercel的环境变量分类策略基于创建时的风险评估，而非运行时的访问图分析。当OAuth令牌的网络扩展时，"非敏感"变量的暴露面同步扩大，但分类标签保持不变。

共同模式：安全控制的设计假设与攻击者的实际行为之间存在系统性错位。我们防御的是"异常登录"和"漏洞利用"，而攻击者提供的是"正常集成"和"信任继承"。

需要改变的三个实践

第一，OAuth令牌的生存周期管理。当前行业惯例是"按需授权、长期有效"。需要转向"最小权限、短期凭证、持续验证"。具体而言：区分用户授权与机器授权，为CI/CD场景强制使用短期令牌，建立令牌使用行为的异常基线。

第二，第三方风险的实时监控。Vercel事件的教训是：你的安全态势取决于你最不透明的供应商。需要建立泄露情报的自动化摄入机制，将Hudson Rock这类数据源集成到响应流程中，在攻击者利用前完成凭证轮换。

第三，敏感数据的动态分类。放弃"敏感/非敏感"的二元标签，转向基于访问路径的风险评分。一个环境变量的敏感度取决于：哪些身份可以访问它、这些身份的信任来源、访问路径上的控制强度。这个评分需要随架构变化自动更新。

工程组织的行动清单

如果你管理着25-40人的技术团队，接下来两周可以做的具体事项：

审计OAuth授权清单。导出组织内所有活跃的第三方集成，按权限范围排序。识别那些拥有"读取代码仓库""访问生产环境"等高级权限、但业务价值不明确的集成。优先审查三个月内新增的工具——Vercel事件的模式。

扫描长期有效令牌。检查CI/CD配置中是否存在超过90天未轮换的令牌或密钥。特别注意那些"临时添加、忘记清理"的遗留凭证——Axios事件的根源。

验证安全扫描的覆盖范围。如果你的流水线依赖Trivy、Snyk或类似工具，确认它们的更新机制。被污染的扫描器会报告"一切正常"，这是最危险的虚假安全感。

测试事件响应的第三方依赖。模拟场景：你的某个SaaS供应商明天宣布数据泄露，你需要多长时间完成凭证轮换、隔离受影响系统、评估数据暴露范围？如果答案超过4小时，流程需要优化。

供应链攻击的形态已经改变。2026年的威胁模型必须把"正常集成的异常继承"放在核心位置——不是作为边缘风险，而是作为主要攻击面。