作者 | 李冬梅、Tina

(资料图)

近年来，开源软件的使用率越来越高，许多组织依赖它作为其 IT 基础设施的重要组成部分。然而，开源软件供应链安全已成为各组织的主要关注点，因为使用开源软件会给其系统带来漏洞和安全风险。

ChatGPT、Bard 等大语言模型问世后，其带来工作效率的提升让人们积极地探索如何将这些大模型能力应用到各行各业中。但不得不注意到是，用于训练这些大模型的数据通常来源于公开获取的内容，如果数据源被攻击者控制，在数据标注时又未能及时识别出这些恶意数据，那么攻击者就有可能通过这些恶意的数据干扰模型结果。

此前，Google 在发布 Bard 时就因为提供了错误的事实结果，导致当日股价大跌。

在使用公开数据集训练 ChatGPT、Bard 这类大语言模型时会不会为后续的结果带来隐患？使用大模型在安全方面究竟是利大于弊还是弊大于利？大模型带来生成力大幅提升，同时也会存在安全上的问题，我们该如何权衡？近日，InfoQ 有机会再次采访了 OpenSSF CTO Brian Behlendor，听他来聊一聊对上述相关问题的看法。

Brian Behlendorf：当然，OpenSSF 仍在继续发展。我们继续吸引更多企业成为基金会成员。我们目前已经拥有 100 多家成员组织，更多公司的加入也让我们获得了做好安全工作的资源。过去 6 个月来，最大的一项成果就是推出了 SLSA，即针对软件工件的供应链等级。这是一种对供应链和软件构建安全程度的描述方式，它贯穿整个软件供应链，允许大家设置政策以适应所在行业的监管政策及要求。

我们都知道，世界各地的监管机构和政府越来越关注如何将软件纳入整个供应链体系，这正是解决问题的关键所在。

最后是另一个重大改变是关于我的工作内容的变动。从 2021 年秋季、也就是 9 月左右加入以来，我一直以总经理的身份领导 OpenSSF。但从上个月开始，我把职务移交给了另一位新任总经理，Omkhar Arasaratnam。

Omkhar 非常出色，他在安全和软件安全方面拥有深厚的专业背景，是位领域专家。他曾在谷歌工作，还曾先后在英国一家大型银行、IBM 和其他多家金融服务公司任职。他带来了很多知识，比如如何遵循各种监管要求，以及如何构建起真正安全的产品。其实我们 OpenSSF 所做的就是把这些要素整合起来，集成到顺畅连贯的技术套件当中。

对于各种开源软件供应链，包括 npm、pip、rust 和 java 等供应链，我们希望各方也能将这些上游技术整合到他们的工作流程当中，整合到他们的核心工具当中。这样无论是 java 生态系统还是 npm 生态系统，所有软件都将受到默认的保护。

这才是我们真正的目标和愿景所在。Omkhar 在软件工程和安全工程方面的背景非常重要。我本人则会转任 CTO，进一步建立贡献者社区，并投身于 AI 等领域。总之，我能腾出精力走出 OpenSSF 之外，扮演好倡导和布道的角色。

用开源代码和公开数据训练大模型，安全吗？

Brian Behlendorf：我觉得应该不会有什么隐患，反倒是件好事。虽然总会有一些组织发挥主导作用，比如 OpenAI 和其他一些构建专有增强功能的机构。但总体而言，我觉得大语言模型的价值会向训练集转移，包括更多受到训练集规则的影响，而不再单纯集中在生成模型的开源代码之内。

而且源代码的演进也会不断分层，除了由 Python、Rust 和 Ruby 编写的算法之外，数据集和训练集也会给大语言模型带来深远影响。

目前，基于开源许可的训练集在质量上还不及 ChatGPT 和其他非开源精选训练集。但情况正在改善，LLaMA 和 Hugging Face 等正带来越来越好的开源训练集。我认为在未来某个时候，这些训练集甚至将超越 ChatGPT，而且具体时间甚至有可能是在今年之内或明年年初。

所以我对开源社区在解决当前各种固有缺陷方面的作用保持乐观态度，比如长期困扰大语言模型的幻觉问题，比如说可以由额外的模型检索线上参考资料来确定大语言模型给出的结论是否属实。

当然，我们也可以寄希望于开源 AI 模型发展得越来越好，凭借自己的力量解决这个问题。

Brian Behlendorf：我觉得开源软件领域已经在所有权方面摸索出了很好的解决办法，对吧？开源代码都有其版权所有者和相应的许可证。许可证条款会赋予使用者一部分权利，同时提出相应要求。那这些许可证不仅适用于 Python 编写的算法和软件，应该也适用于训练集。

