開源軟件供應鏈當前面臨的主要是兩大風險：一是安全風險，一是許可證、版權、專利和出口管制等方面的法律合規(guī)風險。當然針對使用開源軟件的企業(yè)來說，還有供應鏈風險及運維風險。這些風險如何更好地規(guī)避？開源協(xié)議、開源組織都做了哪些事情？企業(yè)如何自查內(nèi)部開源項目的安全性？本期《極客有約》，我們邀請到了 Zilliz 合伙人，首席布道師顧鈞，上海安勢信息技術有限公司資深解決方案架構師朱賢曼共同解答上述問題。

(原文視頻：https://www.infoq.cn/article/6jm3rPVwybGMbJl358Fx)

InfoQ：開源軟件供應鏈到底應該如何理解？

顧鈞：我覺得開源軟件供應鏈和傳統(tǒng)制造業(yè)類似，只是開源軟件供應鏈會有很多新的挑戰(zhàn)。傳統(tǒng)制造業(yè)供應鏈的供應商承擔的責任相對清晰，因為合作方之間會在成熟的法律條框下簽訂商業(yè)合同。但是，用戶在使用開源軟件時可能沒有特別意識到已經(jīng)對其形成依賴，該項目已經(jīng)成為上游。傳統(tǒng)意義上，可以將該開源項目理解為是供應商，但其又不承擔供應商的職責。這個新的挑戰(zhàn)就是，上下游之間沒有強制的商務合作，沒有法律條框可以限制使用過程，想要確保安全會有很多不確定的地方。

朱賢曼：開源軟件供應鏈面臨的最大挑戰(zhàn)就是企業(yè)自己都不知道用了哪些開源軟件，大一點的公司可能開始關注到開源合規(guī)治理的內(nèi)容，但是很多小公司可能還沒有這個意識。

InfoQ：國內(nèi)當前在軟件供應鏈安全方面的意識形態(tài)大概是什么樣的？

顧鈞：站在使用者的角度，Zilliz 開發(fā)服務的新一代向量數(shù)據(jù)庫 Milvus ，希望提供給最終用戶云服務，所以我們既是一個開源軟件的供應商，但同時我們 Milvus 也引用了大量第三方開源組件，是供應鏈上的消費者。項目初期引用上游其他開源組件的時候，我們會有一些比較簡單的規(guī)則，比如說考慮許可證的兼容性問題，加入到 Linux 基金會時也會有一些開源項目合規(guī)性檢查，回溯其中引入的開源項目許可證的合規(guī)性。

站在用戶的角度，明顯分為兩類：一類是動手能力較強的互聯(lián)網(wǎng)類型的技術公司或者創(chuàng)業(yè)公司，可能沒有那么嚴格的要求，不強制開源項目的開發(fā)團隊提供一個質(zhì)量保證的書面化內(nèi)容，也不會嘗試商務合同；另一類社區(qū)當中的用戶，比如金融機構等，非常關心這個問題，尤其是想要投入到生產(chǎn)上的時候。我覺得國內(nèi)目前有嚴格內(nèi)部規(guī)范的企業(yè)，對開源軟件供應鏈還是比較在意的，希望引入的開源軟件有服務商提供質(zhì)量保證。

朱賢曼：國內(nèi)企業(yè)做這件事的動力來源大部分都是外部壓力，比如歐盟的運營商會在合同里面要求提供開源軟件清單，寫清楚項目中使用了哪些開源軟件，且保證后續(xù)不會造成法律風險。國內(nèi)的部分廠商是因為下游客戶的要求，在合同里面簽訂相關條款，保證代碼合規(guī)性，整個供應鏈環(huán)環(huán)相扣，這些是外部的壓力。

此外，國家層面也在慢慢重視開源合規(guī)，國內(nèi)有很多安全相關的法律法規(guī)，尤其是金融行業(yè)。

InfoQ：如果企業(yè)的業(yè)務在規(guī)劃或正在做出海，會著重考慮這一塊嗎？

顧鈞：現(xiàn)在的廠商一般偏向于提供 SaaS 型云服務，像我們這樣的創(chuàng)業(yè)團隊是從基礎軟件開始做云服務，早期是在做基礎軟件，后來慢慢做云服務，再去做合規(guī)。海外則有很多上來就做 SaaS 相關云服務的公司，最重要的事情就是先把合規(guī)全部完成，這是很不一樣的地方。

朱賢曼：開源軟件在出口管制層面的合規(guī)性要求，在美國是有法條規(guī)定的，如果不特別注意，可能會無意識當中觸犯美國的出口管制條款。在中美貿(mào)易合規(guī)大背景下，企業(yè)可能就得額外關注這種合規(guī)性。所以，開源軟件治理的驅(qū)動力是合規(guī)和安全，以及環(huán)境影響，比如國內(nèi)之前發(fā)生的 GPL 訴訟，這會讓很多公司逐漸關注開源合規(guī)并識別風險。

顧鈞：GPL 開源協(xié)議和法律條款容易引人誤會的地方是傳統(tǒng)上，大家覺得要白紙黑字簽署過才有法律約束，但開源協(xié)議是使用時默認代表接受整個協(xié)議，如果不接受就不能使用。

InfoQ：隨著國內(nèi)使用開源的人越來越多，大家對開源協(xié)議的理解程度大概是什么樣子的？

顧鈞：開源協(xié)議的數(shù)量還是挺多的，GitHub 上也有一些專門的許可證選擇器，幫助用戶選擇適合自己的許可證，基本上大家都會集中選擇幾大主流協(xié)議。

首先是 Apache 2.0，因為國內(nèi)很多項目都加入了 Apache 軟件基金會，很多新項目也是希望遵循這種方式進行治理，很多都默認選擇了 Apache 2.0 許可證，所以對該許可證的解讀會比較充分。

其次是 MIT 許可，因為 MIT 許可相對寬松，所以很多個人項目或者程序庫型的項目，直接就選擇了該許可。因為大家都比較容易理解。當然這之中可能會潛藏一些專利問題。整體上 MIT 因為最簡單，大家都能理解，用的人也比較多。

最后是 GPL，名聲大，受到的攻擊就比較多，很多人的錯誤解讀，造成了 GPL 的評價特別兩極分化。GPL 協(xié)議的開源項目近期國內(nèi)不是特別多，大家一般不會選擇 GPL，但是會有一些項目選擇 AGPL。

朱賢曼：近幾年，國內(nèi)對許可證的理解程度要好很多，中大型企業(yè)都會關注，很多公司已經(jīng)成立了專門的開源治理辦公室，但實際業(yè)務當中會發(fā)現(xiàn)仍有很多問題需要解決。根據(jù)我目前的了解，國內(nèi)對 GPL 還是能不用盡量不用，畢竟需要承擔更多的合規(guī)業(yè)務。對商業(yè)應用比較友好的是 Apache，寬松、不需要開放源代碼、條款也相對嚴謹，如果商業(yè)公司使用，法務風險相對較低。AGPL、SSPL 這種一般很多公司直接禁用。一般的分發(fā)概念，需要實際發(fā)布代碼，以前的分發(fā)是寄光盤，現(xiàn)在可能是把源代碼包上傳到應用商店，但 AGPL 的分發(fā)可能通過遠程訪問云服務就算，這個范圍就大了，所以很多公司不會選擇這兩種協(xié)議。如果公司內(nèi)部有類似開源辦公室這種角色，制訂規(guī)則的時候一般會將這兩者禁用。企業(yè)在對外發(fā)布開源項目時，如果希望商業(yè)化之后保留一個商業(yè)版本、一個社區(qū)版本，可能會選擇類似 GPL 的許可，一方面可以收集到用戶意見，也就是開源的反饋意見，用于改進商業(yè)版，同時也不希望被直接白嫖。

InfoQ：國內(nèi)在供應鏈管理方面有沒有比較好的軟件工具可以推薦的？

朱賢曼：供應鏈是一個系統(tǒng)工程，肯定不是單一工具可以解決的，需要一整套的工具。因為這個鏈條很長，很多都需要 DevOps 這一套工具鏈。但如果想知道開源治理部分的潛在風險，最基本的是要知道到底使用了哪些開源軟件，由于現(xiàn)在軟件使用的開源軟件數(shù)量眾多，調(diào)用關系錯綜復雜，且層層依賴，靠人工去梳理基本不太現(xiàn)實，所以一般稍大點的公司都會引入專業(yè)的 SCA 工具，用于梳理企業(yè)的產(chǎn)品中使用了哪些開源軟件，這些開源軟件存在怎樣的安全風險和許可證風險。

InfoQ：發(fā)生漏洞事件之后，可以做哪些事情盡量降低不好的影響？

顧鈞：從開發(fā)人員的角度講，如果發(fā)現(xiàn)了一個漏洞，首先要找到可行的繞過方法，在用戶不需要進行系統(tǒng)更新、不需要改動任何代碼的情況下將問題危害降到最低，找到方法后盡快公布，通知用戶漏洞詳情，如果沒有也需要告知用戶漏洞信息，畢竟對用戶來講是非常危險的，哪怕連夜完成修復，比較嚴謹?shù)拇笮凸疽埠茈y將新的修復版本上線生產(chǎn)環(huán)境。因為這類公司有自己的流程且不易打破，連夜趕出來的修復版本也沒有經(jīng)過完善的測試，對企業(yè)來講是不可取的。

