AI 工具供应链安全清单：从 Vercel、Nx Console 两起事件提炼的 8 条防御原则

blog144 写过 Vercel 入侵的完整攻击链复盘——攻击者通过 Lumma Stealer 拿到 Context AI 员工凭证 → 偷出 OAuth token → 横向到 Vercel 内部系统 → 窃取客户环境变量。这篇文章不再讲事件本身，而是反过来问一个问题：如果你是独立开发者或小团队的 owner，怎么把这件事的教训变成可执行的防御 checklist？

我对照 Trend Micro、Ox Security、VentureBeat 在 4 月底到 5 月上旬的事后分析，先从 Vercel 事件提炼出 7 条核心原则，再从下面要讲的 Nx Console 事件补上第 8 条，一共 8 条。每条都附”具体怎么做”和”1 小时内能完成”的实操步骤。

为什么要从这个角度写

Vercel 事件的一个细节值得反复读：

一名 Vercel 员工用他的 Vercel Enterprise Google 账户登录 Context.ai，给了 Context AI 对其 Google Drive 的完整读权限。

这一步看起来无害——“用 Google 账号登录第三方 AI 工具”是每个开发者每周都在做的事。但攻击者拿到 Context AI 的访问权后，这个 OAuth token 就是企业 Google Drive 的钥匙。Vercel 内部一份 IAM 配置文档恰好在那个 Drive 里。

Vercel CEO Guillermo Rauch 在 X 上明确说：这次攻击者的”异常速度”归因于 AI 加速——攻击者用 AI 工具快速分析窃取的数据、定位高价值目标、生成合规但恶意的 OAuth 请求。这是 2026 年讨论”AI 加速对抗性工具链”的早期标志性案例。

这两个细节意味着：OAuth 攻击不是协议漏洞，是治理漏洞。协议本身没问题，但用户的授权习惯是问题。修协议没用，得修人和流程。

另一个角度的同类事件：Nx Console（攻击源是 IDE 扩展本身）

Vercel 事件是”第三方 AI 工具被攻破，殃及授权方”。但供应链攻击还有一个更贴近开发者日常的入口——你每天用的 IDE 扩展和 CLI 工具本身被投毒。2026 年 5 月的 Nx Console 事件就是教科书级案例。

时间线很短但破坏力惊人：

• 2026-05-18 14:36-14:47 CEST（仅 11 分钟窗口），恶意构建的 nrwl.angular-console v18.95.0 被推到 VS Code Marketplace，这个扩展有 220 万安装量
• 开发者只要打开任意工作区，扩展就在数秒内从官方 nrwl/nx 仓库里一个隐藏的孤立提交（dangling commit）拉取并执行 498 KB 混淆 payload
• 这是一个多阶段凭证窃取工具，系统性搜刮 1Password 保险库、Anthropic Claude Code 配置、npm / GitHub / AWS 凭证，还扫描文件系统和 /proc 内存找嵌入的密钥
• 官方初报 28 次安装，后续修正为 6000+ 次安装（含 41 次来自 Open VSX）

根因链条值得对照 Vercel 事件看：一名贡献者的机器被入侵 → GitHub PAT 被盗 → 拿到 nrwl/nx 仓库 push 权限 → 进而拿到 VS Code Marketplace 发布凭证（VSCE_PAT）→ 发布恶意版本。最阴险的一步是 payload 集成了完整 Sigstore（Fulcio 证书签发 + Rekor 透明日志 + SLSA provenance），结合窃取的 npm OIDC token，能让攻击者发布带合法密码学签名的恶意 npm 包——签名校验这道防线被绕过了。

这件事和 Vercel 事件的共同点很清楚：不是协议或工具有 bug，是凭证（PAT / 发布 token）被过度信任、缺乏隔离和轮换。区别在于入口——Vercel 是”你授权了恶意工具”，Nx 是”你信任的工具被人冒名顶替”。两个入口都得防，所以下面在 7 条 OAuth 原则之外，专门加了第 8 条针对 IDE 扩展与 CLI 工具。

