在AI和CI/CD时代重新思考漏洞管理

在AI和CI/CD时代重新思考漏洞管理

随着AI辅助编程（即“氛围编码”）的兴起，开发者不再逐行编写代码，而是指导AI代理构建软件，这一趋势已深刻改变了安全领域。即使是资深开发者，也因为速度和效率的提升而转向这种模式，产出可增加十倍。其影响远不止代码编写方式，更延伸至漏洞发现、跟踪和修复的整个流程。下游过程必须随之适应。

考虑一个场景：开发者向AI报告一个发现的漏洞。AI很可能扫描代码库，查找类似漏洞，并询问是否一并修复。随后，代码库会接受全面审查以消除该类漏洞。另一种可能是，代码从制品重新生成，从而可能减少其他现有漏洞。模型或训练数据可能已学到改进的软件架构模式，例如零信任对齐和API安全增强。由于代码正在重构，你旨在修复的漏洞可能连同之前未知的一整套漏洞一同解决。

这改变了我们应向CVE系统提出的问题。CVE长期以来一直是跟踪和共享已发现漏洞的主要方法。与版本绑定的CVE有助于识别哪些漏洞不再适用。然而，CI/CD管道持续推送应用，其运作方式不同于传统供应商提供更新由客户内部部署的模式。多年来，云原生架构已采用不同模型在不影响客户的情况下补丁和修复漏洞。此外，决定哪些CVE应优先处理一直存在挑战。

当整个代码库用更安全的语言和更新的架构模式重写时，会发生什么？现有漏洞可能被消除，也可能被新漏洞替代——理想情况下数量少得多。随着时间的推移，随着更老旧、更易受攻击的软件被现代语言、改进架构和AI驱动的软件保证所淘汰，跟踪漏洞的需求应会减少。

这提出了一个重要问题：如果一个漏洞在通过CI/CD管道管理的平台内被发现并修复，且你确认它已修复，那么该CVE是否还应存在？CVE目录的目的是协调跨供应商和运营商的认知与修复，他们可能仍处于暴露状态。如果修复是确认的、自动的、可验证的，且没有受影响版本仍在运行，活跃的CVE还有何作用？将其作为历史记录保留对回顾分析有价值，但作为威胁情报中的实时信号，它变成了噪音。我们应开始考虑在高度动态环境中跟踪漏洞的更好机制，其中新代码和补丁可快速生成，工作负载可通过云原生平台和CI/CD管道的弹性迁移到更新软件。

这种变化速度不仅挑战我们通过CVE跟踪漏洞的方式，还重塑了使用CVSS评分漏洞严重性的方法。CVSS可能需要更充分地考虑运行环境。代码在孤立环境中可能脆弱，但考虑环境控制后脆弱性如何？并非所有工作负载都在可信执行环境或安全围篱中运行，但有些确实如此。此外，系统可验证运行代码的变化，快速检测已知漏洞的利用，从而减少或阻止危害。忽略这些因素的静态基础评分越来越无法提供有价值的信息。

尽管许多报告暗示漏洞可能消失，但我们尚未达到那个阶段。即使代码广泛用防止内存安全漏洞的语言编写，风险依然存在。这些包括内部威胁植入恶意代码，以及需要软件或固件缓解的硬件漏洞（如Spectre和Meltdown）。AI可快速重写软件以绕过硬件缺陷，正如Spectre和Meltdown所展示的，它们利用硬件的推测执行。在这些情况下，硬件仍是限制因素。但在软件方面，在短时间内将整个代码库迁移到提高内存安全的语言变得越来越可行。遗留代码正在迅速消失，这一趋势可能在未来几年持续。

不要被动接受这些结果。应积极参与塑造伴随软件快速演进而来的流程变化。CVE、CVSS和威胁情报源是为一个更缓慢、更静态的世界设计的。是时候退一步，思考漏洞和漏洞利用之外的更广泛影响，包括我们用于管理它们的流程以及对我们环境的影响。