AI 加剧软件供应链攻击威胁，行业如何应对

AI 编程工具极大地提升了开发者的效率，但 AI 对攻击者同样起到了加速作用——而软件供应链正日益成为两者碰撞的主战场。

一系列数据足以说明软件开发变化之快。GitHub 在 2025 年处理了约 10 亿次提交。到 2026 年 4 月，该平台每周已能处理约 2.75 亿次提交，GitHub COO Kyle Daigle 透露。GitHub Actions 的使用量也在攀升，从 2023 年每周 5 亿计算分钟增长到今年单周的 21 亿。

Chainguard 首席安全官 Quincy Castro 表示，软件开发方式的转变已经非常明显。

"我环顾 Chainguard，我不认为我们任何工程师在过去一年里真正独立编写过一行代码，"Castro 告诉 The New Stack。手动写代码现在"感觉有点像在用手抄写手稿，"他说，而"印刷机已经在那里疯狂运转了。"

但这不仅仅关乎专业开发者产出更多代码。AI 还扩大了能够创建软件的人群。之前必须等待工程资源支持的 HR、财务和商业智能团队，现在越来越多地可以自己动手构建所需的东西。

这意味着更多软件由传统工程团队以外的人创建，且往往由 AI 来决定其中纳入哪些内容。操控 agent 的人可能永远不会看到它选择了哪些库或包。

当 agent 选择依赖时

软件安全此前已经建立在人类无法检查所有内容的认知之上。但开发者仍在做出重要决策，包括应用程序中使用哪些库和包。

当 AI agent 承担大部分编码工作时，情况就变了。

"人类在指挥他们想要完成的事情，但他们某种程度上与实际的工作执行过程脱离开来了，"Castro 说。"现在是由 AI 来做出这样的选择：我将把哪些依赖拉入这个应用？我将如何完成这个任务？"

"人类在指挥他们想要完成的事情，但他们某种程度上与实际的工作执行过程脱离开来了。"

与此同时，攻击者也在为同样的技术找到大量用途。Castro 看到三个问题同时涌来：前沿模型发现以前未知的漏洞、攻击者使用 agent 利用组织尚未修复的漏洞，以及对开源生态系统的持续攻击。

一系列中低危漏洞曾经可能远远排在修复队列末尾。但具备高级网络能力的前沿模型，包括 Anthropic 的 Claude Mythos Preview 和 OpenAI 的 GPT-5.6-Cyber，现在可以跨这些漏洞工作，将看似微小的弱点串联成可行的攻击路径。

"这里有一大堆中危和低危漏洞。现在给我一条能让我拿到域管理员的攻击路径，"Castro 如此描述这种方法。"把这些串联起来，帮我拿到系统的 root 权限。AI 在做这件事上真的非常、非常擅长。"

这对漏洞管理提出了一个棘手的问题——而且模型还在不断变强，OpenAI 在 8 月发布了 GPT-5.6-Cyber。根据 Mandiant 的数据，平均利用时间已从 2018-19 年的 63 天下降到 2025 年的负 7 天，意味着在防御者有补丁可用之前利用就已经开始了。

与此同时，AI 组合看似不太严重的弱点的能力，使得基于 CVSS 的整洁队列在代表攻击者实际能做什么方面变得不那么有用了。

第三个问题是软件供应链本身。

开源成为攻击路径

现代应用程序严重依赖开源软件，攻击者越来越多地将矛头指向用于构建和分发开源软件的基础设施。

Castro 提到了 TeamPCP 攻击活动，它影响了包括 Aqua Security 的 Trivy 在内的广泛使用项目。在那次攻击中，恶意代码被推入受信任的组件，随后被下游取用。

供应链攻击曾经主要与愿意投入大量时间进入正确位置的高复杂度国家级组织相关联。这道壁垒正在崩塌。

"如果你不在乎制造一些动静，这是一个比很多人想象的容易得多的攻击向量，"Castro 说。更重要的是，"一次成功的攻击可以导致级联的其他漏洞利用和其他访问，让你进入其他地方。"