补充：这已是 Nx 生态一年内第二次大型供应链事件。2025 年 8 月的 “s1ngularity” 攻击通过恶意 Nx npm 包（20.9.0-21.8.0）从 1079 台开发者机器窃取 2349 个凭证，并专门针对 Claude / Gemini / Q 等 AI CLI 工具的配置和 token——AI 工具的高权限正在成为攻击者的明确目标。

8 条防御原则

原则 1：OAuth 授权默认拒绝（最高优先级）

最关键的一条。Google Workspace 和 Microsoft 365 都有一个单一管理员开关，可以把”用户能否授权第三方应用”切到默认拒绝——任何新 OAuth 集成必须管理员审批。

为什么这条最重要：Vercel 事件如果开启了 default-deny，那个员工根本不能给 Context AI Trial 授权，整个攻击链在第一步就被切断。

怎么做：

• Google Workspace：Admin Console → Security → Access and data control → API Controls → Manage Third-Party App Access，把默认值切到 “Restrict access”，再用受信任应用列表（Trusted apps list）逐个白名单已审批过的应用。按钮名以最新 UI 为准
• Microsoft 365：Entra Admin Center → Enterprise applications → Consent and permissions → “Do not allow user consent”

1 小时内：登录管理员账号、切换那个开关、把当前已授权的应用列表导出审查一遍。

原则 2：OAuth scope 最小权限

每个 AI 工具接入时都会要求一组 OAuth scope。开发者习惯性点”全部允许”，因为：

• 弹窗设计就是诱导一键通过
• 拒绝部分 scope 后工具可能某些功能不能用，开发者懒得调试

真实代价：你授权的不是”AI 工具读取文档”，是”这家公司的整个安全姿态接管了你的对应数据”。

怎么做：

• 接入新工具时，逐条审查 scope，问”这个工具真的需要 drive.readonly 还是只需 drive.file（仅它创建的文件）？”
• 优先选有 fine-grained scope 设计的工具（如 GitHub Apps 的逐仓库授权，远好于 OAuth 全账号授权）
• 如果工具只支持”全部或拒绝”，用辅助账号授权，主账号永不接入

1 小时内：登录主要 SaaS 平台（Google / Microsoft / GitHub / Atlassian），用导出工具拉出当前 OAuth 授权列表，标记每个”为什么需要这个 scope”。

原则 3：把 AI 工具采购当作第三方风险决策

Context AI Trial 当时是一个免费自助注册，没有任何采购审批。一个员工随手试用，结果牵动了整个公司的安全。

核心问题：AI 工具的采用速度远超传统 SaaS 的采购流程，多数公司的安全/合规审批跟不上。

怎么做：

• 对独立开发者：建一个个人的”AI 工具风险登记”——每个新工具记录授权 scope、用什么账号、风险评估。这个列表本身就是审计基础
• 对小团队：把”AI 工具试用”加入轻量审批流程——不需要复杂表单，但至少有一个共享文档记录”谁在用什么”
• 绝不用主账号试用未知 AI 工具——用独立的”试用账号”或邮箱别名

1 小时内：列出过去 6 个月你授权过 OAuth 的所有 AI 工具，对每个回答”现在还在用吗？信任度有变化吗？“

原则 4：密钥分级（Sensitive 标记）

Vercel 入侵中真正流出的是环境变量里的 API key——攻击者拿到的不是源码，是 OPENAI_API_KEY、AWS_ACCESS_KEY、数据库连接串。

很多平台（Vercel 自己、Netlify、Cloudflare）都支持把环境变量标记为 “Sensitive”，开启后：

• 写入后变量值不能再被读取（只能整体替换）
• API/CLI 输出时显示为 ***
• Web UI 也不显示

怎么做：

• 所有以 _KEY / _SECRET / _TOKEN / _PASSWORD 结尾的环境变量全部勾选 Sensitive
• 在 Vercel：Project Settings → Environment Variables → 找到变量 → 编辑 → 勾选”Sensitive”
• 在 GitHub Actions：用 Secrets 而非 Variables（Variables 是明文的）
• 在 Cloudflare Workers：用 wrangler secret put，不是普通的 vars

1 小时内：登录每个部署平台，把环境变量列表导出来，把所有含敏感关键词的强制标 Sensitive。

原则 5：托管设备隔离（高敏感数据访问）