只要对开源代码的所有权和许可证做点修改或延伸，就能把训练集也覆盖进来。这个问答在开源领域已经有了答案，比如个人贡献者围绕 Apache 或其他项目提交了成果，那么最终产品就由 Apache 软件基金会、Linux 基金会或者 OpenSSF 拥有版权。这些非营利组织在某种程度上起到了保护作用，有助于协调贡献活动，同时也为贡献者和最终用户服务提供了法律保护，让每个人都能安心遵守开发方与使用方之间的社会契约。

我认为这种社会契约、透明度和即时可访问性，都能非常直接地被应用到大语言模型身上。

Brian Behlendorf：我们可以跳出软件之外考虑这个问题。美国前段时间闹出这么件事，说有个律师找 ChatGPT 帮他写法庭案件提要。ChatGPT 提出了一大堆并不存在的判例，根本就是凭空捏造的。但律师根本懒得检查作业，直接把材料递交给了法官。法官很生气，因为律师把自己的大名签在了文件上。跟 AI 生成文本一样，AI 生成代码也可能有错误，或者说必然会出错。

那开发人员就有责任验证这些内容，保证其正确性，甚至编写测试来验证这种正确性。也许测试也可以由 AI 编写，但无论如何最终的责任还是要由开发人员承担。所以身为优秀的开发人员，大家必须善于阅读代码。毕竟之前这些繁重的编程工作都得亲自动手，现在有了 ChatGPT 代劳，这肯定不是坏事。所以我倒是非常乐观，相信模型肯定能根据提示词编写出越来越好的代码，我们也能借助 AI 更好地检测出代码中的安全漏洞。

就是说，我们可以把结果交给其他生成工具，即时对生成的代码做安全检查。但有些安全漏洞需要参考整个系统才能被检测出来，这对 AI 系统来说就很困难了。AI 虽然能快速浏览完整文档，但却无法同时查看 10 万行代码，再把其中可能构成错误的逻辑链整理出来。这就是问题所在，所以人类程序员还是得保持深入研究、了解问题根源的能力。正因为如此，开发人员才特别有必要了解大语言模型中的各个层及其构建方式。无论如何，我坚信大语言模型将成为一种非常高效的加速器，能帮助更多人成为 10 倍开发者。

出现问题，别“甩锅”给 ChatGPT

Brian Behlendorf：我不知道中文场景会不会这样，但在英文场景下，当我们在手机上打字时，拼写检查有时候会错误提示甚至修改某些单词。可最终按下发送键的仍然是人，是人决定使用提示结果的，对吧？所以仍然要由人来负责。而且我觉得这种勇于承担责任的心态非常重要，绝不能单纯说是 AI 弄错了。不不，无论是作为开发人员、产品经理还是律师，我们都必须对生成的内容承担起所有权和责任。而且未来错误会越来越少，需要手动处理的工作量也会越来越小。我们肯定能用 AI 来检查其他 AI 生成的内容，会有多种 AI 和多种工具以某种方式结合起来，让使用者对其生成的内容抱有更大的信心。

Brian Behlendorf：是这样的。

Brian Behlendorf：软件开发工具是安全体系中的重要组成部分。一旦开发工具就存在安全漏洞，那漏洞肯定会渗透进它所创建的代码中。好消息是，目前大多数软件开发工具都是开源项目，比如说 eclipse 和 emacs，还包括 GitHub 中内置的很多功能，都是基于开源代码。这是因为开发人员需要知晓这些工具内部到底是怎样运作的。虽然不是人人在乎，但总有百分之一或者千分之一的开发者想搞清楚底层代码的原理。

我认为一定要让 AI 世界远离像 ChatGPT 这样单一的集中式专有模型。在我看来，ChatGPT 就类似于 AI 界的微软 Windows。它属于典型的集中加专有型产品。它专属于一家公司，虽然他们愿意开放 API 供其他人使用，但其本质仍然是个专有平台。而真正的开源模型应该允许任何人参与，你可以构建模型，我也可以构建模型，每个人都能加入进来并做出修改。那将是一个与如今 ChatGPT 的形态完全不同的新世界，也是我们应该为之奋斗的未来。只有这样，大语言模型生成的代码才能具备更高的安全性。

Brian Behlendorf：我觉得还是利大于弊，就是说它们生成的代码仍然比人类更安全，前提是双方投入的时间相同。大语言模型就像是加速器，如果非要从反面来看，那 10 倍开发者制造安全漏洞的速度也是 10 倍呢。所以我们不仅要投资大语言模型，也要投资建设更好的扫描工具，这一点非常重要。

