專訪 OpenSSF CTO：安全問題應該考慮，别出問題就讓 ChatGPT 背鍋

作者 | 李冬梅、Tina

過去幾年，資料庫可信生态的建構情況到底如何？标準到底是什麼？技術層面取得了哪些進展？這些進展又将如何與産業做結合？各行業在實踐層面的最佳方法論到底是什麼？如果你希望擷取上述問題的答案，歡迎報名參加【2023 可信資料庫發展大會】。

近年來，開源軟體的使用率越來越高，許多組織依賴它作為其 IT 基礎設施的重要組成部分。然而，開源軟體供應鍊安全已成為各組織的主要關注點，因為使用開源軟體會給其系統帶來漏洞和安全風險。

ChatGPT、Bard 等大語言模型問世後，其帶來工作效率的提升讓人們積極地探索如何将這些大模型能力應用到各行各業中。但不得不注意到是，用于訓練這些大模型的資料通常來源于公開擷取的内容，如果資料源被攻擊者控制，在資料标注時又未能及時識别出這些惡意資料，那麼攻擊者就有可能通過這些惡意的資料幹擾模型結果。

此前，Google 在釋出 Bard 時就因為提供了錯誤的事實結果，導緻當日股價大跌。

在使用公開資料集訓練 ChatGPT、Bard 這類大語言模型時會不會為後續的結果帶來隐患？使用大模型在安全方面究竟是利大于弊還是弊大于利？大模型帶來生成力大幅提升，同時也會存在安全上的問題，我們該如何權衡？近日，InfoQ 有機會再次采訪了 OpenSSF CTO Brian Behlendor，聽他來聊一聊對上述相關問題的看法。

InfoQ：能不能跟我們分享一下，OpenSSF 最近取得了哪些新進展？

Brian Behlendorf：當然，OpenSSF 仍在繼續發展。我們繼續吸引更多企業成為基金會成員。我們目前已經擁有 100 多家成員組織，更多公司的加入也讓我們獲得了做好安全工作的資源。過去 6 個月來，最大的一項成果就是推出了 SLSA，即針對軟體工件的供應鍊等級。這是一種對供應鍊和軟體建構安全程度的描述方式，它貫穿整個軟體供應鍊，允許大家設定政策以适應所在行業的監管政策及要求。

我們都知道，世界各地的監管機構和政府越來越關注如何将軟體納入整個供應鍊體系，這正是解決問題的關鍵所在。

最後是另一個重大改變是關于我的工作内容的變動。從 2021 年秋季、也就是 9 月左右加入以來，我一直以總經理的身份上司 OpenSSF。但從上個月開始，我把職務移交給了另一位新任總經理，Omkhar Arasaratnam。

Omkhar 非常出色，他在安全和軟體安全方面擁有深厚的專業背景，是位領域專家。他曾在谷歌工作，還曾先後在英國一家大型銀行、IBM 和其他多家金融服務公司任職。他帶來了很多知識，比如如何遵循各種監管要求，以及如何建構起真正安全的産品。其實我們 OpenSSF 所做的就是把這些要素整合起來，內建到順暢連貫的技術套件當中。

對于各種開源軟體供應鍊，包括 npm、pip、rust 和 java 等供應鍊，我們希望各方也能将這些上遊技術整合到他們的工作流程當中，整合到他們的核心工具當中。這樣無論是 java 生态系統還是 npm 生态系統，所有軟體都将受到預設的保護。

這才是我們真正的目标和願景所在。Omkhar 在軟體工程和安全工程方面的背景非常重要。我本人則會轉任 CTO，進一步建立貢獻者社群，并投身于 AI 等領域。總之，我能騰出精力走出 OpenSSF 之外，扮演好倡導和布道的角色。

用開源代碼和公開資料訓練大模型，安全嗎？

InfoQ：聽說現在很多大語言模型都在使用開源代碼或者公開的資料進行模型訓練，您覺得這裡會不會有什麼隐患？

Brian Behlendorf：我覺得應該不會有什麼隐患，反倒是件好事。雖然總會有一些組織發揮主導作用，比如 OpenAI 和其他一些建構專有增強功能的機構。但總體而言，我覺得大語言模型的價值會向訓練集轉移，包括更多受到訓練集規則的影響，而不再單純集中在生成模型的開源代碼之内。

而且源代碼的演進也會不斷分層，除了由 Python、Rust 和 Ruby 編寫的算法之外，資料集和訓練集也會給大語言模型帶來深遠影響。

