AI 正在改写软件供应链安全的游戏规则

过去几个月，安全圈接连出现了几个值得注意的信号。Vim 编辑器被曝出代码执行漏洞（CVE-2026-34982），攻击者只需诱导用户打开一个特制文件，就能在系统上执行任意代码。与此同时，GitHub 上出现了两轮 AI 辅助的自动化供应链攻击，攻击者利用 GitHub Actions 的配置缺陷，向开源仓库批量提交恶意拉取请求，成功入侵了至少两个 NPM 软件包。

这些事件单独看，可能只是又一个漏洞和一次攻击。但如果把它们放在一起看，你会发现一个更本质的问题正在浮现：AI 正在同时改变攻击者和防御者的能力边界，而现有的安全策略并没有跟上这个变化。

攻击者已经用上了 AI，而且门槛在降低

先看攻击侧。Wiz 公司追踪到的一起名为“prt-scan”的攻击行动，攻击者在 26 小时内发起了约 475 次拉取请求，目标覆盖 GitHub 上数百个仓库。这个速度，靠人工操作是不可能的。研究人员判断，攻击者使用了 AI 辅助的自动化技术。

更有意思的是，这些攻击的技术实现其实很粗糙。Wiz 的报告里提到，攻击者尝试了复杂的多阶段载荷，但里面充斥着“在专家看来不合逻辑”的技术手段。换句话说，攻击者可能本身技术能力并不强，但 AI 帮他把攻击规模放大了几十倍。过去需要高水平黑客才能发起的供应链攻击，现在一个中等水平的攻击者，用 AI 工具就能批量执行。

这带来的直接后果是：攻击数量暴增，但质量参差不齐。对防御方来说，这意味着需要处理的安全告警会成倍增加，而其中大部分可能是无效攻击——但你没法忽视它们，因为总有少数能成功。

防御侧的困境：事后修补已经不够用了

再看防御侧。目前主流的软件供应链安全做法，基本是“先生成、后检测、再修复”的被动思路。比如用静态分析工具扫描代码漏洞，用模糊测试找运行时问题，用 SLSA、SBOM 这类框架做溯源和验证。这些方法的问题在于，它们都是事后补救——等代码写完了、构建完成了、甚至已经部署了，才发现问题。

帝国理工学院的一篇论文直接点出了这个模式的四个致命缺陷。第一，大型代码库的状态空间极其复杂，任何分析工具都无法穷举所有执行路径，高危漏洞往往藏在罕见的异常分支里。第二，工具没发现漏洞，不代表漏洞不存在，只是没触及那条路径。第三，一年前生成的代码，可能扛不住今天顶级 AI 的攻击。第四，防御方受安全、可复现等约束，而攻击者可以无限迭代、聚焦单一目标——攻防不对称是结构性的，不是靠堆工具能解决的。

这篇论文提出的核心观点是：应该放弃“事后修补”，转向“在代码生成阶段就强制实施安全约束”。具体来说，就是让代码在生成的那一刻，就必须满足某些硬性的安全规则——比如数组访问必须加边界检查、HTML 输出必须做清洗、禁止使用不安全的库函数。

论文认为，扩散式代码模型是实现这个目标的最佳载体。原因在于，扩散模型可以一次性生成完整程序，能在生成阶段全局评估安全约束，而不是像传统自回归模型那样逐令牌生成、局部判断。而且大多数安全修复其实很局部（1-2行代码，局限在单个函数内），扩散模型的层级化生成方式正好适合在局部节点施加精准约束。

但现实是：很多老代码连让 AI“读懂”都做不到

理论方向很清晰，但落地时遇到的最大障碍，可能不是模型本身，而是代码仓库的状态。

云起无垠的沈凯文博士在一次技术分享中，直指一个现实问题：很多团队发现，AI 在新项目里能轻松写出完整功能，但一接入存量老项目就频频“失灵”——生成的代码编译不过，或者能运行但团队不敢合并，因为“改一个 Bug 引出三个新 Bug”。

他给出的诊断是：问题不在 AI 模型，而在代码仓库本身没有为 AI 协作做好准备。 老项目长期积累的四类技术债——代码债、测试债、文档债、架构债——让 AI 陷入了“看不懂、改不动、不敢合”的困境。

具体来说，代码债表现为代码体量过大导致上下文溢出、技术栈老旧导致训练数据覆盖不足、注释缺失导致隐含知识无法传递、模块耦合严重导致修改风险极高。测试债的核心问题是缺乏自动化测试保护网，团队“能写代码但不敢合并”。文档债让 AI 失去了理解项目的导航图，只能“靠猜”推断业务意图。架构债则表现为多仓割裂，AI 只能看到零散的代码碎片，无法理解完整的产品系统。

他提出的治理框架很务实：代码治理让仓库可读，测试治理让 AI 可验证，文档治理让 AI 可理解，架构治理让 AI 看全局。在一个真实案例中，一套 30 万行 Java 代码、测试覆盖率不足 5% 的系统，经过系统性治理后，AI 代码合入率从 12% 提升到了 67%。

一个正在形成的共识

把这几件事放在一起，能看到一个清晰的脉络。

攻击者已经在用 AI 大规模自动化地发起供应链攻击，门槛在降低、频率在上升。防御侧的传统事后修补模式，在理论上被证明存在结构性缺陷。而新的防御思路——在代码生成阶段就实施硬安全约束——在技术上有了可行的载体（扩散模型），但在落地时遇到了老代码仓库“喂不动 AI”的现实瓶颈。

个人觉得，这里面有一个关键点值得注意：AI 安全的核心矛盾，正在从“模型能力够不够强”，转向“工程体系有没有为 AI 做好准备”。 无论是攻击者用 AI 批量发起攻击，还是防御者想用 AI 做代码安全，最终都依赖一个前提——代码本身是结构清晰、可被理解的。如果代码仓库是一团乱麻，AI 既无法准确理解业务逻辑，也无法有效施加安全约束。

理论上，未来三到五年，软件供应链安全的核心战场，可能不是哪个模型更强，而是谁的工程体系能更快地完成 AI 适配。那些还在 L0 阶段（AI 基本不可用）的团队，面临的不仅是效率问题，更是安全风险——因为攻击者不会等他们改造完再动手。