關注企業開源供應鏈：開源有風險，使用需謹慎！

2021-06-17 11:27:43

所謂的軟體供應鏈，就是一個企業在生產環境中，包括研發、運營、銷售等環節所依賴的計算機軟體。如今，大部分企業所使用的基礎軟體都是基於開源軟體實現，有研究表明目前企業所使用的軟體中，開源軟體佔比已高達 90%，可見開源軟體在今天的重要地位。

然而，開源軟體不同於有供應商提供一站式服務的商用軟體。很多企業使用的開源軟體通常來源於開源社群或各大程式碼託管平臺，如何保證這些軟體的安全性與合規性，就成為了每個使用開源軟體的企業必須思考的問題。

開放原子基金會 TOC 副主席譚中意是一位擁有 20 年開源經驗的軟體工程師，同時也是國際開源合規項目 OpenChain 中國工作組聯合創始人。本文將整理譚中意老師在 GOTC 全球開源技術峰會「開源運營與治理」直播專場的演講內容，為大家介紹企業開源軟體供應鏈常見的風險和挑戰，以及國際開源供應鏈標準 OpenChain 項目如何幫助企業解決和避免這些問題。

開源軟體供應鏈的風險與挑戰

開源軟體在企業軟體開發中的地位無需贅言，但很多企業的開發團隊在使用開源軟體時，往往會忽略一些潛在的風險。

這裡有一個真實的案例。美國晶片巨頭 Broadcom 曾在某款 802.11 晶片中使用了 Linux 系統，隨後該晶片被通訊裝置公司 Linksys 收購，並整合在了自家的 WRT54G 無線路由器中，再後來 Linksys 公司在 2003 年被業界巨頭思科收購。理論上，由於 WRT54G 使用的晶片採用了GPL 協議的 Linux 系統，那麼包括晶片源碼、集成了晶片的產品源碼都要遵循 GPL 協議開源出去。然而出於商業利益考慮，思科並沒有這麼做。隨後，思科就被自由軟體基金會 FSF 投訴，起初雙方互不讓步，經過數年交涉，思科被迫開放了一百多款路由器的原始碼，並向基金會捐款數千萬美元才把事件平息。這件事對開源社群來說無疑是一件好事，但對於思科公司來說確實造成了一系列損失。

在來看看另一個案例。知名前端開發框架 React 最初是 Facebook 公司在內部開發 Instagram 時構建的項目，是一個用來構建使用者介面的優秀 JS 庫，於 2013 年 5 月開源。React 最初是在 BSD 協議下開源，在世界範圍內吸引了大量的企業使用者。然而在 2016 年 7 月，Facebook 毫無預兆地在 React 的開源協議中附加了一項專利條款（patent grant），該條款規定如果你使用了 React，你不能做構成與 Facebook （包括其子公司及其合作方）競爭的事情，一旦你做了，就會面臨法律訴訟。此條款一出立即引發了軒然大波，導致國內外眾多企業使用者不得不放棄 React 改用其他的替代軟體。這個案例告訴我們，開源項目來源一方也存在協議變更等事件帶來的法律風險。

除了法律合規性方面的風險以外，開源軟體供應鏈中也存在程式碼安全性的風險，後者給企業帶來的損失往往更加直接和巨大。

2017 年 9 月，美國三大信用評估機構之一的 Equifax 公司被曝出遭黑客入侵，導致約 1.43 億使用者的個人隱私資料洩漏。事後的調查顯示，Equifax 內部使用了開源的 MVC 框架 Apache Struts 項目，黑客利用該項目 2.3 版本中的一個漏洞實現入侵。而事實上， Apache Struts 社群早在當年的三月就修復了該漏洞，但是 Equifax 在五月中旬出現了洩漏，直到七月底才被發現，Apache Struts 方面認為是 Equifax 內部沒有及時更新版本導致漏洞被黑客利用。這次事件導致 Equifax 公司直接經濟損失近 4 億美元。

此外，由於不像商業軟體一樣有完善的售後服務，在使用開源軟體的過程中遇到大大小小的 BUG 也是家常便飯。對於有能力的企業來說，可以專門安排開發人員參與開源工作，將 BUG 問題反饋到開源社群等候維護者解決，或是自己解決並將程式碼回饋到開源社群，這也是我們鼓勵的一種參與開源建設的良性方式。但對於很多中小型企業來說，面對這些 BUG 時往往會手足無措，損耗大量的時間和人力成本。

解決問題的思路

開源軟體供應鏈存在各種各樣的風險，針對這些風險建立標準化的合規流程迫在眉睫。

一個完整的開源供應鏈如下圖所示：

