为什么 AI 生成的代码会破坏您的漏洞管理模型

AI 代码生成器 已经做到了多年来 DevOps 工具无法做到的事情：它们使得可以在几天内交付以前需要几周才能完成的功能。问题是，速度同样适用于漏洞。

在我从事网络安全领域的这些年里，我一直看到组织陷入同样的反应模式：发现漏洞，匆忙了解其范围，争论谁负责修复，并在几周或几个月后进行补丁。AI 并没有改变这种模式，它只是加速了这种模式的发生速度，使旧的模型无法跟上。对于关键 CVE 的平均 MTTR 为 60 天以上。AI 辅助开发并没有给你 60 天的时间，它给你每个 sprint 一个新的代码库。

依赖问题现在是一个 AI 问题

96% 的企业应用程序包含开源组件。大多数组件都是从公共注册表中拉取的，因为它们可以工作，并且有人需要它们。安全团队多年来一直在努力控制这一问题，AI 编码助手已经将其转变为更难以控制的东西。

当开发人员手动编写代码时，他们会对依赖关系做出明智的选择。当 AI 模型生成代码时，它会从其训练数据中拉取依赖关系。这通常意味着生成的包、过时的版本或具有已知 CVE 的组件，这些组件对于模型来说没有任何理由避免。代码看起来很干净，但风险嵌入在依赖关系树中，隐藏在任何人看不到的地方。

我曾经参加过安全审查，团队们对发现批准的包的传递依赖关系中的关键 CVE 感到震惊。包本身是安全的，但它拉取的内容不是。这种动态现在正在以机器的规模发生，跨越数百名使用没有安全意识的 AI 工具的开发人员。

事后扫描不是一种策略

开源软件安全的主流模型是扫描和修复：运行扫描器，整理发现结果，分配票据，然后等待。这种模型一直是反应性的，在 AI 加速的开发环境中，它完全被甩在了后面。

扫描器在问题已经进入代码后发现问题。引入和发现之间的时间窗口就是你的暴露所在。当 AI 以规模生成代码时，这个窗口变得更大，发现结果的数量增长得比任何团队都能手动修复得更快。结果是一个无限增长的 CVE 后台，优先级变得任意，开发人员在每个漏洞上花费 4 到 8 小时的时间做无关业务价值的工作。

添加治理故障，情况变得更糟。补丁的所有权通常不明确。安全团队标记一个 CVE，工程团队称其为配置问题，运维团队称其为代码问题。我 20 年前见过这种模式，它并没有改变。AI 使得这种模糊性的后果变得更难以承受。

真正有效的转变：控制输入

那些走在前列的组织已经停止尝试通过扫描来确保安全，而是开始控制开发人员和 AI 工具可以使用的内容。机制是一份策略性管理的开源组件目录，构建自源代码，持续监控，并作为私有内部注册表，取代直接从 PyPI、npm 或 Maven 等公共生态系统中拉取。

这种方法以最直接的方式将安全性移至左侧。漏洞在进入构建流水线之前被阻止。开发人员使用相同的工具。AI 编码助手从相同的管理源中解析依赖关系。安全团队只需设置一次策略，这种策略适用于所有地方，包括在 2 点钟没有人工审查的情况下生成的代码。

实践中的样子

对于正在经历这一过程的安全领导者，以下几点至关重要：

1. 在扩大 AI 采用之前定义您的批准组件集。如果您的 AI 编码工具从公共注册表中解析依赖关系，则您的批准过程仅存在于纸面上。建立一个管理的内部注册表，路由所有内容，并要求组件从源代码构建，具有可验证的来源。
2. 将补丁视为一个管理流程，而不是票据队列。那些领先于 CVE 债务的组织并没有加快手动补丁的速度。他们已经从等式中删除了手动补丁。当社区批准的补丁可用时，它会自动重建到目录中。开发人员在下一次拉取时会收到更新。没有人分配票据。没有人等待 60 天。
3. 在被迫之前将您的 AI 工具链映射到您的合规义务。我曾经看到团队在 AI 工具上构建数月，只是当客户需要 FedRAMP 对齐或 SOC 2 证据时才遇到墙。您的策略性目录也是您的合规审计跟踪。SBOM 和来源记录应该与每个组件一起提供，而不是在最后期限压力下重新组装。
4. 在治理层面分配明确的所有权，而不是在票据层面。那些在补丁方面行动最快的团队并不是拥有最多开发人员的团队。他们是安全团队拥有策略、平台团队拥有交付、两者都不需要等待对方行动的团队。

使安全成为赋能而非阻塞

人们一直认为安全性和开发速度存在根本冲突。我从未发现这种说法在安全性被设计到流程中而不是被添加到流程中时是正确的。从策略性组件集中工作的开发人员实际上可以更快地移动，因为他们不需要对批准进行二次猜测，等待安全审查，或清理本可以在上游阻止的漏洞。

那些能够在不积累不可持续的安全债务的情况下驾驭 AI 驱动开发的组织，并不是那些运行最多扫描器的组织。他们是那些已经做出明智决定来管理进入其软件供应链的内容的组织，以免成为事件响应问题。这个决定属于领导层。执行它的工具今天已经存在。