如今,显而易见,人工智能正在从根本上改变软件开发的格局和未来。在过去几年里,生成式人工智能(GenAI)和大型语言模型(LLMs)已彻底颠覆了软件开发生态系统。

从英伟达(NVIDIA)首席执行官黄仁勋调侃“孩子们不应该学习编程”,到谷歌等行业领导者宣称其 25%的代码如今由人工智能编写,风险投资公司YCombinator表示其最新一批员工的代码库中有 25%由人工智能完成度高达 95%,再到 Anthropic 首席执行官声称 6 个月内 90%的代码将由人工智能生成。谷歌 2024 年的 DORA 报告还发现,75%的开发人员现已依赖人工智能编码助手。

即便抛开我近期在《Vibe Coding 的难题》一文中提到的“Vibe Coding”等趋势不谈,人工智能显然正在重塑现代软件开发的方式,涉及劳动力、工具、产出等诸多方面。

尽管如此,这也带来了固有的安全问题,我们将在后文展开讨论。

此外,安全领域有机会成为先进技术的早期采用者,而非落伍者,并且不再继续纠结是“事后附加安全”还是“内置安全”的问题。

速度、数量和漏洞

我们已经探讨过编码助手和人工智能驱动的开发工具是如何被迅速广泛采用的。除了广泛应用之外,这些工具还推动了“生产力”的大幅提升。尽管具体数据有所不同,但就交付速度和代码输出而言,估计提升幅度通常在 35%至 50%之间。

从表面上看,这对主要关注收入和上市速度等激励因素而非安全性的企业和开发人员来说是一件好事。然而,这种速度和数量的提升会对另一个方面产生影响,即漏洞。

让我们来看看现有的漏洞状况。撇开通用漏洞与暴露(CVE)和 NIST 国家漏洞数据库(NVD)的崩溃情况不谈,多年来,安全领域一直在努力跟上软件开发的步伐。

就在 2024 年 3 月,从 2024 年到 2025 年,CVE 的年增长率达到了 +48.37%,且丝毫没有放缓的迹象。

Source: Jerry Gamblin

这是由多种因素造成的,例如漏洞发现和披露工作的改进与增加、漏洞管理生态系统的成熟,但也与基本的数学原理有关。从历史上看,更多的应用程序、软件和代码行意味着更多的漏洞,即更大的攻击面。

这在许多企业环境中表现为成千上万的大量漏洞积压,安全工作无法跟上不断增长的攻击面、日益加快的软件开发速度,以及业务方面相互竞争的优先事项,如功能发布、客户满意度、上市速度和收入。

安全部门尝试过各种方法,如“左移”策略和“DevSecOps”理念,但这在很大程度上是将一系列缩略语式的安全工具(如SAST、DAST、IaC、容器扫描等)生硬地纳入持续集成/持续交付(CI/CD)管道。这些工具大多保真度低、存在数据质量问题,并且几乎没有与应用或组织相关的背景信息,从而加剧了安全与开发之间的隔阂。而具有讽刺意味的是,“DevSecOps”理念本应改善这种隔阂。

你不需要是天才也能想到,当我们考虑到 Copilots、编码助手以及通用人工智能驱动开发的广泛采用时,这个问题的可能影响及其未来的恶化趋势。

你可能会问,编码助手和人工智能工具难道不会生成更安全的代码吗?

嗯,不完全是,至少目前还不是。

整个行业的各种研究人员和相关方都在研究这个问题,目前情况不容乐观。一项资料显示,人工智能生成的解决方案中有 62%存在错误和/或包含安全漏洞。另一项研究发现,29.6%的人工智能生成代码片段存在安全弱点。

Source: BaxBench

尽管有这些研究和发现,但调查显示,开发人员高估了人工智能生成代码的安全性,往往从本质上信任其输出,而不从安全角度进一步验证或核实。还有研究称,人工智能编码工具的广泛应用可能会导致技能衰退,从批判性思维到软件开发细微差别方面的专业知识都会受到影响。

此外,还存在一个“人工智能反馈回路”,这是一个具有挑战性的二分法。随着人工智能创建更现代化的代码库,这些最初由人工智能生成的代码片段和代码随后会被用于未来的人工智能模型训练。这就造成了一种反馈性影响,即人工智能模型训练使用了潜在的不安全和脆弱代码,从而扩大了未来的安全影响。

诚然,这个问题并非人工智能生成代码所独有。事实上,现代编码助手所使用的大多数基础人工智能模型都不是凭空创造的有机代码,而是在庞大的开源软件生态系统中训练出来的。

正如我在一篇题为《2025 年开源安全格局》的文章中所写的那样,开源技术的采用已经呈现出指数级的逐年增长态势,97%的代码库都包含开源技术,平均每个应用程序中的开源文件数量在过去四年里增加了两倍。这些开源代码同时存在漏洞和可持续性问题。

如上所述,开源代码中的漏洞非常普遍。绝大多数开源组件已经过时数年,在许多情况下,已经多年没有新的开发,这表明这些漏洞不可能在短期内得到修复。

这并不是说开源技术天生就比专有代码糟糕或不安全。事实上,如上所述,大多数商业代码都源于开源技术。

同样的情况也适用于领先的前沿人工智能模型和它们所训练的代码,这些代码现在可以帮助开发人员创建并发布到现代软件生态系统中。

治理 - 模型、代码和集成

人工智能驱动的开发挑战的一个基本方面是治理工作,这涵盖模型、代码和集成三个关键领域。在模型方面,BaxBench等研究表明,并非所有的人工智能模型及其编码能力(包括生成安全代码的能力)都处于同一水平。企业需要对软件开发活动中使用的 Copilots、编码助手和模型进行管理。

