组织如何保护其人工智能代码

人工智能生成的代码无处不在，甚至在官方禁止使用的地方也是如此。网络安全领导者可以采取以下措施来确保其不会危及安全。

2023 年，数据提取初创公司 Reworkd 的团队面临着紧迫的期限。投资者向他们施压，要求他们通过该平台获利，他们需要将所有内容从 Next.js 迁移到 Python/FastAPI。为了加快速度，团队决定求助于 ChatGPT 来完成一些工作。人工智能生成的代码似乎可以运行，因此他们将其直接实施到生产环境中。然后就到此为止了。

第二天早上，他们醒来时发现了 40 多条关于用户投诉的 Gmail 通知，”联合创始人 Ashim Shrestha 在一篇文章中写道。博客文章。——一切似乎都在一夜之间着火了。这些用户都无法订阅。 –

第 56 行由 AI 生成的错误导致订阅过程中出现唯一 ID 冲突，他们花了五天时间才发现并修复该问题。Shrestha 写道，这个错误，即“ChatGPT 的一个错误就导致了 10,000 多美元的损失”。

虽然 Reworkd 对他们的错误持开放态度，但许多类似事件仍然未知。CISO 经常闭门了解它们。金融机构、医疗保健系统和电子商务平台都遇到了安全挑战，因为代码完成工具可能会引入漏洞、扰乱运营或损害数据完整性。许多风险与人工智能生成的代码、幻觉产生的库名称或引入未跟踪和未经验证的第三方依赖项有关。

“我们正面临一场完美风暴：对人工智能生成代码的依赖日益增加、开源库的快速增长以及这些系统固有的复杂性，”Veracode 首席技术官 Jens Wessling 说道。“安全风险升级是很自然的。”

通常，ChatGPT、GitHub Copilot 或 Amazon CodeWhisperer 等代码补全工具会被秘密使用。一项调查由斯尼克研究表明，大约 80% 的开发人员忽视安全策略来合并人工智能生成的代码。这种做法给组织带来了盲点，组织常常难以缓解由此出现的安全和法律问题。

随着自动化编码工具得到更广泛的采用，围绕其带来的风险的讨论已成为许多 CISO 和网络安全领导者的首要任务。虽然这些工具具有革命性，可以加速开发，但它们也带来了各种安全问题，其中一些难以检测。

确保软件包被识别

虽然人工智能驱动的代码完成工具的兴起开创了软件开发效率和创新的新时代，但这种进步也带来了重要的安全风险。“人工智能生成的代码通常与人类开发的代码无缝融合，因此很难判断安全风险来自何处，”Wessling 说。

有时，自动生成的代码可能包含第三方库或虚拟依赖项 - 未在清单文件中显式声明的依赖项。这些未报告的软件包在扫描过程中可能无法识别，并且可能隐藏漏洞。 

解决此问题的一种方法是使用软件组合分析 (SCA) 和软件供应链安全工具，帮助识别正在使用的库、漏洞以及可能带来的潜在法律和合规问题。 

“正确调整 SCA，使其看起来比表面更深入，这可能就是答案。”Secure Delivery 的 CSO 兼联合创始人 Grant Ongers 说道。但这个解决方案并不完美。“SCA 的更大问题往往是在从未被调用的库中的函数中包含漏洞，”他补充道。

Endor 实验室™2024 年依赖管理报告发现对于具有大量虚拟依赖足迹的组织来说，56% 的报告库漏洞存在于虚拟依赖项中。“我们预计这对组织来说将是一个日益严峻的挑战，并且工具需要能够让安全团队了解出于合规性和风险管理目的而使用的所有软件组件，”研究工程师 Darren Meyer 说道在恩多实验室。

这就是为什么组织拥有准确的软件组件清单非常重要。“如果没有它，您就无法识别、更不用说管理来自人工智能库或任何第三方库的风险，”Meyer 补充道。“如果您没有办法识别人工智能库（这些库是您的组织正在编写、发布和/或使用的软件的一部分），那么您可能会面临合规风险。”¤

当开发人员从 Hugging Face 等平台下载机器学习 (ML) 模型或数据集时，组织也会面临风险。 

“尽管两端都有安全检查，但模型仍然可能包含一个后门，一旦模型集成，该后门就会变得活跃，”有组织犯罪组织的开源开发人员 Alex Ètefänescu 说道。和腐败举报项目 (OCCRP)。“这最终可能导致使用恶意模型的公司的数据被泄露。”

据一家机构称，到 2024 年初，Hugging Face 平台托管了至少 100 个恶意机器学习模型，其中一些能够在受害者的机器上执行代码JFrog报告。

