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

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

InfoQ：開源軟件供應(yīng)鏈到底應(yīng)該如何理解？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

InfoQ：請兩位分享開源軟件供應(yīng)鏈可能面臨的風(fēng)險或者問題？

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

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

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

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

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

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

InfoQ：關(guān)于斷供問題怎么解決？

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

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

講師介紹：

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

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