Vercel 事件的入口是员工在个人设备上下载游戏外挂，被 Lumma Stealer 感染。如果工作访问只允许在公司 managed device 上进行，Lumma 即使感染个人设备也接触不到企业 OAuth token。

对独立开发者也适用——把工作环境和娱乐环境分开：

怎么做：

• 工作账号只在工作机器上登录（用 macOS 多用户切换 / Windows 多账户 / 独立物理机）
• 浏览器 Profile 分隔：工作 Profile 不装游戏插件、不浏览未知网站
• Mobile 端不要登录工作账号到第三方 App（特别是不知名的”提升效率”类应用）

1 小时内：检查个人主电脑上是否登录了任何工作 SaaS 账号——如果有，把它们迁到独立浏览器 Profile 或独立设备。

原则 6：定期 OAuth 授权 Revoke 审计

授权过了不管，过期账号不清，是 OAuth 治理最大盲区。一个员工授权过 50 个工具，3 年后他离职——其中一半的工具凭证可能仍然有效。

怎么做：

• 每季度审计一次主要平台的 OAuth 授权列表
• 直接打开 https://myaccount.google.com/permissions 看 Google 端
• GitHub：Settings → Applications → Authorized OAuth Apps
• 任何”超过 90 天没用过”的工具，直接 Revoke
• 任何”我已经不记得为什么授权”的工具，立刻 Revoke

1 小时内：跑一遍主要平台的 OAuth 列表，每个的最近使用时间一眼可见——清理掉”上次使用 > 90 天”的全部。

原则 7：监控异常 OAuth 行为

最被忽视的一条——授权后不监控，等到出事才知道。Vercel 事件中有客户报告凭证泄漏早于官方披露日期（详见 Ox Security 的时间线复盘），可疑信号其实早就出现了，只是没人在看。

怎么做：

• Google Workspace：Admin Console → Reports → Audit logs → Token 标签页，定期看”哪些 app 在拉数据”
• 接入 Have I Been Pwned 监控你工作邮箱
• 用 GitHub Secret Scanning 监控仓库里是否漏了密钥
• 设置 webhook 通知：任何新 OAuth 授权 → 邮件/Slack 告警
• 部署平台如 Vercel / Cloudflare 都有”环境变量被读取”的审计日志，定期审查

1 小时内：把上面 4 个监控渠道都打开（多数都是免费的），订阅告警邮件。

原则 8：IDE 扩展与 CLI 工具的凭证隔离

前 7 条都在防”你主动授权出去”的风险，Nx Console 事件提醒我们还有一类：你被动信任的工具被冒名顶替。IDE 扩展和 CLI 工具有两个危险特征——自动更新（你不会逐版本审查）、和高权限运行环境（能读你机器上所有密钥、配置、/proc 内存）。

怎么做：

• 关闭高权限扩展的自动更新，至少对能执行任意代码的扩展（构建工具、AI 助手、Git 集成）手动确认更新。VS Code：settings.json 里设 "extensions.autoUpdate": false，更新前看一眼版本号和发布时间是否异常
• PAT / 发布凭证最小权限 + 短有效期：GitHub PAT 用 fine-grained token 限定到具体仓库，npm token 用自动过期的，绝不用”全账号、永不过期”的经典 PAT——Nx 事件正是经典 PAT 被盗后畅通无阻
• AI CLI 工具的配置目录单独保护：~/.claude、~/.config/gcloud 这类目录里有高权限 token，确保它们不在任何会被扩展扫描的工作区路径下；s1ngularity 攻击就是专挑这些目录
• 遇到供应链事件，第一时间轮换”那台机器能碰到的所有凭证”——不要只删恶意包，payload 可能已经把密钥发走了

1 小时内：列出你装的能执行代码的 IDE 扩展和全局 CLI 工具，关掉它们的自动更新；检查 GitHub / npm 上有没有”全权限、永不过期”的 token，能换成 fine-grained 的全换掉。

1 小时审计 checklist（直接照做）

汇总 8 条原则的实操步骤，按”先后顺序”排好：

□  [10 分钟] 打开 Google Workspace Admin，把"用户授权第三方 OAuth"切到默认拒绝
□  [10 分钟] 同样操作 Microsoft 365（如果用）
□  [10 分钟] 访问 https://myaccount.google.com/permissions
            → Revoke 所有 90 天未用 / 已不记得为什么授权的应用