在代码方面,这需要根据深入的上下文(远不止已知的漏洞),就应用程序、产品和系统中应包含哪些代码做出基于风险的决策。这包括已知利用情况、利用概率、可及性、业务背景等因素。传统的漏洞管理方法会给开发团队带来低情境、低质量的安全扫描结果,拖慢开发速度,起到类似商业税收的作用,而非促进作用。开发人员深知这一点,这也正是他们积极主动地规避安全流程,而非积极配合安全工作的原因。

在集成方面,随着模型上下文协议(MCP)和代理 2 代理协议(Agent2Agent Protocol)等的兴起,我们看到了支持协议和方法论的爆炸式增长与令人兴奋的发展态势。这些协议和方法论不仅支持人工智能驱动的开发,还支持整个代理架构。

我们将继续看到人工智能驱动的开发以及快速开发的应用程序和软件的整个代理架构和工作流程得到广泛应用。这些架构和流程在代理之间进行内部协调,并与数据源、工具和服务进行外部交互。

安全领域跨越鸿沟的机遇

安全问题历来是企业的一个摩擦点,被开发人员称为“让人灵魂发白的苦差事”。它常常被视为“不可能的办公室”,通常被企业视为必要的“恶魔”。

这是由于我在上文讨论的诸多问题,再加上安全领域继续使用传统方法、基于纸张的合规流程、无法向企业阐明自身价值,以及固有的风险规避文化所导致的。

经典的技术营销和销售书籍《跨越鸿沟》概述了技术采用的生命周期,包括创新者、早期采用者、早期多数人、后期多数人和落后者。

安全领域几乎总是处于落后状态。

当企业正在快速采用云技术、移动技术、软件即服务(SaaS)、人工智能以及接下来出现的任何新技术时,安全问题却始终袖手旁观,对假想的和现实的风险应对不力,强调过度谨慎,最终不可避免地被抛在后面。

这就是为什么我们会听到“安全需要内置,而不是附加”这样的说法。虽然每个从事安全工作的人听到这句话都会点头认同,但我们的行为、与开发和工程同行的互动,以及我们如何在企业内部和整个企业中实施“安全”措施,却反映出不同的情况。

我们因处于落后状态而延续了过去的问题。

然而,摆在我们面前的是一个真正的抉择和机遇。我们是继续延续过去的问题,还是通过在技术应用生命周期中提前布局,成为早期采用者甚至创新者呢?

我们已经知道,开发人员和企业正在迅速采用人工智能和人工智能驱动的开发。最近的一份报告显示,企业对人工智能代理的采用也在迅速增长,其中包括一个显著的激增态势。仅在一个季度内,试点比例就从 37%增长到 65%,几乎翻了一番。

我曾在一篇标题相同的文章中讨论过人工智能与网络安全的交集。初创企业、创新者和投资者正在探索代理人工智能在治理、风险与合规(GRC)、安全运营(SecOps)和应用安全(AppSec)等领域的潜力,本文主要关注这些领域。

代理人工智能为安全领域提供了应对系统性挑战的机遇,例如漏洞管理、劳动力限制以及长期存在的摩擦和挫折。

这包括识别错误配置和漏洞,并通过主动识别、建议和及时补救等措施,积极维护源代码和运行时的应用程序安全。

多个 AI 代理可用于在数千个拉取请求中扩展安全代码审查等活动,带来丰富的代码上下文和深刻的安全见解,并减少因开发人员在组织中人数相对较少而困扰安全工作的人工审查和工作量。

就像人工智能提高了开发人员的生产力一样,它也可以成为安全领域的倍增器,将安全任务和活动扩展到人类劳动力难以企及的水平。

MCP 等协议的兴起允许与人工智能编码助手集成,直接嵌入到本地开发人员的工作流程中,在提交之前捕捉缺陷和漏洞,并在安全/保密库、升级和补救等方面为开发人员提供上下文代码审查和建议。

需要强调的是,在所有行业热潮中,关于 MCP 和代理人工智能,一个关键点是 MCP 和这些工作流程的可扩展性与所集成的数据、工具和服务的质量息息相关。

如果你集成了传统的、保真度差的、低质量的工具和服务,那么你只是在复制我上文讨论过的问题。尽管如此,CI/CD 工作流程中的低质量安全工具和发现还没有整合到集成开发环境中,这开发人员感受到的挫折和痛苦比以前更严重,而不是改善组织的安全成果。

其中一个例子来自 AppSec 领导者 Endor Labs,我在该公司担任首席安全顾问。正如您在下面的演示中看到的,通过 Endor Labs 的 MCP Server 功能,您将看到VSCode和 Copilot 的演示。用户可以用自然语言询问有关代码漏洞的问题,甚至可以指示修复代码依赖关系中的漏洞,所有这一切都不会干扰开发人员的工作流程。

这包括使用领先的集成开发环境进行上下文代码审查、准确且有优先级的补救结果、更安全的库建议以及针对潜在破坏性更改的上下文升级。

这显示了通过 MCP 和大型语言模型(LLMs)与开发人员工具和工作流程集成的能力,从而改善组织的安全成果。

结束语

正如我在文章中所讨论的那样,人工智能驱动的开发正在彻底改变现代软件开发的方式。现在,安全性正处于一个关键的十字路口。我们可以延续过去的问题,保持落后状态;也可以跨越鸿沟,将自己定位为这一新兴技术的早期采用者和创新者。

我们知道我们的业务、开发和工程同行以及恶意行为者在做什么。

从这一点出发,我们的所作所为将决定安全问题是事后才想到的附加问题,还是设计中的内置问题。

我们真的希望我们的行业留下落后者的名声吗?

原文链接:

https://www.resilientcyber.io/p/securitys-ai-driven-dilemma

声明:本文来自安全喵喵站,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。