TanStack 披露一起复杂的 npm 供应链攻击事件， 42 个包遭入侵

此次TanStack事件是一次典型且技术细节复杂的软件供应链攻击，为我们理解当前开源生态的安全态势提供了极佳的案例。以下从几个层面进行解读：

攻击者并未直接窃取npm发布凭证，而是利用了CI/CD系统中的信任链条和权限漏洞，其技术路径值得深入剖析：

起点：利用“合法”入口：攻击始于一个看似无害的拉取请求（PR）。关键在于，目标仓库的GitHub Actions工作流错误地配置了 pull_request_target 模式。该模式默认拥有对主仓库代码的更高权限，允许攻击者提交的代码在受信任的上下文中执行。
核心：缓存投毒：攻击者通过该高权限工作流，篡改了GitHub Actions的共享缓存。这部分缓存被设计为在不同工作流和PR之间共享以提升效率，但成了攻击的跳板。恶意文件被植入缓存。
引爆：污染发布管道：当维护者后续合并一个完全无关的、正常的PR时，发布流程被触发。此时，受污染的缓存被加载，恶意代码在发布管道的测试或准备阶段执行。由于发布管道本身已被授予了可信的OIDC令牌（用于向npm证明身份），攻击者便利用该令牌将恶意版本直接发布。
本质：权限滥用而非凭证泄露：正如报告强调，npm令牌本身并未被盗。攻击者“劫持”了CI/CD工作流的合法身份和权限，完成了恶意发布。这揭示了 “身份”与“凭证”分离后的新风险——即使你保管好了长期令牌，系统赋予自动化流程的短期信任权限同样能被利用。

注入的恶意软件设计精密，构成了完整的攻击闭环：

自动执行：利用npm的生命周期脚本（如postinstall），在受害者安装受影响的包时自动运行，无需用户交互。
广泛窃取：扫描并窃取开发环境和CI服务器中的高价值凭证，覆盖AWS、GCP、Kubernetes、GitHub、SSH密钥等关键基础设施的访问权限。
自我传播：具有“蠕虫”特性。它会枚举受害者账户维护的其他npm包，将自身恶意负载复制并发布到这些包的新版本中，从而实现指数级扩散。

TanStack事件并非孤例，它是一系列针对开源供应链攻击的缩影，其背后反映的深层趋势包括：

攻击面转移：攻击目标从直接的代码仓库或开发者凭证，转向了构建、测试、发布的自动化流水线本身。CI/CD系统、包管理器的缓存、依赖解析过程等，都成了需要重点防护的“新边界”。
信任机制的双刃剑：像OIDC可信发布这样的安全最佳实践，旨在消除静态的长期令牌，提高安全性。但本次事件表明，如果授予该信任的工作流本身被入侵，攻击者仍能获得等效的发布权限。安全机制需要配套的上下文（如工作流来源）验证。
缓存风险常被忽视：许多团队并未充分意识到，像GitHub Actions这类服务的缓存默认是共享的，且缓存内容可能被恶意写入。缓存应被视为软件供应链的一部分加以管控。
检测与响应的速度：此次攻击被迅速发现（20分钟内），部分原因是恶意软件意外导致了构建失败。这提示我们，完备的监控和异常检测机制至关重要，不能仅依赖偶然的失败。

面对不断升级的威胁，安全防线正在多层面加固：

项目层面：TanStack在事后采取了多项措施，如清除缓存、固定Actions版本到不可变SHA、添加所有者验证，这是其他项目应学习的自查范本。
平台层面：GitHub等平台需要持续强化默认安全配置，并为用户提供更安全的工作流模板和权限管控工具。
行业协作：推广 SLSA、 Sigstore 等框架，通过标准化的源码溯源、构建产物签名，提升整个供应链的透明度和可验证性。

**总结而言，TanStack事件是一个强烈的警示：在高度依赖自动化、云原生工具和开源组件的现代软件开发中，安全防护必须从保护静态的“物品”（代码、凭证），扩展到治理动态的“关系”与“流程”（工作流权限、

深度分析