作者 | 李冬梅、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

關鍵詞：