朱賢曼：如果是開源軟件出現(xiàn)漏洞，我們一般建議升級版本，成本相對來說偏低，當然企業(yè)內(nèi)部一般會有完備的應急預案，肯定不是隨便發(fā)版升級的。

InfoQ：如果一個開源項目總是頻繁發(fā)布漏洞修復信息，是應該使用還是盡量少用？

顧鈞：我覺得這個問題挺有趣的。首先肯定要看開源軟件本身的代碼質(zhì)量以及 Issue 里的反饋，對開源項目本身有一個整體評判。如果覺得軟件不行就不要使用，如果用戶反饋比較積極，經(jīng)常更新漏洞信息說明真的有很多人在用，經(jīng)常有用戶給出反饋，說明項目質(zhì)量在穩(wěn)步提高。此外，也要注意頻繁升級帶來的成本。

朱賢曼：我在做行管時，如果軟件頻繁出現(xiàn)安全漏洞升級信息，不建議使用。當然也分情況，開源軟件同類型的項目很多，要多方面綜合考慮，但是一般不建議選擇頻繁出現(xiàn)漏洞，或者漏洞版本很多的開源軟件，建議選擇基金會支持或者商業(yè)公司主導的項目，當然這種項目也曾出現(xiàn)過較大漏洞，但相對來說可能會有保障一些。