目前，基于開源許可的訓練集在品質上還不及 ChatGPT 和其他非開源精選訓練集。但情況正在改善，LLaMA 和 Hugging Face 等正帶來越來越好的開源訓練集。我認為在未來某個時候，這些訓練集甚至将超越 ChatGPT，而且具體時間甚至有可能是在今年之内或明年年初。

是以我對開源社群在解決目前各種固有缺陷方面的作用保持樂觀态度，比如長期困擾大語言模型的幻覺問題，比如說可以由額外的模型檢索線上參考資料來确定大語言模型給出的結論是否屬實。

當然，我們也可以寄希望于開源 AI 模型發展得越來越好，憑借自己的力量解決這個問題。

InfoQ：但換個角度說，利用開源代碼進行訓練會不會存在開源許可上的問題？

Brian Behlendorf：我覺得開源軟體領域已經在所有權方面摸索出了很好的解決辦法，對吧？開源代碼都有其版權所有者和相應的許可證。許可證條款會賦予使用者一部分權利，同時提出相應要求。那這些許可證不僅适用于 Python 編寫的算法和軟體，應該也适用于訓練集。

隻要對開源代碼的所有權和許可證做點修改或延伸，就能把訓練集也覆寫進來。這個問答在開源領域已經有了答案，比如個人貢獻者圍繞 Apache 或其他項目送出了成果，那麼最終産品就由 Apache 軟體基金會、Linux 基金會或者 OpenSSF 擁有版權。這些非營利組織在某種程度上起到了保護作用，有助于協調貢獻活動，同時也為貢獻者和最終使用者服務提供了法律保護，讓每個人都能安心遵守開發方與使用方之間的社會契約。

我認為這種社會契約、透明度和即時可通路性，都能非常直接地被應用到大語言模型身上。

InfoQ：根據研究論文，目前 GPT 生成的代碼中可能有 40%的代碼帶有至少一個漏洞。在您看來，像 ChatGPT 這樣的大模型未來能産出安全代碼嗎？

Brian Behlendorf：我們可以跳出軟體之外考慮這個問題。美國前段時間鬧出這麼件事，說有個律師找 ChatGPT 幫他寫法庭案件提要。ChatGPT 提出了一大堆并不存在的判例，根本就是憑空捏造的。但律師根本懶得檢查作業，直接把材料遞交給了法官。法官很生氣，因為律師把自己的大名簽在了檔案上。跟 AI 生成文本一樣，AI 生成代碼也可能有錯誤，或者說必然會出錯。

那開發人員就有責任驗證這些内容，保證其正确性，甚至編寫測試來驗證這種正确性。也許測試也可以由 AI 編寫，但無論如何最終的責任還是要由開發人員承擔。是以身為優秀的開發人員，大家必須善于閱讀代碼。畢竟之前這些繁重的程式設計工作都得親自動手，現在有了 ChatGPT 代勞，這肯定不是壞事。是以我倒是非常樂觀，相信模型肯定能根據提示詞編寫出越來越好的代碼，我們也能借助 AI 更好地檢測出代碼中的安全漏洞。

就是說，我們可以把結果交給其他生成工具，即時對生成的代碼做安全檢查。但有些安全漏洞需要參考整個系統才能被檢測出來，這對 AI 系統來說就很困難了。AI 雖然能快速浏覽完整文檔，但卻無法同時檢視 10 萬行代碼，再把其中可能構成錯誤的邏輯鍊整理出來。這就是問題所在，是以人類程式員還是得保持深入研究、了解問題根源的能力。正因為如此，開發人員才特别有必要了解大語言模型中的各個層及其建構方式。無論如何，我堅信大語言模型将成為一種非常高效的加速器，能幫助更多人成為 10 倍開發者。

出現問題，别“甩鍋”給 ChatGPT

InfoQ：您是說即使是出現故障或錯誤，也不是 ChatGPT 的錯，歸根結底問題出在開發者身上，對吧？

Brian Behlendorf：我不知道中文場景會不會這樣，但在英文場景下，當我們在手機上打字時，拼寫檢查有時候會錯誤提示甚至修改某些單詞。可最終按下發送鍵的仍然是人，是人決定使用提示結果的，對吧？是以仍然要由人來負責。而且我覺得這種勇于承擔責任的心态非常重要，絕不能單純說是 AI 弄錯了。不不，無論是作為開發人員、産品經理還是律師，我們都必須對生成的内容承擔起所有權和責任。而且未來錯誤會越來越少，需要手動處理的工作量也會越來越小。我們肯定能用 AI 來檢查其他 AI 生成的内容，會有多種 AI 和多種工具以某種方式結合起來，讓使用者對其生成的内容抱有更大的信心。