□  [10 分钟] GitHub Settings → Applications → 审 OAuth Apps，Revoke 不用的
□  [10 分钟] Vercel / Netlify / Cloudflare → 把所有含 KEY/SECRET/TOKEN 的环境变量强制标 Sensitive
□  [10 分钟] 整理"AI 工具风险登记"文档：列当前所有 AI 工具 + scope + 用的账号
□  [10 分钟] 关掉高权限 IDE 扩展 / CLI 工具的自动更新；把 GitHub / npm 上"全权限永不过期"的 token 换成 fine-grained

不到 1 小时，能把”工具供应链攻击面”砍掉 80%。

几个常见误解

”我又不是 Vercel 那种大公司，攻击者不会盯我”

错。AI 加速攻击的核心特征是规模化——攻击者不再”挑选高价值目标”，而是用 AI 批量扫描所有 OAuth 泄漏，按价值排序。

独立开发者的特征反而让你更容易被批量攻击：

• 没有专职安全团队监控异常
• 习惯性把生产密钥放本机
• 偏爱新 AI 工具（很多是 Trial 期、安全姿态弱）
• 一旦泄漏，攻击者直接拿 AWS / Stripe / 个人邮箱去变现

Vercel 之所以是受害者，不是因为它是高价值目标——是因为攻击者的”自动化漏斗”里它恰好命中。你的小项目可能也在某个漏斗里。

“OAuth 已经是密钥更安全的替代了”

OAuth 设计初衷是”不用密码就能授权”，但它没解决”过度授权”问题。原始密码 = 100% 访问，OAuth full-access scope = 同样的 100% 访问，只是看起来更现代。

防御的关键不是”用不用 OAuth”，是”OAuth scope 控不控制得住”。

“Sensitive 标记只是 UI 而已”

错。Sensitive 标记是真正的写入后不可读——一旦标记，平台 API 也读不出来。这是审计追溯时唯一可信的证据：哪些值是从来没被读出过的。

长期防御思路

这 8 条原则本质上都是减少攻击面——但攻击面只会越来越大（每月都有新 AI 工具、新扩展发布）。长期防御得再加一条压舱原则：承认防御做不到 100%，把检测和响应做扎实。

具体讲：

• 接受密钥总会泄漏——做轮换机制（30 天一轮），泄漏后立刻无效
• 接受 OAuth 总有过度授权——做使用日志监控，异常行为告警
• 接受 AI 工具总有恶意可能——做数据分级，关键数据永远不接入未审计 AI
• 接受 IDE 扩展和 CLI 工具会被投毒——关高权限扩展的自动更新，遇到供应链事件先轮换凭证再排查

这套思路不新，但 AI 工具的爆发把它从”企业安全的奢侈品”变成了”独立开发者的必需品”。

给独立开发者的最终建议

如果你是个人或 2-5 人小团队，按这个优先级落地：

1. 本周内：跑完上面的 1 小时审计 checklist
2. 本月内：把所有现役 AI 工具的 OAuth scope 重审一遍，能降级的全部降级
3. 每季度：重复审计 + 清理新累积的授权
4. 遇到入侵新闻：花 15 分钟看是不是涉及你授权过或安装过的工具——授权类的立刻 Revoke，扩展/CLI 类的立刻轮换那台机器能碰到的凭证

最便宜的安全投入是”不授权那些你不需要的 scope”——这一条原则就能省下 90% 的事后补救成本。

延伸阅读：

• Vercel 入侵事件完整复盘 - 攻击链每一步的技术细节
• AI Agent 安全治理 - 更宏观的 Agent 安全方法论
• Trend Micro 官方分析 - 安全厂商对事件的技术拆解
• Ox Security: Vercel Breach 分析 - 攻击经济和 BreachForums 后续追踪
• VentureBeat: OAuth Gap 报告 - 行业级 OAuth 治理盲区分析
• The Hacker News: Nx Console 18.95.0 事件 - IDE 扩展供应链攻击的完整时间线
• Nx 官方 s1ngularity 复盘 - 厂商自述 2025 年事件的根因与响应