1.1 什么是软件供应链#

软件供应链（Software Supply Chain）是指从源代码到最终运行产物的完整路径——每一个环节都可能被攻击者利用：

传统安全关注的是运行时（F）的防护——WAF、EDR、微隔离。供应链安全关注的是到达运行时之前的路径（A→E）是否可信。如果构建产物在到达部署环境之前就已经被植入后门，运行时的所有防护都将失效。

1.2 npm生态的信任模型#

npm生态的信任模型建立在几个隐含假设上：

供应链攻击的本质，就是打破这些隐含假设。

1.3 GitHub Actions CI/CD基础#

理解TanStack事件需要了解GitHub Actions的几个关键概念：

• pull_request触发器：在Fork的PR中运行，使用Fork的代码和Fork的CI配置，没有Base仓库的写权限——安全
• pull_request_target触发器：在Fork的PR中运行，但使用Base仓库的CI配置和密钥——危险，因为Fork的代码在Base仓库的信任上下文中执行
• GITHUB_TOKEN：临时token，受permissions:约束，PR触发的workflow默认只有read权限
• OIDC token：通过id-token: write权限获取的临时身份令牌，用于npm trusted publishing
• actions/cache：CI缓存，scope为per-repository，post-job save不受permissions:约束

1.4 当前态势：供应链攻击演进#

供应链攻击在过去三年经历了从”包级别”到”CI/CD级别”再到”生态级别”的演进：

关键趋势：攻击者不再满足于单个漏洞的利用，而是将多个已知漏洞串联成链式攻击，每个漏洞单独都不足以完成攻击，但组合后可以跨越多道信任边界。

2.1 攻击全景#

攻击者将三个已知漏洞串联，每个单独都不足以完成攻击，但三者组合跨越了三道信任边界：

2.2 第一链：Pwn Request#

bundle-size.yml使用了pull_request_target触发器，对Fork的PR自动运行，并在该上下文中checkout了Fork的合并代码并执行构建：

1
on:
2
  pull_request_target:
3
    paths: ['packages/**', 'benchmarks/**']
4
jobs:
5
  benchmark-pr:
6
    steps:
7
      - uses: actions/checkout@v6.0.2
8
        with:
9
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
10
      - uses: TanStack/config/.github/setup@main
11
      - run: pnpm nx run @benchmarks/bundle-size:build

攻击者创建了一个Fork（zblgg/configuration，故意重命名以规避Fork列表搜索），提交了包含3万行捆绑JS载荷的恶意commit，然后以[skip ci]前缀压制CI，再通过PR将恶意代码引入pull_request_target的执行上下文。

关键问题：pull_request_target绕过了首次贡献者审批门控。PR的pull_request触发的工作流被正确阻止了，但pull_request_target的工作流直接放行。

2.3 第二链：Cache投毒#

恶意代码vite_setup.mjs被精心设计，向pnpm store目录写入数据，使用的key恰好匹配正式release.yml工作流会查找的key：

1
Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')}

当benchmark-pr任务结束，actions/cache@v5的post-step将已被投毒的pnpm store保存到该key下。当release.yml下次在main分支上运行时，其Setup Tools步骤恢复了被投毒的缓存条目。

这是GitHub Actions的已知设计问题，由Adnan Khan在2024年5月公开文档化。核心矛盾：

• actions/cache@v5的post-job save不受permissions:约束——Cache写入使用Runner内部token，不是GITHUB_TOKEN
• 设置permissions: contents: read不会阻止Cache写入
• Cache scope是per-repo的，pull_request_target运行和main上的push共享同一Cache scope

2.4 第三链：OIDC令牌内存提取#

release.yml声明了id-token: write（合法的npm OIDC可信发布所需）。当被投毒的pnpm store恢复到Runner后，攻击者控制的二进制文件被调用：

1
# 攻击流程（简化）
2
# 1. 定位GitHub Actions Runner.Worker进程
3
runner_pid = find_process("/proc/*/cmdline", "Runner.Worker")
4

5
# 2. 读取进程内存映射
6
maps = read_file(f"/proc/{runner_pid}/maps")
7
mem  = read_file(f"/proc/{runner_pid}/mem")
8

9
# 3. 从内存中提取OIDC令牌
10
oidc_token = extract_oidc_token(maps, mem)
11

12
# 4. 直接POST到npm registry
13
requests.post("https://registry.npmjs.org/-/npm/v1/tarball",
14
              headers={"Authorization": f"Bearer {oidc_token}"})

这绕过了工作流中定义的”Publish Packages”步骤——恶意代码在测试/清理阶段就铸造了OIDC令牌并直接发布。

这是与2025年3月tj-actions/changed-files妥协事件完全相同的内存提取技术，攻击者甚至使用了原文的Python脚本（保留了归属注释）。

2.5 恶意载荷行为#

当开发者或CI环境对受影响版本执行npm install时：

外泄通道值得注意：使用Session/Oxen Messenger的文件上传网络（filev2.getsession.org），端到端加密，没有攻击者控制的C2——因此只能通过IP/域名阻断，无法通过内容检测拦截。

自传播机制：通过registry.npmjs.org/-/v1/search?text=maintainer:<user>枚举受害者维护的其他包，然后重新发布注入版本。这意味着一个受感染的CI环境可以污染整个npm生态中该维护者的所有包。

2.6 时间线#

3.1 六大攻击手法对比#