当谈到 GitHub Copilot 等代码补全工具时，Ètefänescu 担心出现幻觉。– LLM 始终会生成给定提示的统计上最可能的延续，因此无法真正保证它将从 PIPy 生成真实的包，例如，在单词“import”之后，他们说。– 一些攻击者意识到了这一点，并在 npm 和 PIPy 等平台上注册包名称，填充代码完成工具建议的一些功能，以使包看起来合法。 –

如果将这些包导入到实际应用程序中，它们可能会造成真正的损害。

为了解决这些风险，CISO 可以建立协议，用于从 Hugging Face 等外部平台下载和集成 ML 模型或数据集。这包括实施自动扫描工具来检测恶意代码或后门，制定仅允许使用经过验证的发布者的模型的策略，或在隔离环境中进行内部测试。

通过AI编码助手确保敏感信息不泄露

根据 GitGuardian 的报告，近一半的组织担心人工智能系统学习和复制包含敏感信息的模式2024 年从业者之声调查。“这尤其令人担忧，因为这些工具建议的代码基于从训练数据中学习的模式，例如，这可能会无意中包含硬编码的凭据，”GitGuardian 的报告作者 Thomas Segura 说。

总部位于美国的公司尤其担心，由于开发人员使用人工智能驱动的代码完成工具，敏感信息可能会无意中泄漏到代码库中。

虽然没有灵丹妙药，但组织可以采取一些措施来降低这种风险。“使用不报告数据的自托管人工智能系统是一个有效的答案，”翁格斯说。– 另一个是确保数据无法进入。 – 

放眼传统开发团队之外

并非所有基于人工智能的工具都来自由软件工程师组成的团队。“我们看到许多采用是由组织内的数据分析师、营销团队、研究人员等推动的，”Meyer 说。

这些团队传统上并不开发自己的软件，而是越来越多地编写采用人工智能库和模型的简单工具，因此他们通常没有意识到所涉及的风险。“影子工程与低于平均水平的应用程序安全意识的结合可能成为风险的滋生地，”他补充道。

为了确保这些团队安全工作，CISO 必须考虑在此过程的早期与这些团队建立关系。网络安全领导者可能还希望制定针对非传统开发团队的培训计划，以教育数据分析师、营销专业人员和研究人员了解与基于人工智能的工具和库相关的潜在风险。

确保应用程序安全的安全资源

“安全预算通常不会以与软件开发加速相同的速度增长，而人工智能的采用只会扩大这一差距。”Meyer 说。大多数组织中的应用程序安全资金往往不足，但分配了足够的时间和精力随着人工智能的采用和人工智能辅助编码加快了软件开发的步伐，为此提供的资源至关重要。

“可以帮助解决这一差距的高质量安全工具组合不再是可选的，”Meyer 说。“虽然工具对于缩小差距至关重要，但 AppSec 和 ProdSec 员工也同样重要，他们可以有效地与开发人员（甚至是非传统开发人员）合作，并了解人工智能的技术、合规性和安全影响。”¤

当谈到获得足够的资源来保护人工智能系统时，一些利益相关者可能会犹豫，将其视为一项可选费用，而不是一项关键投资。“在许多组织中，人工智能的采用是一个存在分歧的话题，一些领导者和团队“全力支持”采用，而另一些则强烈抵制，”Meyer 说。– 这种紧张关系可能会给富有洞察力的 CISO 和企业信息安全官 (BISO) 带来挑战。 –

意识到这样做的优点和缺点的 CISO 可能会尝试设置控制措施来有效管理风险，但如果他们不正确解释自己所做的事情，这可能会让人觉得他们阻碍了组织的创新。“组织需要制定全面的战略，平衡人工智能工具的生产力优势与强大的安全实践，”Segura 说。

不安全的人工智能驱动的开源库的风险

随着人工智能改变代码编写方式，业界正在抓住人工智能提供的机遇和减轻其可能带来的风险之间的微妙界限。昂格斯表示，这种范式的改变带来了一些担忧。“我认为最大的问题是两个极端之一：要么过度依赖有缺陷的人工智能，要么完全忽视人工智能，”他说。

目前已有超过 500 万个开源库可供使用，预计未来十年还将发布 5 亿个开源库，其中许多库将由人工智能提供支持，组织在管理与其软件生态系统相关的安全风险方面面临着前所未有的挑战。一个 

“这对行业来说是一个陌生的领域，我确实认为需要在行业层面解决风险，以确保为我们的世界提供动力的软件的安全性和质量，”Wessling 说。

如何解决这些问题也很重要。目前，声称能够保护人工智能安全的安全供应商激增，但并非所有供应商都做得一丝不苟。结果，“组织可能既没有做出明智风险决策所需的可见性，也没有根据这些决策采取行动所需的能力，”迈耶说。– 当新闻中出现漏洞时，CISO 不希望发现自己处于构建新能力的境地，或者更糟糕的是，当他们的组织遭到破坏时。Ø