AI 重构软件供应链安全:既是“矛”,也是“盾”

过去，供应链安全被我们训练成了一个很朴素的动作：用 SCA 工具 扫 pom.xml、扫 package.json、扫制品，比对 CVE 库，出报告。开源组件是“别人写的、我在用的、可能有洞的代码”——定义清晰，边界清晰。但是现在，两个“清晰”被AI同时打碎了。

一方面，我们开始信任并自动执行一批从来没进过依赖清单的东西；另一方面，我们第一次有了一个能帮我们消化海量告警的助手。攻击面和防御方法被同一项技术同时改写。

先问一个问题：什么东西才算我们的“供应链”？

传统答案是——被打包进制品的第三方代码。但真正的定义应该更宽：凡是“来源不完全可控、会被自动执行、且被默认信任”的东西，都是供应链。

2024 年的 xz-utils 后门（CVE-2024-3094）就是很好的例子：攻击者花了将近两年，以贡献者身份混进项目、骗到维护权限，再把后门埋进发布包。全程没有一行“漏洞代码”，被攻破的是信任链本身。

而 AI 时代，这样的东西多了很多，并且大多没有 SBOM、没有准入、不在扫描器的覆盖范围内：

它是应用行为的一部分，却几乎没人给它做版本管理、评审和注入审计。一段被污染的系统提示，可以让整个 Agent 的行为偏移，而 Git 里可能根本没有它的变更记录。

这是我个人认为今年最被低估的一类。一个第三方 skill 或 MCP server，装上就带着 Agent 的全部权限运行——读本地文件、发网络请求、调用其它工具。

2025 年 Invariant Labs 披露的“工具投毒”（tool poisoning）就很典型：恶意指令藏在 MCP 工具的描述文本里，模型读到就执行，而界面上什么都看不到；更阴险的是“先审核通过、事后偷改描述”的 rug-pull。

它比一个 npm 包危险得多——npm 包起码还躺在依赖树里、SCA 看得见。好在这块不算完全裸奔：Invariant Labs 披露的同时就放出了 mcp-scan，运行时护栏、MCP 网关、skill 层的静态权限分析也都开始出现。真正的缺口不在“有没有工具”，而在这些检测还远没成为“装之前必须过一遍”的默认动作——手法已经公开，准入却还没跟上。

大模型会稳定地“幻觉”出并不存在的包名。2025 年一项针对主流模型的研究发现，生成代码里引用不存在依赖的比例，商业模型约 5%、开源模型可高达 20% 以上，而且同一个假包名会被反复生成——这就给了攻击者可乘之机：把这些高频包名抢注上传，一次投毒就成了。

这个新词叫 slopsquatting。它不是理论：已有研究者把某模型反复推荐的一个包名注册下来，几个月内被拉取上万次。我们让 AI 帮忙写代码，它可能顺手就把一个后门包名写进import。

我们在给 Agent Skill 做安全检测时，一个很直接的体感是：这些“AI 原生依赖”的危险性，恰恰来自它们太方便、太不像“依赖”。没有人会因为装一个 skill、拉一个模型而召集一次安全评审，但它们拿到的权限和信任，远超一个普通的开源库。

所以，供应链的“清单”必须扩容。SBOM 之外，我们需要一份 AIBOM——把模型、数据集、prompt、skill、MCP、乃至 AI 生成代码的来源，都纳入可追溯、可准入的范围。

好在标准侧已经在动：CycloneDX 有了 ML-BOM，SPDX 3.0 加了 AI 与数据集的描述能力，OpenSSF 也在推模型签名。工具会逐步跟上，但前提是我们得认识到这一层“依赖”。

这里有个被长期误解的点：供应链安全真正的痛，从来不是“扫不出来”，而是“扫出来一堆，处理成本太高”。任何用过 SCA 的团队都懂这种绝望：一次扫描几百上千条告警，可真正需要动手的没几条。

这里要先澄清一件事：这些“用不上”的告警，严格讲并不是误报。SCA 报出“依赖里有一个带 CVE 的组件”，这个判断是准确的——问题在于扫描原理决定了它只能做到组件级比对，天生判断不了“代码到底有没有走到那段有问题的路径上”。

以 Spring4Shell（CVE-2022-22965）为例：用了相关 Spring 版本的应用无数，但真正满足利用条件（跑在 Tomcat 上、以 WAR 包部署、特定 JDK 版本）的只是一部分。SCA 没报错，它只是把“可利用性”这一层留给了我们。

于是每一条告警，都得靠人去读代码、追调用链，才能回答那个真正关键的问题：这个洞，到底打不打得到我们？真正压垮安全团队的，从来不是漏洞数量本身，而是逐条判别告警可达性的时间成本。叠加上 NVD 这两年的收录积压，“等着别人替我们判好”也越来越不现实。