应该努力利用工具帮助发现其中的各种安全缺陷，我们 OpenSSF 也在通过 Alpha-Omega 项目努力达成这个目标。该项目的核心，就是找出广泛存在于大量开源项目中的简单 bug。我们要如何扫描数以万计的现有项目，并找到其中的 bug？这是一项体量巨大的工程，找出的 bug 往往影响成百上千个项目。所以我们要做的就是先想办法做扫描，再开发出自动修复程序，最后把修复成果以 PR 的形式提交上去。这方面研究工作目前由 Jonathan Bryce 负责，我们聘请他加入进来并推动项目发展。

我们觉得这是个下限问题，即应该努力提高常用开源项目的质量下限。作为其中的关键部分，此举将有助于捕捉大语言模型可能在代码中引入的常见 bug。当然，编写测试、使用模糊测试工具等工作还是要由开发人员亲自负责，这样才能真正贯彻提升软件质量和安全性的最佳实践。

我认为开发永远是人与工具的结合。这有点像赛车运动，现在很多比赛已经从手动变速箱升级成了自动变速箱，对吧？但用哪种变速箱并不是重点，重点在于怎样比其他对手跑得更快。开发也是，要不要使用 AI 生成的代码并不是重点，重点在于如何更好地构建安全代码并帮助其他人安全使用开发成果。

Brian Behlendorf：我觉得这个要具体问题具体分析，至少要搞清楚他们到底在用哪些开源代码做训练。因为如果他们使用的是排名前 1000，或者说前 10000 的项目代码，那么这类训练集的代码质量其实是很高的。毕竟 GitHub 上有上亿个 repo，Gitee 也不遑多让。其中很多是教学用的项目或者一次性项目，还有其他项目的特定分支，这里确实有很多非常垃圾、质量极差。

我希望构建模型的团队能认真考量训练集中的内容。在 OpenSSF，我们开发出一款名叫 Security Scorecard 的工具。在对 GitHub repo 使用后，它会打出 0 到 9 分的相应得分，借此说明目标代码的可信度如何、存在 bug 的可能性有多大。如果只得到 1 分，则代表目标代码可能因管理不善而存在尚未发现的 bug，或者是未经过模糊测试。总之它能提供各种各样的启发和辅助。

所以只要以此为基础构建起训练集，就能挑选出在 Scorecard 上得分较高的项目代码，比如要求其至少要得到 7 分。正如我之前所说，理解训练集中的内容跟理解源代码中的内容同等重要。

安全应该考虑在模型构建之前，而不是之后

Brian Behlendorf：没错，而且我觉得这会是个持续的过程。也许大家投入到模型完善上的精力，会超过软件开发本身。

Brian Behlendorf：目前还没有多少开源项目把 AI 代码直接纳入进来，但我觉得每位面向最终用户的开发者都会使用网络浏览器、文本编辑器和 WordPress/Dribble 之类的工具。

而这些工具，正是大语言模型介入开发流程的载体，或者说通往 OpenAI API 的门户。希望未来会有更多内置模型的出现，但目前我觉得 AIGC 还不能说已经成为软件供应链的一部分。不过我认为这些工具正变得越来越重要，跟 SBOM，也就是软件物料清单差不多。或者是我之前提到的 Scorecard，还有 OpenSSF 用于为供应链目标分配签名的 Sigstore，以及反映安全水平的 SLSA 规范等。

我觉得这些技术都能被轻松纳入训练集，以及由这些训练集编译成的模型。它们适用于源代码和文档，自然也适用于大语言模型。

Brian Behlendorf：我觉得绝对有可能，毕竟模型会边组装边沿着供应链向下游移动，之后可能有恶意分子突然介入并替换或篡改其中的训练集，导致模型偏离既定的学习路线。

所以我要再次强调，必须要用保护供应链内源代码和其他构建工件的相同工件保护 AI 模型，因为它们在完整性上有着同等重要的意义。

Brian Behlendorf：可以用 Sigstore 这类方案。它会为每个对象分配签名，并在不同对象结合起来时再分配新的签名。它能覆盖到供应链中的所有对象，这种形式跟钻石供应链非常相似。比如我们到店里挑选钻石，当然希望心仪的宝钻不是出自被非法奴役的劳作者之手。但问题是要如何验证？答案就是使用上游开发者的加密签名。这种机制能够证明代码来自上游开发者，且到达当前环节前没有经过篡改。Sigstore 想要起到的就是这样的作用，而且效果不错。Sigstore 目前已经在云原生生态系统中得到了广泛应用。

