AI编程如何毁掉你的 API？

在最近的一篇文章中，我们回顾了前 Gartner 分析师 Paul Dumas 在奥斯汀 API 峰会上的主题演讲。演讲的要点是，随着使用 AI 生成代码的实践不断发展，我们将成为内容的管理者。换句话说，就是提示、测试和整理 AI 创建的代码。

根据GitHub 的研究，到 2023 年，多达 92% 的美国开发者“无论在工作中还是工作之外”都在使用 AI 编码工具。GitHub进行的另一项研究发现，使用 Copilot（GitHub 开发的工具）的人完成任务的速度比不使用 Copilot 的人快 55%。

然而，这种对人工智能的依赖也带来了潜在的后果。由于“生成的代码数量庞大……没有防护措施，生成式人工智能很可能会导致更多的技术债务”，Bill Doerrfeld写道。既然可以抛弃代码并生成新代码，为什么还要重复使用和改进代码呢？

例如，当开发人员使用 AI 生成他们不熟悉的语言的代码时，也会出现问题。他们是否了解相关的最佳实践？安全风险？出现的问题的解决方案？这些问题的答案通常是响亮的“不”。

尽管如此，上述研究的隐含信​​息是，要么加入人工智能编码工具，要么被抛在后面，对于一些怀疑论者来说，这可能是一个可怕的前景……

使用人工智能生成代码的风险

值得一提的是，上述两项研究均提及“AI 编码工具”（请参阅​​我们关于面向 API 开发人员的 AI 工具的文章），这不一定与 AI 生成的代码相同。例如，此类工具可能会建议完成代码或修复已知错误。

但肯定有人，包括开发人员和外行，纯粹用 AI 生成的代码创建工具和产品。在2024 年奥斯汀 API 峰会上，我们与Traceable AI 的 API 安全教育者Katie Paxton-Fear谈论了人们如此大规模使用 AI 生成的代码的一些影响。

“他们能够将自己的应用创意公之于众，这很棒，但他们不知道如何主动查看代码，看看它是否安全，或者这是否是最合适的做法，”帕克斯顿-菲尔说。“如果你使用人工智能生成的代码，你甚至可能不知道你的监管要求是什么。”

更不用说您是否满足了这些要求。而且，即使您知道存储特定数据的安全要求，您也可能不知道如何处理违规行为。

不过，帕克斯顿-菲尔观察到，相反的情况也可能是真的。“对安全一无所知的人可能可以通过询问 ChatGPT 或 Copilot 来了解一些常见的陷阱。而且我发现这对于那些不愿意或不敢询问高级工程师的初级开发人员来说很有用，因为他们担心会浪费他们的时间。”

我们之前曾介绍过如何使用 Hacking APIs GPT 等工具进行API 安全测试。其他公司也在为自己的工具筹集资金，专注于使用 AI 进行安全测试。至少就目前而言，此类工具当然应该被视为补充措施，而不是典型代码审查和测试的替代品。

有了正确的安全协议和可观察性，使用人工智能生成或人工智能辅助的代码就不成问题了。它甚至可以带来显著的好处。但在可能已经存在漏洞的情况下，依赖人工智能创建的代码可能非常危险。

使用人工智能生成代码的风险

在进入 API 领域之前，让我们先来看一下大局。使用 AI 生成的代码有各种相关风险，例如可能引入不准确或错误。事实上，10 多年前编写的数千个教程和帖子（现在已经完全过时了）最终可能会被用作训练数据。

Paxton-Fear 建议以PHP 的文档为例。文档中包含有关弃用的内容，但其中有些评论是 14 年前的，可能不再适用。“因此，我们将看到漏洞和攻击等我们以为已经处理过的问题再次出现，”她说。

幻觉也令人担忧。以ChatGPT 推荐的OpenCage Geocoding API 的电话查询功能为例……该功能并不存在。用 Paxton-Fear 的话来说，这是一个完美的例子，“人工智能告诉我们我们想听到什么”，而不是提供准确可靠的信息。

除了意外失误，还需要考虑一些恶意行为。在最近的一个案例中，网络犯罪分子通过一个恶意软件包推送恶意软件，该软件包被建议用于修复 StackOverflow 上的各种问题。

Paxton-Fear 表示，“我们完全可以期待看到人工智能对提示或问题的回答也会出现同样的情况，尤其是因为人工智能是非确定性的。聪明的攻击者可能会在训练数据中包含恶意程序包，并将其作为对不常被问到的真正具体问题的回答偷偷带入。”

为什么 AI编程 对 API 特别危险？

Paxton-Fear 认为，由于编写 API 的性质，开发人员使用 AI 生成的代码的一般风险在 API 领域会加剧。创建和记录端点可能是重复性的，甚至是无聊的，因此自动化该过程的动机很高。在这方面，API 比其他项目更容易受到这些风险的影响。

随着越来越多的产品将 AI 融入其产品中，我们可以期待更多外部工具被采用，例如 OpenAI 的 API。除了过度依赖 AI 的记录风险（这打破了 OWASP 的LLM 十大风险）之外，应用程序与此类 API 之间的交互始终存在以某种方式失败的风险。

“我们永远无法解决即时注入问题，”帕克斯顿-菲尔担心道。“如果你依赖人工智能输入来生成博客文章或代码，你就必须考虑常见的问题。你不一定能信任用户输入，而人工智能输入只是另一种形式。”你是否信任人工智能输入而不是工程师手动创建的东西则完全是另一个问题……

随着越来越多的应用程序开始依赖AI编程，我们最好希望它们的提供商能够出色地维护和保护这些产品。

我们能否降低风险并接受通用人工智能编码？

从表面上看，像 Paxton-Fear 这样自认对人工智能持怀疑态度的人，与 Gartner 的前分析师 Paul Dumas（后者预测人工智能将很快为你生成 API）的观点截然不同。

但事实上，它们确实有共同之处。Paxton-Fear 告诉我们，尽管她有所保留，但“我确实认为它是一种强大的创意工具，特别是对于知道自己在做什么的开发人员来说。他们可以查看代码并实际评估其质量。”这与 Dumas 的观点相呼应。

然而，Paxton-Fear 还观察到，工作场所的文化在降低 AI 生成代码的风险方面发挥着重要作用。“各级开发人员的衡量标准不是安全结果，而是代码行数、提交的功能和解决的工单数量。”

因此，他们被激励去提高效率，而且我们已经看到，使用人工智能可以大大减少他们必须做的工作。“但如果他们发现 [或没有发现] 他们缺少说明某些东西已被弃用或淘汰的文档，那么这确实存在风险，尤其是对于那些没有安全团队的组织来说。”

解决这一问题的一个可能方法是为高级工程师提供真正的平衡：让他们有机会更广泛地思考应用程序和全局问题，而不仅仅是审查请求。这会带来更具挑战性的问题，他们希望自己参与其中，而不是将工作外包给新一代人工智能工具。

最终，Paxton-Fear 得出结论，人工智能生成的代码应该是“与人类一起使用的工具，而不是人类的替代品”。就像 Paul Dumas 在奥斯汀 API 峰会主题演讲中所说的那样。好的 API文档会定期更新指南、安全问题等。由于滞后，人工智能工具很长时间内无法访问这些信息。而熟练的人类开发人员则可以。

“偷工减料有很多明显的好处，”帕克斯顿-菲尔随口说道。“闯红灯，你会更快到达目的地……大多数时候都是这样。但有一次你没有闯红灯？那就糟糕了。”

转载自：https://nordicapis.com/how-ai-generated-code-could-kill-your-api/