于是大多数安全团队被迫做了一个理性但难受的妥协：既然逐条研判可达性的成本，常常比直接修掉漏洞还高，那就别逐条判了——按 CVSS 或 EPSS 画一条线，线上的全处理，线下的先搁着。可这条线怎么画都别扭：画高了，会漏掉那些评分不高、却在自己场景里恰好可达的洞；画低了，告警又重新淹没所有人。

说到底，CVSS 是脱离具体上下文的通用分，EPSS 预测的是全网被利用的概率，它们都回答不了那个唯一要紧的问题：在我们的代码里，它到底打不打得到。

而 AI 第一次真正撼动的，正是这个成本结构——当逐条研判的边际成本被压到接近于零，“按分数一刀切”这个被迫的妥协，才第一次有了更优解。值得注意的是，在软件供应链安全治理上 AI 的价值从来不是帮我们“发现更多”，而是帮我们“消化得完”。

在做 CVE 研判自动化的过程中，我们把价值点收敛到了三件事上：

• 可达性判断：纯粹的结构问题——从入口到这个 sink，调用链连不连得起来。连都连不上，这条告警直接出局。

• 可利用性甄别：链路通了，再看攻击者能不能真的触发——外部输入到得了那个点吗？前面有没有鉴权、参数校验、配置开关把它挡在实际利用之外？可达只是前提，可利用才是结论。

• 批量触达：命中之后，自动生成针对每条业务线的通知，把“影响了哪个服务、卡在哪个版本、升级到哪个版本、如果无法升级有哪些缓解措施”讲清楚。

但这套甄别必须带一条铁律：“暂时打不到”不等于“永远安全”。可达性只是代码某一刻的快照——今天挡在漏洞前面的那个鉴权、那个开关、那条没被走到的分支，下一次迭代就可能被删掉、被绕过、被接通。所以研判的结论只能是“降低优先级 + 持续复评”，绝不能是“判定无风险 + 就地关闭”。

被降噪压下去的告警必须留痕，并在依赖升级或相关代码变更时自动重新触发研判——否则，降噪只是让风险暂时看不见，并没有真正消除它。

这背后是一个态度上的转变：在软件供应链安全上，过去我们指望 AI 去做“发现”（它其实不够准，会漏会编），现在应该让 AI 去做规模化的“研判”（它足够快，而且结论可以被复核）。人则退到最有价值的那一环——结合业务实际澄清风险的性质。

“矛”和“盾”讲完，方法论其实就顺出来了：

把模型、数据集、skill、MCP、AI 生成代码全部纳入依赖定义，建立 AIBOM。没登记在册的东西，永远扫不到——清单是这一切的前提，不是可选项。

第三方 skill、MCP、模型上线前强制过一道检测门，而不是出事后再回头扫。开源生态用了将近二十年，才把“引入前评审”变成肌肉记忆；AI 原生依赖如果也要再等二十年，代价我们付不起。

值得庆幸的是，这次工具没有缺席（MCP 扫描器、运行时护栏、skill 权限分析都已经出现），缺的只是把它们拧成一道“装之前必须过”的强制门。检测可以借力现成的知识体系：OWASP 的 LLM Top 10、机器学习 Top 10，以及 MITRE ATLAS 的攻击矩阵，都是现成的检查清单。

AI 负责规模化研判可达性、把无效告警降噪；人只做风险性质的澄清；风险接受权归业务。这不是偷懒，是把最稀缺的专家时间，用在机器判不了、也不该替人做主的地方。

而 AI 在这里真正不可替代的，是“可重复”：代码一变就能把相关告警重新研判一遍，这是人工永远做不到的。

你用来做研判的那个 LLM，同样可能被 prompt 注入污染结论——喂给它的漏洞情报、代码片段，都是不可信输入。

所以自动化研判的每一步，都要能溯源、可复核：AI 给出的结论，必须是“可以被质疑的”，而不是“直接采信的”。 一个连自己都保护不好的盾，不配拿来挡别人的矛。

AI 时代的供应链安全，不是在老问题上加个“智能”前缀。它是攻防两端被同一项技术同时重写：“依赖”的定义在变大，我们要守的东西多了；而“研判”的成本被打到接近于零，那些一直研判不完的告警，第一次研判得过来了。

真正的差距，会出现在那些既躲得开 AI 这杆“矛”、又举得起 AI 这面“盾”的团队，和那些还在“扫 package.json”的团队之间。

“矛”和“盾”，是同一个 AI。关键是你有没有意识到自己两只手都得握住它。