所以当软件在供应链中往来流动时，我们可以依靠 Sigstore 防止中间人攻击。它还可以在 SBOM 等环节上发挥作用。所以投毒确实是个大问题，但我觉得把 AI 模型当作供应链内的其他对象做统一管理即可。

AIGC 对开源软件意味着什么？

Brian Behlendorf：我觉得肯定能用 AI 帮助开发者构建更好的扫描工具，检测出更多安全漏洞。之后，我们可以把 AI 引入开发工具当中，比如在人们提交 PR 时自动扫描其中的安全问题。目前供应链中的组织正变得极为复杂，比如企业往往会在世界各地设有多处数据中心，掌握着大量外部和内部应用程序并设定有不同的安全级别，这一切都要借助 AI 的力量。AI 明显特别擅长处理海量数据、将数据内容可视化、提取见解并快速找到异常。所以是的，我相信 AIGC 的发展肯定会给软件世界带来助益。

反正我非常乐观。目前已经有人在应用机器学习来扫描漏洞，虽然难度很高而且尚处于早期发展阶段，但我仍看好这方面探索。

Brian Behlendorf：确实，但扫描工具其实不涉及生产中的关键路径，影响范围只局限于供应链之内，对吧？所以我觉得多做点实验也未尝不可，而且大家可以把它作为一种对现有扫描工具的启发性探索。总之，AI 工具就是实现扫描的一种办法，不要把它想得有多特殊。

Brian Behlendorf：我觉得他们主要是担心在使用这些工具时，目前能够仰仗的主要是集中式服务。假定大家在一家大企业工作，并要求 ChatGPT 生成一款能够完成 a、b 和 c 任务的软件，那这些具体要求就会成为 OpenAI 服务器内部的专有信息。这显然与大部分信息管理原则有所冲突。但如果这些工具能够保持去中心化，就是说不单纯由 OpenAI 和 ChatGPT 来实现，而是一切都在本地、在我们面前实现，情况当然就不一样了。

那样这些安全问题，这些隐私或数据管理问题将不复存在。所以我们才更需要着力推动开源大语言模型的快速发展，而不能坐视整个世界围着 ChatGPT 打转，对不对？

如何安全地使用 ChatGPT？

Brian Behlendorf：我觉得倒是不至于。至少我还没听到有人说 AI 生成的代码因为质量低下而引发失控。确实，如果你是计算机科学专业的大一学生，而且打算全靠 ChatGPT 帮你完成作业，那它生成的代码确实惨不忍睹、搞得你挂了科，但这纯属自作自受。身为开发人员，大家必须保证 AI 生成的结果真正与需求和目标相匹配，要能够真正解决问题。你想借它之手搞定一切，这肯定不行，但我相信未来这些工具会表现得越来越好。

所以从长远角度来看，我仍然保持乐观。但在短期之内，大家使用时千万要谨慎。

Brian Behlendorf：我一直强调测试驱动开发的重要意义。就是说要先定义测试，然后再编写出能通过这些测试的代码。在我看来，大家应该先从人的角度入手编写测试，再让 ChatGPT 输出代码，依靠测试来确保 AI 生成的代码符合需求。

当然，大家也可以要求 ChatGPT 代为编写测试，对吧？但不管怎么操作，阅读代码、理解代码逻辑和保证代码发挥正确作用的责任永远都在我们自己肩上。

在安全对抗当中，“守方”永远是被动的一方，而恶意人士往往总会抢先一步。考虑到这样的现实，AIGC 也许会给开源社区带来巨大威胁。

Brian Behlendorf：我们正计划组建新的工作组，专注于 AI/机器学习方向。其中一半成员考虑如何使用工具来更好地保障供应链安全，而另一半成员则更多关注使用环节的安全问题。目前我们尚处于起步阶段，未来应该会逐步提出建议和方法，甚至在领域当中交付一些工具或规范。

所以要做断言还为时过早。而且我个人认为，守方不一定就是被动的一方。安全保护工作也可以主动出击。比如定期检查漏洞，在开源项目中每年或者每两年组织一次安全审计。花点钱让专业人士梳理现有代码，查找安全漏洞。还有，可以针对自己的基础设施组织红队演练。身为 CIO，大家应该主动尝试渗透己方基础设施。是的，安全保护完全可以出去起来，不一定要陷入被动。我觉得这种心态本身就该扭转，这样我们才能时刻做好准备，无论 AI 最终会不会像人们想象得那样得到广泛普及。

本文转载来源：

https://www.infoq.cn/article/dalIGpeiZNB8m93pPGti

标签：