3.2 为什么Cache投毒特别危险#

GitHub Actions的Cache设计存在一个根本性的信任边界问题：

• Cache scope是per-repository的，不是per-workflow或per-trigger的
• pull_request_target运行使用base仓库的Cache scope
• actions/cache的post-job save不受permissions:约束
• 这意味着Fork PR的CI可以向Main分支发布CI使用的Cache写入任意数据

这不是TanStack特有的问题——任何使用pull_request_target + actions/cache的仓库都面临相同风险。

3.3 信任链视角#

从信任链的角度看，供应链攻击的本质是信任的传递与滥用：

每一步都是信任的传递，每一步都假设上一步是干净的。攻击者的策略是找到信任链中最弱的一环，然后沿着链向下渗透。

4.1 GitHub Actions加固#

1
# GitHub Actions安全加固清单
2
github_actions_hardening:
3
  pull_request_target:
4
    - 规则: 绝不在pull_request_target中checkout Fork代码
5
    - 规则: 绝不在pull_request_target中运行Fork控制的构建命令
6
    - 规则: 如必须使用，仅用于只读操作（标签、评论）
7
    - 替代: 使用pull_request触发 + 首次贡献者审批
8

9
  cache:
10
    - 规则: 不在pull_request_target工作流中使用actions/cache
11
    - 规则: 如必须使用，设置cache-key前缀隔离PR和Main的Cache
12
    - 规则: 定期审查和清除Cache条目
13
    - 替代: 使用actions/upload-artifact + download-artifact（scope为workflow run）
14

15
  oidc:
16
    - 规则: 限制id-token: write仅用于实际发布步骤
17
    - 规则: 将发布步骤与测试步骤分离为独立job
18
    - 规则: 考虑添加provenance-source-verification检测异常发布路径
19
    - 替代: 短期classic token + 手动审批
20

21
  actions:
22
    - 规则: 所有第三方Action引用固定到SHA而非tag
23
    - 规则: 定期审计所有使用的第三方Action
24
    - 规则: 使用StepSecurity的harden-runner Action限制网络和文件系统访问

4.2 npm生态防护#

1
npm_ecosystem_defense:
2
  安装时:
3
    - 使用npm audit持续扫描已知漏洞
4
    - 部署Socket.dev或Phylum等供应链安全工具
5
    - 在CI中添加package-lock.json完整性校验
6
    - 监控optionalDependencies中的异常github:引用
7

8
  发布时:
9
    - 使用npm OIDC trusted publishing替代长期token
10
    - 配置npm provenance签名
11
    - 限制scope的maintainer列表（减少凭据暴露面）
12
    - 发布后自动验证tarball内容与预期一致
13

14
  响应时:
15
    - 建立npm publish实时监控和告警
16
    - 准备应急deprecation脚本
17
    - 与npm安全团队建立快速沟通渠道
18
    - 受影响后立即轮换所有可达凭据

4.3 凭据轮换清单#

任何在2026-05-11安装了受影响TanStack版本的主机，应视为可能被入侵，需轮换：

1
credential_rotation:
2
  云平台:
3
    - AWS: 所有AccessKey + IMDS可达的Secrets Manager值
4
    - GCP: 所有Service Account Key + metadata可达的凭据
5
    - Kubernetes: 所有ServiceAccount Token
6
    - Vault: 所有Token和动态凭据
7

8
  开发平台:
9
    - GitHub: Personal Access Token + SSH Key
10
    - npm: 所有发布token
11
    - Git: .git-credentials中存储的所有凭据
12

13
  基础设施:
14
    - SSH: ~/.ssh/下所有私钥
15
    - CI/CD: 所有CI环境变量中的密钥

4.4 “信任中断”原则#

纵深防御的本质不是在每一层都加锁，而是在信任链中插入不信任的断点：

5.1 供应链安全是云安全的阿喀琉斯之踵#

云安全的所有技术——零信任、微隔离、EDR、CNAPP——都建立在一个隐含假设上：你部署的代码是你以为的代码。当这个假设被打破，所有上层防护都是空中楼阁。TanStack事件表明，攻击者不需要突破你的云安全体系，只需要在你信任的包里植入一行代码。

5.2 “信任传递”是核心问题#

从Fork代码到Base仓库Cache，从Cache到发布Runner，从Runner到npm registry——每一步都是信任的传递，每一步都假设上一步是干净的。攻击者的策略永远是找到信任链中最弱的一环，然后沿着链向下渗透。

5.3 防御者需要”信任中断”#

纵深防御的本质不是在每一层都加锁，而是在信任链中插入不信任的断点——Cache恢复后校验hash、OIDC铸造时验证来源、npm install后验证签名。每一个断点都是对”上一步是干净的”这个假设的挑战。

5.4 开源生态的系统性风险#

TanStack事件暴露了npm生态的几个结构性问题：

• npm的unpublish政策：如果包有依赖者就不能unpublish，导致恶意tarball只能等待npm安全团队服务端移除，增加了数小时的暴露窗口
• OIDC trusted publishing的盲区：一旦配置，workflow中任何代码路径都可以铸造发布令牌，没有per-publish review
• 维护者凭据的爆炸半径：7个maintainer的npm scope意味着7个独立的凭据窃取目标，但影响范围相同

这些问题不是TanStack能独自解决的，需要npm/GitHub生态层面的系统性改进。