InfoQ：是以說 AI 能做什麼、不能做什麼要取決于人，而不是技術本身，對吧？

Brian Behlendorf：是這樣的。

InfoQ：現在市面上生成編碼軟體越來越多，您如何看待 AI 程式設計工具的生産力提升和安全風險？

Brian Behlendorf：軟體開發工具是安全體系中的重要組成部分。一旦開發工具就存在安全漏洞，那漏洞肯定會滲透進它所建立的代碼中。好消息是，目前大多數軟體開發工具都是開源項目，比如說 eclipse 和 emacs，還包括 GitHub 中内置的很多功能，都是基于開源代碼。這是因為開發人員需要知曉這些工具内部到底是怎樣運作的。雖然不是人人在乎，但總有百分之一或者千分之一的開發者想搞清楚底層代碼的原理。

我認為一定要讓 AI 世界遠離像 ChatGPT 這樣單一的集中式專有模型。在我看來，ChatGPT 就類似于 AI 界的微軟 Windows。它屬于典型的集中加專有型産品。它專屬于一家公司，雖然他們願意開放 API 供其他人使用，但其本質仍然是個專有平台。而真正的開源模型應該允許任何人參與，你可以構模組化型，我也可以構模組化型，每個人都能加入進來并做出修改。那将是一個與如今 ChatGPT 的形态完全不同的新世界，也是我們應該為之奮鬥的未來。隻有這樣，大語言模型生成的代碼才能具備更高的安全性。

InfoQ：那您覺得像 ChatGPT 這樣的大模型，在安全方面究竟是利大于弊還是弊大于利？

Brian Behlendorf：我覺得還是利大于弊，就是說它們生成的代碼仍然比人類更安全，前提是雙方投入的時間相同。大語言模型就像是加速器，如果非要從反面來看，那 10 倍開發者制造安全漏洞的速度也是 10 倍呢。是以我們不僅要投資大語言模型，也要投資建設更好的掃描工具，這一點非常重要。

應該努力利用工具幫助發現其中的各種安全缺陷，我們 OpenSSF 也在通過 Alpha-Omega 項目努力達成這個目标。該項目的核心，就是找出廣泛存在于大量開源項目中的簡單 bug。我們要如何掃描數以萬計的現有項目，并找到其中的 bug？這是一項體量巨大的工程，找出的 bug 往往影響成百上千個項目。是以我們要做的就是先想辦法做掃描，再開發出自動修複程式，最後把修複成果以 PR 的形式送出上去。這方面研究工作目前由 Jonathan Bryce 負責，我們聘請他加入進來并推動項目發展。

我們覺得這是個下限問題，即應該努力提高常用開源項目的品質下限。作為其中的關鍵部分，此舉将有助于捕捉大語言模型可能在代碼中引入的常見 bug。當然，編寫測試、使用模糊測試工具等工作還是要由開發人員親自負責，這樣才能真正貫徹提升軟體品質和安全性的最佳實踐。

我認為開發永遠是人與工具的結合。這有點像賽車運動，現在很多比賽已經從手動變速箱更新成了自動變速箱，對吧？但用哪種變速箱并不是重點，重點在于怎樣比其他對手跑得更快。開發也是，要不要使用 AI 生成的代碼并不是重點，重點在于如何更好地建構安全代碼并幫助其他人安全使用開發成果。

InfoQ：從這個角度看，AI 确實比人類效率更高。但我們也知道，某些程式設計助手的底層模型是用開源代碼訓練而成。如果資料本身不安全，那大模型肯定會受到影響吧？

Brian Behlendorf：我覺得這個要具體問題具體分析，至少要搞清楚他們到底在用哪些開源代碼做訓練。因為如果他們使用的是排名前 1000，或者說前 10000 的項目代碼，那麼這類訓練集的代碼品質其實是很高的。畢竟 GitHub 上有上億個 repo，Gitee 也不遑多讓。其中很多是教學用的項目或者一次性項目，還有其他項目的特定分支，這裡确實有很多非常垃圾、品質極差。