InfoQ：開源項目有什么樣的措施保證安全性？

顧鈞：代碼托管在 GitHub 上，平臺就有專門的工具掃描依賴，如果有比較嚴重的安全性問題會提示是否升級到新的版本。軟件升級本身是一個復雜的過程，有時升級太快會引入一些新的問題，如果只是一些簡單修復，對其他的影響不大，我覺得是需要積極升級的。當然有時候，這種修復也可能會引入新的問題。企業(yè)在生產(chǎn)當中要具體問題具體分析。

InfoQ：開源項目背后的商業(yè)公司在整個過程中起到什么樣的作用，或者說會引入一些什么樣的風險嗎？

顧鈞：早期來看，很多開源軟件都是社區(qū)驅(qū)動的，要保證項目長期發(fā)展，光靠社區(qū)志愿是很難的，沒辦法要求太高。只有商務合同或者有現(xiàn)實利益分配時，才能確保需要的項目按時交付，個人業(yè)余時間做的項目出現(xiàn)在依賴上，無法提出太多要求。如果開源項目成立自己的商業(yè)公司，用戶可以與其簽訂法律合同，提出 SLA 或問題修復時效相關的承諾，這些開源軟件背后的公司扮演了一個讓供應鏈更牢固的角色。

朱賢曼：我非常認可顧老師的觀點，站在企業(yè)的角度，選擇開源軟件，我會建議考量這些因素。如果自己沒有支持能力，建議選擇有商業(yè)背景的公司，可以購買公司提供的服務。有時免費的才是最貴的，有人幫助對整個項目兜底，至少能夠解決很多問題，這是值得做的方式。

InfoQ：請兩位分享開源軟件供應鏈可能面臨的風險或者問題？

顧鈞：我覺得從早期許可證的角度來講，很容易出現(xiàn)類似 MIT、BSD 這種過于寬松的協(xié)議，因為其不帶專利所有權。代碼雖然是開源的，但不代表不能就這些代碼申請專利。開發(fā)者可以在代碼開源之前，先遞交專利申請。如果開源項目的協(xié)議是 Apache 2.0，提交代碼時已經(jīng)默認授權用戶在項目范圍內(nèi)使用專利，這也是相對安全的。類似 MIT 或者 BSD 這些可能就沒有這個顯式過程，會有另外的方式去彌補，比如通過 CLA 的方式將專利授權給項目用戶使用，這是從許可證兼容性和專利層面的考量。

另一個顯著問題是需要將企業(yè)內(nèi)部流程或者習慣做法更加規(guī)范化。因為之前開源的 JavaScript 生態(tài)當中的一些開源項目，作者直接往 npm 站點上傳所謂的“有毒”代碼，正常情況不應該在生產(chǎn)環(huán)境中直接下載 mpn 包做升級，肯定有測試環(huán)境，驗證升級沒問題再搬到生產(chǎn)環(huán)境，用戶需要有這樣的流程。

