AI 生成代码如何影响API安全？

根据 GitHub 的研究，到 2023 年，多达 92% 的美国开发人员会在 “工作内外 “使用人工智能编码工具。 GitHub进行的另一项研究发现，使用Copilot（GitHub开发的一款工具）的人完成任务的速度比没有使用该工具的人快55%。

然而，对人工智能的依赖也带来了潜在的后果。 比尔-多尔费尔德（Bill Doerrfeld）表示：”由于产生的代码量巨大……如果没有防护措施，生成式人工智能很可能会导致更多的技术债务。 当你可以直接抛弃代码并生成新的代码时，为什么还要重复使用和完善代码呢？

当开发人员使用人工智能以一种他们并不熟悉的语言生成代码时，也会出现问题。他们了解相关的最佳实践吗？ 安全风险？ 如何解决出现的问题？ 这些问题的答案往往是响亮的 “不”。

不过，上述研究隐含的信息是，要么使用人工智能编码工具，要么就被淘汰出局，而这对于一些持怀疑态度的人来说，可能是一个可怕的前景。

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

值得指出的是，上述两项研究都提到了 “人工智能编码工具”，这与人工智能生成的代码并不一定是一回事。 例如，此类工具可能会建议代码补全或修复已知错误。

但肯定有一些人，包括开发人员和普通人，纯粹利用人工智能生成的代码来创建工具和产品。 在 2024 年奥斯汀 API 峰会上，我们采访了 Traceable AI 公司的 API 安全教育专家 Katie Paxton-Fear，她谈到了人们如此大规模地使用人工智能生成的代码所带来的一些影响。

“他们能够把自己的应用想法发布出去，这很好，但他们不知道如何主动查看这些代码是否安全，或者这是否是最合适的做事方式，”Paxton-Fear 说。 “如果你使用的是人工智能生成的代码，你甚至可能不知道你的监管要求是什么。”

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

帕克斯顿-费尔（Paxton-Fear）认为，事实可能恰恰相反。 “对安全一无所知的人也许可以通过询问 ChatGPT 或 Copilot 了解到一些常见的陷阱。我可以看到，这对那些因为害怕浪费时间而不敢或没有信心向高级工程师提问的初级开发人员来说非常有用。

我们之前介绍过 Hacking APIs GPT 等工具如何用于 API 安全测试。 还有一些公司正在为自己的工具寻求资金，重点是使用人工智能来测试安全性。当然，至少在目前，这类工具应被视为补充措施，而不是典型的代码审查和测试的替代品。

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

在进入应用程序接口领域之前，让我们先来看看全局。使用人工智能生成的代码有各种相关风险，例如可能会引入不准确或错误。 事实上，成千上万篇 10 多年前编写的教程和文章（现在已完全过时）最终都可能被用作训练数据。

Paxton-Fear 建议，以 PHP 的文档为例。 文档中包含有关废弃的注释，但其中有一些 14 年前的注释可能已经不再适用。 “她说：”因此，我们将看到一些我们认为已经处理过的问题，如漏洞和漏洞利用，又重新出现了。

幻觉也令人担忧。考虑到 ChatGPT 推荐 Open Cage Geocoding API 的电话查询功能……而这一功能并不存在。用帕克斯顿-费尔（Paxton-Fear）的话说，这是一个完美的例子，”人工智能告诉我们我们想听的东西”，而不是提供准确可靠的信息。

除了意外的失误，还有一些主动的恶意活动也值得考虑。 在最近的一个案例中，网络犯罪分子通过一个恶意软件包在 StackOverflow 上推送恶意软件，该恶意软件包被建议作为各种问题的修复程序。

Paxton-Fear 认为，”我们完全可以预见，人工智能生成的对提示或问题的回答也会出现同样的情况，尤其是因为人工智能是非确定性的。 聪明的攻击者可能会在训练数据中加入恶意软件包，并将其作为对不会经常被问到的真正具体问题的回答偷偷加入其中”。

为什么 Gen AI 对 API 尤为危险？

Paxton-Fear 认为，由于编写应用程序接口的性质，开发人员使用人工智能生成代码的一般风险在应用程序接口领域更为复杂。 创建和记录端点可能是重复性的，甚至是枯燥乏味的，因此自动化流程的积极性很高。 在这方面，应用程序接口比其他项目更容易受到这些风险的影响。

随着越来越多的产品将人工智能集成到自己的产品中，我们可以期待像 OpenAI 的 API 这样的外部工具被进一步采用。 除了记录在案的过度依赖人工智能的风险之外（这也是 OWASP 列出的十大风险之一），应用程序与此类 API 之间的交互始终存在以某种方式失败的风险。

“我们永远无法解决及时注入问题，”Paxton-Fear 担心道。 “如果你依赖人工智能输入来生成博文或代码，你就必须寻找常见的嫌疑人。 你不一定能信任用户输入，而人工智能输入只是用户输入的另一种形式。 你是否信任人工智能输入而不是工程师手动创建的东西，这完全是另一个问题……

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

我们能否降低风险并拥抱新一代人工智能编码？

从表面上看，像帕克斯顿-费尔（Paxton-Fear）这样自认对人工智能持怀疑态度的人，与 Gartner 的前分析师保罗-杜马斯（Paul Dumas）（他预测人工智能很快就会为你提供应用程序接口）的观点大相径庭。

但事实上，他们确实有共同之处。 帕克斯顿-费尔告诉我们，尽管她有所保留，但 “我确实认为这是一个强大的创造性工具，尤其是对于那些知道自己在做什么的开发人员来说。 他们可以查看代码，并实际评估其质量”。 这与 Dumas 的观点不谋而合。

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

因此，他们有动力提高效率，而我们已经看到，使用人工智能可以减少他们必须做的工作，从而提供很大的帮助。”但是，如果他们发现[或没有发现]他们缺少解释某些东西已被弃用或日落的文档，就会存在真正的风险，尤其是对于那些没有真正安全团队的组织而言。”

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

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

“少走弯路有很多明显的好处，”Paxton-Fear 断言。 “闯过每一个红灯，你就能更快地到达目的地……大多数时候都是这样。 有一次你没有？ 那就糟了”

原文链接：How AI-Generated Code Could Kill Your API