我希望構模組化型的團隊能認真考量訓練集中的内容。在 OpenSSF，我們開發出一款名叫 Security Scorecard 的工具。在對 GitHub repo 使用後，它會打出 0 到 9 分的相應得分，借此說明目标代碼的可信度如何、存在 bug 的可能性有多大。如果隻得到 1 分，則代表目标代碼可能因管理不善而存在尚未發現的 bug，或者是未經過模糊測試。總之它能提供各種各樣的啟發和輔助。

是以隻要以此為基礎建構起訓練集，就能挑選出在 Scorecard 上得分較高的項目代碼，比如要求其至少要得到 7 分。正如我之前所說，了解訓練集中的内容跟了解源代碼中的内容同等重要。

安全應該考慮在模型建構之前，而不是之後

InfoQ：就是說在建構大模型之前，我們應該選擇正确的資料庫以保障安全。對嗎？

Brian Behlendorf：沒錯，而且我覺得這會是個持續的過程。也許大家投入到模型完善上的精力，會超過軟體開發本身。

InfoQ：那就目前來看，AIGC 是不是已經成為軟體供應鍊的組成部分？

Brian Behlendorf：目前還沒有多少開源項目把 AI 代碼直接納入進來，但我覺得每位面向最終使用者的開發者都會使用網絡浏覽器、文本編輯器和 WordPress/Dribble 之類的工具。

而這些工具，正是大語言模型介入開發流程的載體，或者說通往 OpenAI API 的門戶。希望未來會有更多内置模型的出現，但目前我覺得 AIGC 還不能說已經成為軟體供應鍊的一部分。不過我認為這些工具正變得越來越重要，跟 SBOM，也就是軟體物料清單差不多。或者是我之前提到的 Scorecard，還有 OpenSSF 用于為供應鍊目标配置設定簽名的 Sigstore，以及反映安全水準的 SLSA 規範等。

我覺得這些技術都能被輕松納入訓練集，以及由這些訓練集編譯成的模型。它們适用于源代碼和文檔，自然也适用于大語言模型。

InfoQ：各行各業都飽受供應鍊投毒攻擊的侵擾，而且近年來供應鍊投毒事件也愈發多見。随着 AIGC 的流行和廣泛應用，您覺得會不會有模型資料集投毒的風險，甚至在模型建構過程中投毒？

Brian Behlendorf：我覺得絕對有可能，畢竟模型會邊組裝邊沿着供應鍊向下遊移動，之後可能有惡意分子突然介入并替換或篡改其中的訓練集，導緻模型偏離既定的學習路線。

是以我要再次強調，必須要用保護供應鍊内源代碼和其他建構工件的相同工件保護 AI 模型，因為它們在完整性上有着同等重要的意義。

InfoQ：那要如何避免針對 AIGC 模型的投毒行為？

Brian Behlendorf：可以用 Sigstore 這類方案。它會為每個對象配置設定簽名，并在不同對象結合起來時再配置設定新的簽名。它能覆寫到供應鍊中的所有對象，這種形式跟鑽石供應鍊非常相似。比如我們到店裡挑選鑽石，當然希望心儀的寶鑽不是出自被非法奴役的勞作者之手。但問題是要如何驗證？答案就是使用上遊開發者的加密簽名。這種機制能夠證明代碼來自上遊開發者，且到達目前環節前沒有經過篡改。Sigstore 想要起到的就是這樣的作用，而且效果不錯。Sigstore 目前已經在雲原生生态系統中得到了廣泛應用。

是以當軟體在供應鍊中往來流動時，我們可以依靠 Sigstore 防止中間人攻擊。它還可以在 SBOM 等環節上發揮作用。是以投毒确實是個大問題，但我覺得把 AI 模型當作供應鍊内的其他對象做統一管理即可。

AIGC 對開源軟體意味着什麼？

InfoQ：那在您看來，未來的開源社群乃至整個軟體供應鍊是否會受益于 AIGC 的蓬勃發展？

Brian Behlendorf：我覺得肯定能用 AI 幫助開發者建構更好的掃描工具，檢測出更多安全漏洞。之後，我們可以把 AI 引入開發工具當中，比如在人們送出 PR 時自動掃描其中的安全問題。目前供應鍊中的組織正變得極為複雜，比如企業往往會在世界各地設有多處資料中心，掌握着大量外部和内部應用程式并設定有不同的安全級别，這一切都要借助 AI 的力量。AI 明顯特别擅長處理海量資料、将資料内容可視化、提取見解并快速找到異常。是以是的，我相信 AIGC 的發展肯定會給軟體世界帶來助益。

