AI编程的2大失败,正在制造安全瓶颈

6 阅读6分钟

AI代码助手虽加速开发,却因两大失败制造安全瓶颈:一是大规模部署AI工具时未同步扩展安全审查,导致安全团队不堪重负;二是传统安全框架无法应对AI代理的复杂性及不可预测行为。解决之道在于全面审视开发流程、实施可扩展审查机制,并强化底层工程实践与文化,而非仅依赖AI工具。AI仅是放大器,系统健康是关键。

译自:The 2 failures with AI coding that are creating security bottlenecks

作者:Julie Davila

代码助手未能达到我们预期的“10倍工程师”水平。GitLab最近一项针对DevOps从业者的调查发现,尽管超过三分之一的代码现在由AI编写,但从业者将AI引入的质量控制和安全漏洞列为主要的采用挑战。随着组织大规模部署AI编码工具,这些问题正使他们的安全团队不堪重负。AI曾承诺加速开发,但我们正在制造安全审查瓶颈的速度比AI提高编码效率的速度更快。

以前每小时审查100行代码的安全工程师,现在可能要面对100,000行代码,因为其中有AI贡献的代码。与此同时,攻击者已经在使用自主代理快速检测现有系统中的漏洞。随着风险的激增和安全积压的增长,工程师的防御能力仍然受限。

“AI曾承诺加速开发,但我们正在制造安全审查瓶颈的速度比AI提高编码效率的速度更快。”

这种挑战一直以某种形式存在。当代码量可控时,依赖人工劳动的安全流程很容易被忽视。然而,AI的复杂性正使产品安全工作变得指数级困难。如果我们不迅速解决这些规模化挑战,确保AI规模开发的窗口将变得更难关闭。

以下是导致这些瓶颈的两个复合性失败——以及如何避免它们。

1. 部署AI工具但未扩展安全审查

左移”运动旨在通过将安全责任更早地转移给开发者,以解决软件开发生命周期中的安全瓶颈。在开发工作流程中增加安全测试听起来不错,但强迫开发者处理经常误报的安全检查并非最佳方案。我们可能会无意中增加他们工作时长,而没有考虑激励机制。开发者会寻找变通方法,因为他们需要在截止日期前交付功能。

采用左移方法时,团队未能考虑整个软件开发生命周期,导致了意想不到的下游影响。我们在AI代码助手上犯了同样的错误。这些助手优化了代码生成,却让审查流程保持不变。解决方案不是孤立地增加更多人员或更多工具。团队需要全面考虑整个管道。

避免这一陷阱的组织会在添加更多AI工具之前绘制其价值流。这还包括记录那些依赖于隐性机构知识的流程,这些知识使团队难以定义和衡量AI所带来的价值。当AI改进了一个未记录的流程时,团队无法衡量或证明其价值。

“解决方案不是孤立地增加更多人员或更多工具。团队需要全面考虑整个管道。”

领导者还应实施可扩展的审查方法,将AI与实用的人工监督相结合,建立基于可衡量风险的优先级框架。例如,涉及敏感客户数据或生产数据库的代码需要比定制应用程序主题的功能进行更密集的审查。

2. 传统安全框架不适用于AI代理

传统安全框架假设人类行为是可预测的。AI代理不遵循这些规则,结果是产生了一类全新的风险。

当代理跨组织边界与其他代理交互时,复杂性会成倍增加。当一个内部代理从一个本身从另一个外部系统接收指令的第三方代理接收指令时,安全模型必须考虑到这种复杂性。链中增加的代理越多,恶意请求存在于直接观测之外的可能性就越大。

避免这些问题需要开发安全控制措施,以限制权限并监控代理行为。新兴方法,例如为AI系统建立复合身份,可以通过跟踪哪些代理执行了特定操作以及谁授权了它们,来帮助将AI活动与人类责任联系起来。

许多安全工程师今天很难阐明LLM的后端实际是如何工作的,但理解AI系统的设计对于理解AI安全风险至关重要。这不需要对每个组件都有深入的工程专业知识,而是需要对各个部分如何协同工作以实现结果有基本理解,就像安全专业人员理解网络应用程序的工作原理一样。

后续展望

大多数组织将在未来两年内在已知存在缺陷的系统上构建AI能力,因为开发不能等待所有修复都到位。这是正确的选择。没有一个单一的解决方案适用于所有组织来确保AI驱动的开发安全。关键在于承认风险,战略性地管理风险,并努力以正确的方式做事。

安全团队也无法单独解决这些失败。DX最近的研究表明,尽管91%的开发者现在使用AI工具并报告每周节省3-4小时,但组织功能障碍,包括会议、中断、缓慢的代码审查和CI等待时间,所耗费的时间比AI节省的时间还要多。质量结果也因组织而异,一些组织看到了变更失败率的改善和更快的交付,而另一些则深陷技术债务。

“AI是一个放大器。如果你的交付系统是健康的,AI会使其更好。如果它有问题,AI会使其更糟。”——持续交付专家 Bryan Finster

真正的区别不在于AI工具本身,而在于底层的工程实践和文化。正如持续交付专家 Bryan Finster 观察到的:“AI是一个放大器。如果你的交付系统是健康的,AI会使其更好。如果它有问题,AI会使其更糟。”这些失败根植于AI现在大规模暴露的上游问题。安全审查处于这条链的末端,继承了之前的所有弱点。

安全团队必须成为支持实现安全AI驱动开发的工程实践的倡导者,包括有文档记录的流程、强大的测试文化以及将安全性贯穿于整个软件交付过程的持续交付原则。首先到达安全团队的内容质量仍然是真正的制约因素。

将会成功的组织是那些现在就正视这些问题,而不是等到AI生成的代码量大到无法修复的组织。