企業從上游開源社群（Upstream）引入一個開源項目，在公司內部通過一系列 DevOps 研發、定製、上線，最後對外以線上服務、軟體包、硬體捆綁等形式輸出。要使得整個供應鏈過程充分地高效、安全、合規，要面臨的挑戰很多。

首先是來自上游開源社群的開源軟體所包含的元件數量龐大。以國內最常用的程式語言 Java 和 JavaScript 相關技術棧為例。根據 Sonatype 釋出的《2020 年軟體供應鏈調查報告》中的資料，目前共有 5 百萬 Java 軟體包在 maven 中心倉，其中有 30 萬個開源項目，平均每個工程師每年下載 29,736 個軟體包；而在 node.js 相關的 npm 中心倉中，共有約 130 萬軟體包，2019 年新增 50 萬軟體包，平均每個工程師下載 93,457 個軟體包。在面對人均使用量如此龐大的開源軟體包時，為了保證供應鏈的合規性，需要確保團隊內部每一個工程師都對開源軟體相關協議、版權等問題有所瞭解。

經過多年的經驗，人們注意到每個公司要做到開源供應鏈合規，都有大量相似的工作。比如開源軟體的 License 雖然多，但是常見的也就那麼幾種，相關材料可以歸納總結之後複用；又比如公司使用開源軟體的政策，指定使用開源軟體的合規流程，讓工程師理解相關知識的培訓材料，建立供應商之間的信任鏈條等，這些都是大量重複性的工作。

什麼是 OpenChain

為了簡化這些重複性的工作，指定標準化、流程化的開源供應鏈，業內的一些頭部大廠開始進行合作，聯合 Linux 基金會共同創立了 OpenChain 項目。OpenChain 提出了一整套開源軟體供應鏈的規範，並制定為 ISO/IEC 5230 標準。2020 年 12 月 16 日，Linux 基金會、Joint Devlopment 和 OpenChain 項目宣佈 ISO/IEC 5230 已被核准為國際標準。

OpenChain 為企業開源軟體供應鏈提供了一個開源的法律框架，各個企業可以根據這個法律框架來定製自己需要的內容。其主要內容由三部分組成，分別是：

Spec：定義企業達到開源合規的一系列政策，流程和人員角色。
認證：根據 Spec 在政策/流程/人員/培訓等方面的要求，達標即通過認證。
培訓：提供了一系列培訓材料可以參考。

OpenChain Spec

Spec 重點描述企業的開源合規計劃應該「做什麼」以及「為什麼要做」，而不是「如何做」、「何時做」。具體內容包括：

企業需要有一份開源政策，而且需要讓員工都知曉
企業需要指定參與合規工作的人員，並確保他們具備能力
企業需要有流程來稽核許可證，確保符合權利和義務
企業需要有流程來為交付軟體創建軟體元件清單，包括許可證資訊等

OpenChain 認證

OpenChain 還包含合規認證，即針對規範制定了一系列問題，企業能夠滿足所有的這些問題，即符合要求。

例如針對軟體釋出的過程相關有如下幾個問題：

是否有明文規定的流程，用於識別、記錄和存檔軟體中的開源元件資訊
是否有明文規定的流程，保證隨軟體釋出按照許可證要求而提供合適的文件

例如針對公司員工對外開源進行貢獻相關有三個問題：

是否有對外開源貢獻的政策
是否有對外開源貢獻的流程
是否有流程讓工程師都瞭解對外開源貢獻的政策和流程

OpenChain 培訓材料

此外，OpenChain 還給參與企業提供了統一的培訓材料，包括針對工程師的開源合規培訓材料，針對 OSPO 的開源管理政策模版等。

除了是 Linux 基金會旗下的一個開源項目以外，OpenChain 同時也是一個社群，並按照 Linux 基金會開放治理的工作模式運轉。OpenChain 設有董事會，董事會成員包括微軟、谷歌、ARM、 CISCO、Toyota 和 Oppo 等廠商。合作伙伴包括各種法律諮詢公司、合規工具廠商等。

OpenChain 給出了一系列評估企業開源軟體供應鏈管理能力的標準，比如當一個常用開源軟體發現高危 CVE bug 和 fix 之後，多長時間內能在該企業內部定位和修復？當該企業對外輸出軟體的時候，能否快速輸出高質量的 SBOM（軟體元件清單）等。

理想的開源軟體供應鏈

業界普遍認為，理想的開源軟體供應鏈狀態應該在引入開源軟體與輸出開源軟體的兩個關鍵節點設立嚴格的規範。

當引入開源軟體的時候，應確保工程師：