反正我非常樂觀。目前已經有人在應用機器學習來掃描漏洞，雖然難度很高而且尚處于早期發展階段，但我仍看好這方面探索。

InfoQ：但這些畢竟還是早期技術，企業肯定不願意冒險把它們廣泛用于生産環境，對吧？

Brian Behlendorf：确實，但掃描工具其實不涉及生産中的關鍵路徑，影響範圍隻局限于供應鍊之内，對吧？是以我覺得多做點實驗也未嘗不可，而且大家可以把它作為一種對現有掃描工具的啟發性探索。總之，AI 工具就是實作掃描的一種辦法，不要把它想得有多特殊。

InfoQ：有媒體報道，說 Gartner 以及一些其他咨詢企業覺得應該推遲采用 ChatGPT 進行代碼生成、代碼安全掃描和代碼審查。您覺得這種觀點有沒有道理？

Brian Behlendorf：我覺得他們主要是擔心在使用這些工具時，目前能夠仰仗的主要是集中式服務。假定大家在一家大企業工作，并要求 ChatGPT 生成一款能夠完成 a、b 和 c 任務的軟體，那這些具體要求就會成為 OpenAI 伺服器内部的專有資訊。這顯然與大部分資訊管理原則有所沖突。但如果這些工具能夠保持去中心化，就是說不單純由 OpenAI 和 ChatGPT 來實作，而是一切都在本地、在我們面前實作，情況當然就不一樣了。

那樣這些安全問題，這些隐私或資料管理問題将不複存在。是以我們才更需要着力推動開源大語言模型的快速發展，而不能坐視整個世界圍着 ChatGPT 打轉，對不對？

如何安全地使用 ChatGPT？

InfoQ：是以這是否意味着，現有安全檢測工具是不是跟不上 AIGC 的發展？

Brian Behlendorf：我覺得倒是不至于。至少我還沒聽到有人說 AI 生成的代碼因為品質低下而引發失控。确實，如果你是計算機科學專業的大一學生，而且打算全靠 ChatGPT 幫你完成作業，那它生成的代碼确實慘不忍睹、搞得你挂了科，但這純屬自作自受。身為開發人員，大家必須保證 AI 生成的結果真正與需求和目标相比對，要能夠真正解決問題。你想借它之手搞定一切，這肯定不行，但我相信未來這些工具會表現得越來越好。

是以從長遠角度來看，我仍然保持樂觀。但在短期之内，大家使用時千萬要謹慎。

InfoQ：那我們該如何以安全方式使用 ChatGPT？您有什麼建議嗎？

Brian Behlendorf：我一直強調測試驅動開發的重要意義。就是說要先定義測試，然後再編寫出能通過這些測試的代碼。在我看來，大家應該先從人的角度入手編寫測試，再讓 ChatGPT 輸出代碼，依靠測試來確定 AI 生成的代碼符合需求。

當然，大家也可以要求 ChatGPT 代為編寫測試，對吧？但不管怎麼操作，閱讀代碼、了解代碼邏輯和保證代碼發揮正确作用的責任永遠都在我們自己肩上。

在安全對抗當中，“守方”永遠是被動的一方，而惡意人士往往總會搶先一步。考慮到這樣的現實，AIGC 也許會給開源社群帶來巨大威脅。

InfoQ：OpenSSF 在這方面打算如何應對？

Brian Behlendorf：我們正計劃組建新的工作組，專注于 AI/機器學習方向。其中一半成員考慮如何使用工具來更好地保障供應鍊安全，而另一半成員則更多關注使用環節的安全問題。目前我們尚處于起步階段，未來應該會逐漸提出建議和方法，甚至在領域當中傳遞一些工具或規範。

是以要做斷言還為時過早。而且我個人認為，守方不一定就是被動的一方。安全保護工作也可以主動出擊。比如定期檢查漏洞，在開源項目中每年或者每兩年組織一次安全審計。花點錢讓專業人士梳理現有代碼，查找安全漏洞。還有，可以針對自己的基礎設施組織紅隊演練。身為 CIO，大家應該主動嘗試滲透己方基礎設施。是的，安全保護完全可以出去起來，不一定要陷入被動。我覺得這種心态本身就該扭轉，這樣我們才能時刻做好準備，無論 AI 最終會不會像人們想象得那樣得到廣泛普及。

本文轉載來源：

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