开发流程本身可能使情况更糟。Castro 说，许多组织在 CI/CD 方面的控制仍然相对较少，而开发者经常从外部来源拉取组件来完成工作。将自主编程工具添加到这种行为中会加剧风险。

"你不会捡起一个随机的 U 盘然后把它插进生产系统，对吧？但当人们以这种方式消费开源软件时，本质上就是在做同样的事。"

他将组织消费开源软件的方式比作将一个未知的 USB 设备插入生产系统。"你不会捡起一个随机的 U 盘然后把它插进生产系统，对吧？"他说。"但当人们以这种方式消费开源软件时，本质上就是在做同样的事。"

开源不是问题。在没有充分验证所消费内容的情况下信任其分发路径才是。

预防必须先于检测

这就是旧安全模型开始力不从心的地方。

多年来，大部分漏洞管理遵循一个熟悉的循环：扫描某物，生成告警，判断严重程度，然后让人去修复。当开发产出成倍增加、AI agent 做出更多底层决策、且攻击者能够在修复可用之前就利用漏洞时，这种模式越来越难以为继。

Castro 希望公司在软件进入开发环境之初就投入更多努力，而不是在软件已经存在之后才发现问题。

"我们如何从头开始就让事情正常运转，不需要告警、不需要响应事情、不需要人追逐事情、不需要人试图证明一个否定？"他说？"从端到端，从代码创建到部署，我们如何确保能够给人们提供最可信赖的那个版本的东西？"

Chainguard 对容器、库和其他开源制品的方法背后的理念是：不是从公共生态系统中直接获取包并事后扫描，而是从经过验证的、可构建的源码构建制品，并提供关于它们如何创建的可溯源信息。

但可信赖的组件只是其中一层。

"如果你没有一项技术控制来规定这是开发人员消费这些内容的唯一方式，那么将本质上安全的软件组件引入环境就没有意义，"Castro 说。这意味着工程、安全和 SRE 团队还需要控制软件——无论是由人还是 AI agent 选择的——可以从哪里来。

这需要多层次的保护。组织需要知道他们的软件来自哪里、如何构建，控制什么可以进入他们的环境，并确保这些规则在 AI agent 选择组件时以及开发者选择组件时都同样适用。

以 AI 速度防御开源

然而，还有另一个问题。Claude Mythos Preview 和 GPT-5.5-Cyber 等前沿模型不仅仅是在发现以前未检测到的漏洞；它们还能将较低严重程度的缺陷组合成可行的攻击路径。个别公司可以加固自己的流程，但它们所依赖的软件来自一个面对速度和规模都是前所未见的漏洞发现的开源生态系统。

这正是 Chainguard 推出的行业联盟 Athena 背后的部分考量，该联盟旨在将前沿 AI 程序的漏洞发现转化为修复方案。截至 7 月，该联盟已处理超过 40,000 个漏洞，其中 42% 被评为严重或高危，86% 被标记为网络可达，意味着攻击者可以在网络层面访问和触发它们。

对 Castro 来说，重要的是不仅仅是发现更多 bug。AI 在这方面已经做得非常出色了。仍然需要有人去修复它们。

"通过 Athena，我们尝试做的是给人们那个工程修复，"他说。"如果我们创建一个联盟，人们只需要把他们发现的问题发送给我们，我们自动为这些问题生成修复，然后我们把这些修复推送给所有人，会怎么样？"

"通过 Athena，我们尝试做的是给人们那个工程修复。"

这些修复也可以向上游推送给开源维护者，他们面临着被不断扩大的 AI 生成漏洞报告淹没的前景。

这可能最终是 AI 迫使软件安全发生的更大转变。开发者不会因为 coding agent 带来新风险就停止使用它们，就像公司不会因为攻击者以它为目标就停止使用开源一样。

将足够的扫描附加到一个指数级加速的开发流程上也不是什么好答案。

真正的机会是在软件到达开发者或 agent 之前就消除更多风险：从你可以信任的组件开始，严格控制它们如何进入环境，并在尽可能接近源头的地方修复弱点。

AI 使得创建软件的代价大幅降低。它对攻击也是如此。现在安全必须跟上，而不能把印刷机再塞回盒子里。

访问 Chainguard 了解更多。