朱賢曼：一般來說，開源軟件的風險可能來自四個方面：一是安全風險，其中又分為開源軟件本身的安全漏洞導致的風險和目前關注度很高的軟件供應鏈攻擊的風險，個人建議不信任所有從外面下載的組件；二是法律風險，其中又分為許可證本身的協(xié)議，如果未履行開源合規(guī)義務，可能會造成侵權而遭到索賠、訴訟、產(chǎn)品下架、商譽受損等風險。另外一個是專利方面的風險，一種是本身的創(chuàng)建者/貢獻者實現(xiàn)的專利，有可能預埋專利陷阱，另一種是第三方專利維權風險。此外，還有商標侵權及出口管制方面的風險；三是供應鏈斷供風險，比如俄烏事件后，可能 GitHub 直接就不允許俄羅斯開發(fā)人員下載代碼了，甚至把俄羅斯賬號的代碼提交刪掉了。還有上次 faker.js 刪庫事件，導致后續(xù)版本和代碼更新都沒有了；四是運維風險，如果企業(yè)自己沒有能力支撐，沒有商業(yè)公司幫忙的話，維護成本很大。

InfoQ：請兩位老師簡單分享開源軟件供應鏈常見的攻擊類型。

顧鈞：首先是專利，比如潛水艇專利，預留專利埋坑，這類是很不容易防范的，因為專利審核對一般公司來講需要一些代價。其次是惡意代碼，現(xiàn)在主流的開源軟件分發(fā)方式就是 npm、GitHub，從公開站點獲得開源軟件后一定要做驗證，這能夠幫助大家減少很多麻煩。

朱賢曼：一種是惡意代碼，前段時間也有新聞提到可以在 GitHub 上把惡意代碼裝上去且不留下任何記錄，這是很恐怖的，我們還是比較信任 GitHub 上面下載下來的內(nèi)容，因為我們認為這是官方網(wǎng)站。另外一種最近提的比較多依賴混淆攻擊，npm 包管理器的設計存在一些問題，比如用戶創(chuàng)建了一個私人組件，其版本是一個范圍，如果同名組件更新源碼，但其中存放了惡意代碼，也會自動拉取過來，同名組件的代碼就跑到用戶環(huán)境中了，企業(yè)內(nèi)部在引入組件時則需要做更多校驗，我們建議企業(yè)建立自己的開源軟件庫，在組件進來之前有個準入機制，做測試驗證，保證所使用的組件都是受信任的。當然這個成本是相對較高的，但確實很有必要。

InfoQ：關于斷供問題怎么解決？

顧鈞：開源本身不限制地域，但是承載開源這件事情的通常是一個商業(yè)實體，商業(yè)實體會受到所在地區(qū)的出口管制法，或者其他制裁條例的限制。很多時候，我們現(xiàn)在用到的開源軟件，包括自己的開源軟件都托管在 GitHub 上，GitHub 是美國的公司，必然會受到美國的出口管制法的限制。從這個角度來講，企業(yè)內(nèi)部可以建內(nèi)部代碼庫，所依賴的東西可以將其放在內(nèi)部代碼庫上，萬一有一天訪問不了 GitHub，總有個備份的源碼池可以獲得這些代碼。從國家角度來講，對此一直在做準備。目前來講，我覺得大家都有各自的解決方法，似乎影響沒有那么大。

朱賢曼：我個人覺得，相比許可證合規(guī)和安全風險來說，斷供風險只是開源眾多風險之一，相對來說還是影響比較小的，開源治理更多的是許可證的法律法務的合規(guī)和安全性。

講師介紹：

顧鈞，Zilliz 合伙人、首席布道師，LF AI&Data 基金會 TAC 成員，開放原子基金會開源導師。北大畢業(yè) 16 年以來專注于數(shù)據(jù)庫、大數(shù)據(jù)技術，尤其對 OLTP 平臺與場景有著豐富的經(jīng)驗，先后任職于工商銀行、IBM、摩根士丹利、華為等企業(yè)。運營的視頻號 ID 為「JUN 不斷向前」，不定期更新開源領域的熱門趨勢及重要內(nèi)容解析。

朱賢曼，上海安勢信息技術有限公司資深解決方案架構師，十余年軟件開發(fā)經(jīng)驗，先后從事出口管制合規(guī)、合規(guī)相關系統(tǒng)設計和實施、開源軟件合規(guī)等工作