云計算開源產業聯盟：開源產業白皮書（2019年）(37頁).pdf

1、 版權聲明版權聲明 本白皮書版權屬于中國信息通信研究院，并受法律保護。 轉載、摘編或利用其它方式使用本白皮書文字或者觀點的， 應注明“來源：中國信息通信研究院”。違反上述聲明者，本 院將追究其相關法律責任。 前前 言言 當前開源技術快速發展，在云計算、大數據、人工智能等領域逐 漸形成技術主流，開源技術已經成為企業構建信息系統的重要選擇， 國內企業參與開源生態的熱情度持續提升。 開源一方面可以突破技術 壁壘，推動技術創新，另一方面也面臨知識產權、安全、技術運維等 一系列與開源相關的風險問題。抓住開源技術的快速發展機遇，有必 要進一步健全開源生態、樹立開源風險意識、加強開源治理，推動我 國開源產業

2、健康快速發展。 開源產業白皮書 首先通過調查問卷的形式梳理了開源軟件市 場總體規模及應用現狀，然后從知識產權及合規、安全、技術運維三 個角度分別對開源軟件的風險進行調查分析， 進一步總結開源產業發 展特點及趨勢，最后結合當前現狀給出了我國開源產業發展建議。 本白皮書采用電話訪談和在線調查相結合的方式， 共回收有效問 卷 4,135 份，同時利用代碼掃描工具對軟件的組件、許可證、漏洞等 情況進行統計。 在數據采集、 代碼掃描及編寫過程中得到了 FOSSID 等 掃描工具和中國 IDC 圈的支持。 目目 錄錄 一、全球開源軟件市場規模及應用現狀 . 1 （一）開源產業鏈條逐漸形成 . 1 （二）全

3、球開源軟件市場現狀 . 2 （三）我國開源技術市場應用現狀 . 3 1、企業對開源技術的接受程度逐年增高 . 3 2、開源解決方案是企業的重要關注點 . 4 3、聯合開發成為企業部署開源的主要選擇 . 6 4、企業應用開源技術仍面臨眾多挑戰 . 6 （四）我國云計算相關開源技術應用現狀 . 7 1、容器技術應用持續深化 . 7 2、虛擬化技術走向成熟期 . 10 3、微服務應用逐步落地 . 12 4、DevOps 進入實踐階段 . 14 二、開源軟件風險調查分析 . 15 （一）知識產權及合規風險 . 16 1、風險分析 . 16 2、調查結果 . 17 （二）安全風險 . 22 1、風險分析

4、 . 22 2、調查結果 . 23 三、我國開源產業發展特點及趨勢 . 28 四、我國開源產業發展建議 . 29 附錄：開源軟件風險調查掃描軟件清單 . 30 1 一、全球開源軟件市場規模及應用現狀 （一）（一）開源產業鏈條逐漸形成開源產業鏈條逐漸形成 開源即開放一類技術或一種產品的源代碼，源數據，源資產，可 以是各行業的技術或產品，其范疇涵蓋文化、產業、法律、技術等多 個社會維度。如果開放的是軟件代碼，一般被稱作開源軟件。開源經 過形成時期、古典時代、移動時代到云開源時代的不斷發展，開源產 業鏈條已經逐漸形成，其中涉及的企業類型包括：自發開源企業、開 源產品企業和開源用戶企業。 圖 1 開源

5、產業鏈條構成 自發開源企業指對開源社區做出貢獻的企業，如將企業內已有代 碼形成項目，公開發布于代碼托管平臺或捐贈給開源基金會，其代碼 能夠被公開獲取。 著名的開源項目如 Android、 Linux、 TensorFlow 等， 背后多為谷歌、微軟等科技公司。近年來國內華為、騰訊、阿里等企 業均積極主動發起開源項目，主要集中在云計算、大數據、存儲、運 維等領域，在國際上的影響力逐漸提升。 開源產品企業指基于社區版開源軟件提供發行版售賣給開源用 戶企業， 或針對主流社區版開源軟件提供服務 （包括： 軟件選型咨詢、 軟件運維服務支持等）的企業。 開源用戶企業指從開源社區獲取開源軟件或代碼， 用于自

6、身信息 系統構建以輔助實現企業前臺業務功能的機構，包括諸多傳統行業， 自發開源企業開源社區開源產品企業開源用戶企業 2 如金融、電力、通信、能源等。據 Gartner 調查顯示，99%的組織在 其 IT 系統中使用了開源軟件，隨著開源技術快速形成生態，企業用 戶引入開源技術已成大勢所趨。 （二二）全球全球開源軟件市場開源軟件市場現狀現狀1 全球開源熱度持續攀升。截至 2018 年，全球最大的代碼托管平 臺 GitHub 已有 3000 萬開發人員，其中 2018 年的新用戶數量超過了 前六年用戶數之和；囊括 200 萬家企業或組織，2018 年的組織數目 比去年增加了 40%；擁有 9600

7、萬個代碼庫，超過三分之一的代碼庫 是在 18 年創建的；已提交 2 億的 pull request，僅在過去一年就創 造了超過 6000 萬次。 中國貢獻者在開源社區中持續活躍。截至 2018 年，全球最大的 代碼托管平臺 GitHub 上超過 80%的用戶來自美國以外的地區，其中 中國的貢獻者數目僅次于美國，排名第二；2018 年 GitHub 上的貢獻 者數量是2017年的1.6倍， 其中中國的新注冊用戶數目僅次于美國， 排名第二。 熱門領域開源項目涌現， 公司成為開源的重要貢獻者。 2018 年， JavaScript（前端和后端）、機器學習、移動應用程序開發和容器是 貢獻最多的領域。其

8、中，微軟 VS Code、Facebook React、谷歌 TensorFlow位列項目活躍度前三甲 （按貢獻者數目排序） 。 整體來看， 微軟、谷歌、紅帽、英特爾等頂級科技公司的員工是開源項目的重要 貢獻者。 1 數據來源： 3 （三三）我國我國開源技術市場應用現狀開源技術市場應用現狀 1、企業對開源技術的接受程度逐年增高 超過八成的企業認可開源技術。調查顯示，已經應用了開源技術 的企業占比達到 86.7%，有計劃應用開源技術的企業占比 10.6%，開 源技術已經被企業普遍接受。 圖 2 2018 年開源技術使用率調查（N=4135） 數據來源:中國信息通信研究院 技術成熟程度和功能豐富度

9、是企業選擇開源技術時考慮的重要因 素。 據調查， 企業對技術成熟度的關注最高， 達到 68.7%； 其次， 46.3% 的企業在選擇開源技術時會考慮功能豐富程度。此外，還有 43.3%的 企業因縮短應用部署時間而選擇開源技術。 圖 3 企業選擇開源技術的考慮因素（N=4023） 數據來源:中國信息通信研究院 86.7% 10.6% 2.7% 已經應用 有計劃應用 暫時沒有計劃應用 68.7% 46.3% 43.3% 41.9% 30.7% 27.3% 24.8% 23.2% 6.4% 技術成熟程度 功能豐富程度 縮短應用部署時間 節約成本 生態完善程度 自主性、可控性及可持續性 降低試錯風險

10、人才培養 其他 4 缺少適合的解決方案和出于安全性考慮是企業尚未應用開源技術 的兩個原因。在尚未應用開源技術的企業中，認為缺少適合的解決方 案的企業占比最高，達到 43.4%，與去年相比提高了 11.2%；其次， 有35.2%的企業出于安全性考慮尚未使用開源技術。 其他因素還包括： 現有技術不夠成熟（30.3%）、開源技術帶來的優勢不明顯（16.4%） 以及無法滿足合規要求（9.8%）。 圖 4 企業尚未應用開源技術的原因（N=550） 數據來源:中國信息通信研究院 2、開源解決方案是企業的重要關注點 規劃設計和產品選型是最受企業關注的解決方案類型。據調查， 企業對于規劃設計類解決方案的需求最

11、為強烈，占比達到了 68.6%， 相比 2017 年上升了 1.1 個百分點；其次，57.6%的企業更關注產品選 型，比去年提高了 3.4%。其他開源解決方案還包括實施路徑、運維管 理和人才培養等。 43.4% 35.2% 30.3% 16.4% 9.8% 2.5% 32.2% 37.4% 33.0% 13.9% 19.1% 3.5% 缺少適合的解決方案 出于安全性考慮 現有技術不夠成熟 開源技術帶來的優勢不明顯 無法滿足合規要求 其他 20182017 5 圖 5 企業對開源解決方案的選擇（N=4023） 數據來源:中國信息通信研究院 開源解決方案的功能性及易用性和服務安全性是企業的首要關注

12、 點。在企業對開源解決方案關注指標的調查中，有 48.7%的企業更注 重功能性及易用性，占比最高；其次，分別有 38.7%和 34.3%的企業 更關注服務安全性和異構化系統的集成能力。 其他受關注的指標還包 括： 技術支持能力 （28.2%） 、 行業適用性 （26.1%） 以及可用性 （16.4%） 等。 圖 6 企業對開源解決方案的關注指標（N=4023） 數據來源:中國信息通信研究院 存儲是企業開源技術的首要應用方向。調查顯示，將開源技術應 68.6% 57.6% 53.4% 42.3% 34.2% 67.5% 54.2% 59.7% 36.1% 39.5% 規劃設計 產品選型 實施路徑

13、 運維管理 人才培養 20182017 2.7% 10.2% 14.6% 16.4% 26.1% 28.2% 34.3% 38.7% 48.7% 其他 資源調度效率 互操作性 可用性 行業適用性 技術支持能力 異構化系統的集成能力 服務安全性 功能性及易用性 6 用于存儲領域的企業占比最高，達到 56.7%；其次是大數據分析 （54.8%）。其他應用方向還包括：數據庫、網絡和中間件。 圖 7 企業開源技術應用方向（N=4023） 數據來源:中國信息通信研究院 3、聯合開發成為企業部署開源的主要選擇 近七成的企業選擇聯合服務商共同實施開源技術。在企業云計算 開源技術實施方式的調查中， 選擇聯合服

14、務商共同實施開源技術的企 業比例最高，達到 67.3%；其次，21.1%的企業選擇完全依靠企業內部 科技力量自研，這與 2017 年相比提高了 0.9 個百分點。 圖 8 企業開源技術實施方式（N=4023） 數據來源:中國信息通信研究院 4、企業應用開源技術仍面臨眾多挑戰 歷史遺留問題多、異構資源池管理平臺難統一、安全監管以及合 56.7% 54.8% 48.6% 42.4% 28.7% 1.3% 存儲 大數據分析 數據庫 網絡 中間件 其他 7 規要求較高是企業應用開源技術面臨的重要挑戰。 歷史遺留問題多是 企業應用開源技術面臨的最大困難，占比達到 63.7%；其次 59.8%的 企業認為

15、異構資源池管理平臺難以統一。 此外， 分別有 42.6%和 30.8% 的企業表示安全監管以及合規要求較高、 物理設備種類多是其應用開 源技術面臨的挑戰。 圖 9 企業應用開源技術面臨的挑戰（N=4135） 數據來源:中國信息通信研究院 （四四）我國我國云計算相關開源技術應用現狀云計算相關開源技術應用現狀 1、容器技術應用持續深化 超過七成的企業已經使用容器技術或正在測試應用環境。 據調查， 36.4%的企業已經使用了容器技術， 相比 2017 年提高了 6.3%； 其次， 正在測試容器技術應用環境的企業占比達到 34.2%，比去年減少了 2.1 個百分點。此外，還有 21.1%的企業正在評估

16、容器技術。 5.4% 12.7% 30.8% 42.6% 59.8% 63.7% 其他 人才儲備不足 物理設備種類多 安全監管及合規要求較高 異構資源池管理平臺難統一 歷史遺留問題多導致原有應用遷移困難 8 圖 10 云計算容器技術使用階段 (N=918) 數據來源:中國信息通信研究院 支持快速彈性擴容和移植性強是企業選擇容器技術的優先考慮 因素。調查顯示，出于支持快速彈性擴容和能夠實現快速部署/移植 性強考慮而應用容器技術的企業占比分別達到 62.3%和 61.8%； 其次， 有 44.9%的企業認為容器技術有助于微服務框架的實現， 相比 2017 年 提高了 8.7%。另外，可用性高（38

17、.4%）以及管理便利（33.6%）也是 企業應用容器技術的主要推動力。 圖 11 企業應用云計算容器技術的原因 (N=648) 數據來源:中國信息通信研究院 缺少成功案例是企業應用容器技術面臨的最大挑戰。調查顯示， 36.4% 30.1% 34.2% 36.3% 21.1% 24.5% 8.3% 9.1% 2018 2017 已經投入生產環境正在測試環境正在評估尚未使用容器技術 62.3% 61.8% 44.9% 38.4% 33.6% 28.7% 17.6% 55.6% 62.9% 36.2% 26.7% 31.0% 34.0% 23.7% 支持快速彈性擴容 能夠實現快速部署/移植性強 有助

18、于微服務架構的實現 可用性高 管理便利 有助于降低成本 無開發商鎖定 20182017 9 出于缺少成功案例的原因而未使用容器技術的企業占比為 47.1%；其 次， 遷移成本高和對容器技術不太了解也是企業未使用容器技術的重 要因素，占比分別為 31.2%和 30.6%。根據訪談，企業對成功案例和 遷移成本的關注程度有所上升。 圖 12 企業尚未應用云計算容器技術的原因 (N=584) 數據來源:中國信息通信研究院 運維自動化和彈性擴容是容器技術應用最多的兩個場景。在企業 容器技術應用場景的調查中，64.9%的企業選擇將容器技術用于運維 自動化，相比 2017 年上升了 7.0%；其次，應用容器

19、技術實現彈性擴 容的企業占比達到 50.6%。此外，企業還將容器技術應用在多環境一 致性管理和開發測試快速交付等場景中。 圖 13 企業云計算容器技術應用場景 (N=648) 數據來源:中國信息通信研究院 47.1% 31.2% 30.6% 24.8% 20.4% 5.1% 41.4% 21.7% 43.7% 33.8% 25.1% 3.4% 缺少成功案例 遷移成本高 對容器技術不太了解 安全性不夠 沒有直接業務價值 其他 20182017 64.9% 50.6% 37.2% 35.7% 27.9% 25.4% 57.9% 53.5% 31.2% 34.0% 29.4% 22.7% 運維自動化

20、 彈性擴容 多環境一致性管理 開發測試快速交付 CI/CD 微服務 20182017 10 近六成的企業選擇 Docker 作為容器運行技術。調查顯示，在已經 應用容器技術的企業中， 選擇 Docker 的企業占比最高， 達到 58.6%； 在眾多技術中，RKT 與去年相比增幅最大（4.3%）。其他容器技術還 包括：LXD、Solaris Zones 和 LXC 等。 圖 14 企業云對計算容器運行技術的選擇 (N=648) 數據來源:中國信息通信研究院 2、虛擬化技術走向成熟期 超過半數的企業選擇購買商業版 OpenStack，并采用供應商的技 術服務支持。在 OpenStack 解決方案選

21、擇的調查中，54.9%的企業選 擇購買商業版的 OpenStack 并采用供應商的技術服務支持， 相比 2017 年上升了 6.7%。 此外， 還有 33.1%的企業選擇定制化開發 OpenStack， 并自己負責技術支持。 圖 15 云計算 OpenStack 解決方案選擇 (N=603) 數據來源:中國信息通信研究院 58.6% 59.4% 12.6% 8.3% 7.9% 6.5% 6.7% 4.0% 10.4% 16.7% 2.4% 3.7% 1.4% 1.3% 2018 2017 DockerRKTLXDSolaris ZonesLXCBSD Jails 其他 11 Kilo 和 Ic

22、ehouse 是企業應用較為廣泛的兩個 OpenStack 版本。 調 查顯示， 最受企業歡迎的版本是 Kilo， 占比達到 23.7%； 選擇 Icehouse 版本的企業達到 17.8%；其次，分別有 14.6%和 12.9%的企業使用了 Liberty和Newton版本。 其他受關注的OpenStack版本還包括Ocata、 Mitaka 和 Queens 等。 圖圖 16 2018 年云計算年云計算 OpenStack 版本選擇版本選擇 (N=603) 數據來源:中國信息通信研究院 在眾多組件中，Keystone 最受企業歡迎。使用 Keystone 組件的企 業占比最高，達到 48.

23、4%；其次，分別有 40.3%和 34.8%的企業應用了 Swift 和 Glance 組件。 其他 OpenStack 組件還包括： Cinder （29.6%） 、 Ironic（27.8%）、Ceilometer（24.2%）和 Heat（14.3%）等。 23.7% 17.8% 14.6% 12.9% 10.8% 7.7% 5.2% 4.1% 3.2% Kilo Icehouse Liberty Newton Ocata Mitaka Queens Rocky 其他 12 圖 17 企業應用的云計算 OpenStack 組件 (N=603) 數據來源:中國信息通信研究院 3、微服務應用

24、逐步落地 超過六成的企業已經應用或正在測試微服務框架。在對企業微服 務框架使用情況的調查中發現， 22.8%的企業已經應用了微服務框架； 其次，正在測試環境的企業占比達到了 31.6%；此外，還有 28.4%的 企業正在評估微服務框架。 圖 18 云計算微服務框架使用接受程度 (N=918) 數據來源:中國信息通信研究院 超過六成的企業選擇 Spring Cloud 作為其微服務框架。據調查， 48.4% 40.3% 34.8% 29.6% 27.8% 24.2% 14.3% 5.3% Keystone Swift Glance Cinder lronic Ceilometer Heat 其他

25、 22.8% 31.6% 28.4% 17.2% 已經投入生產環境 正在測試環境 正在評估 暫不使用或不了解 13 選擇 Spring Cloud 作為微服務框架的企業比例最高，達到 61.2%； 其次， 有 33.7%的企業認為 Service Comb 更適合作為其微服務框架。 其他受關注的微服務框架還包括：Dubbo（26.6%）、Service Mesh （12.9%）和 Tars（8.6%）。 圖 19 企業對云計算微服務框架的選擇 (N=499) 數據來源:中國信息通信研究院 缺乏運維人員和改造成本較高是企業未使用微服務框架的兩個重 要原因。調查發現，因缺乏運維人員而未使用微服務框

26、架的企業占比 達到 39.3%；其次，有 33.5%的企業認為改造成本較高是其未使用微 服務框架的主要原因。此外，分別有 31.8%和 26.9%的企業未使用微 服務框架的原因是業務暫時不需要和技術人員缺乏了解。 圖 20 企業尚未應用云計算微服務框架的原因 (N=709) 數據來源:中國信息通信研究院 61.2% 33.7% 26.6% 12.9% 8.6% 2.8% Spring Cloud ServiceComb Dubbo Service Mesh Tars 其他 39.3% 33.5% 31.8% 26.9% 3.3% 缺乏運維人員 改造成本較高 業務暫時不需要 技術人員不是很了解

27、其他 14 4、DevOps 進入實踐階段 超過 1/3 的企業已經實現了系統的自動化運維。對 DevOps 應用階 段的調查顯示，33.6%的企業表示已經投入生產環境，與 2017 年相比 提高了 5.8%；其次，36.3%的企業表示正在測試環境。此外，尚未考 慮使用 DevOps 的企業僅有 7.7%。 圖 21 企業云計算 DevOps 實現情況（N=918） 數據來源:中國信息通信研究院 Jenkins 是目前企業使用最廣泛的開源集成工具。調查發現，在諸 多開源集成工具中，Jenkins 的使用比例最高，達到 39.3%；其次， 分別有31.2%和20.7%的企業表示已經應用了Team

28、City和GitLab CI。 此外，使用 Go CD 的企業占比為 8.8%。 圖 22 企業云計算開源集成工具使用情況（N=642） 數據來源:中國信息通信研究院 33.6% 27.8% 36.3% 35.8% 22.4% 26.1% 7.7% 10.3% 2018 2017 已經投入生產環境正在測試環境正在評估不使用或不了解DevOps 39.3% 31.2% 20.7% 8.8% Jenkins TeamCity GitLab CI Go CD 15 超過四成的企業將 Ansible 作為自動化運維工具。調查發現， Ansible 是企業使用率最高（42.2%）的自動化運維工具；此外，

29、還有 29.6%的企業選擇了 Saltstack。其他受關注的自動化運維工具還包 括： Puppet（20.4%）和 Chef（9.7%）。 圖 23 企業云計算開源自動化運維工具使用情況（N=642） 數據來源:中國信息通信研究院 二、開源軟件風險調查分析 相比于閉源軟件，開源軟件的代碼公開、獲取便捷，但企業和個 人在使用開源軟件的過程中仍需注意遵循相關規則， 包括開源許可證 的要求、開源基金會的規范、甚至相關國家法律條例等。由于開源軟 件的所有權和使用權分離，導致用戶往往成為開源的風險落腳點，因 此用戶在引入和使用開源軟件的過程中應充分重視潛在風險問題。 總體來看，開源軟件可能涉及三類風險

30、：知識產權及合規風險、 安全風險、運維和技術風險，其中，知識產權及合規風險主要與開源 許可證的規定相關，安全風險主要涉及安全漏洞等問題，運維和技術 風險主要指因開源軟件的引入導致的開發運維投入量大、 技術人員要 42.2% 29.6% 20.4% 9.7% Ansible Saltstack Puppet Chef 16 求高等問題。針對前兩項風險，本白皮書通過代碼掃描的方式，對若 干熱門開源軟件的實際風險情況進行了調查和統計。 （一）（一）知識產權及合規風險知識產權及合規風險 1、風險分析 除法律法規的保護外， 開源軟件的作者或權利人主要是通過開源 許可證對其知識產權進行許可與約束。 若開源

31、軟件使用者未依照相應 的開源許可證來使用開源軟件， 將可能侵犯開源軟件的作者或權利人 的知識產權。 目前經過 Open Source Initiative（以下稱“OSI”）認證的開 源許可證共有 83 種。根據其傳染型強弱大致可以分為四類： 表 1 常見開源許可證分類 許可證類型 許可證名稱 版本 開放型許可證 (Permissive License) MIT license / BSD 2-Clause 2-Clause BSD 3-Clause 3-Clause Apache License 2.0 弱傳染型許可證 (Weak Copyleft License) GNU LGPL 2.1

32、 GNU LGPL 3.0 Mozilla Public License (MPL) 2.0 Eclipse Public License (EPL) 1.0 傳染型許可證 (Copyleft License) GNU GPL 2.0 GNU GPL 3.0 17 強傳染型許可證 (Strong Copyleft License) GNU AGPL 3.0 個人或企業在使用開源軟件時，因開源許可證的規定或變動，可 能面臨知識產權及合規風險， 一是可能因許可證的傳染性規定被迫開 源，如：根據 GPL 許可證的規定，使用依 GPL 開源的軟件并涉及到修 改和分發，需要將后續修改代碼全部開源；二是商

33、業軟件是否遵守開 源約定未知，如：部分商業軟件基于開源進行二次開發后以閉源形式 提供給用戶，卻不遵守開源許可證的署名要求；三是知識產權風險易 被忽略，如：BSD、MIT 和 GPL 2.0 等并未明確包含明確的專利許可 條款，許可用戶使用軟件所包含的相關專利；四是開源許可證之間可 能不兼容，如：GPL 開源許可證在 GNU 的網站上詳細列出何種開源許 可證是否與其兼容2；五是開源軟件的使用規則存在不確定性，如： 2018 年以來多個開源軟件開發商（Redis 、MongoDB、Kafka 等）已 經對其過去使用的開源許可證進行了修改，Oracle 宣布 2019 年 1 月以后發布的 Orac

34、le Java SE 8 公開更新將不向沒有商用許可證 的業務、商用或生產用途提供。 2、調查結果 本白皮書利用工具對軟件源代碼進行掃描，設置規則為：若被掃 描軟件中有超過 5 個文件與開源組件庫中的組件匹配， 即認定可能包 含該開源組件。然而，受開源組件庫完整度和更新頻率限制，且算法 匹配過程中可能存在誤差，本白皮書調查結果僅供參考。 2 https:/www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses 18 熱門開源容器運行技術存在隱含風險，RKT 和 LXC 均發現少量使 用傳染性許可證的開源組件。 本白皮書

35、對企業選擇最多的三個開源容 器運行技術（Docker、RKT 和 LXC）進行掃描，結果顯示：Docker 暫 未發現使用傳染性許可證的開源組件，RKT 和 LXC 中發現少量使用 傳染性許可證的開源組件。其中，RKT 包含 1 個使用 GPL 許可證的 開源組件，LXC 包含 1 個使用 GPL 許可證的開源組件和 1 個使用 LGPL 許可證的開源組件。 圖 24 熱門開源容器技術許可證情況調查 軟件名稱 許可證類型 組件名稱（帶有傳染性的許可證名稱） Docker Apache-2.0 / RKT Apache-2.0 go(GPL-2.0) LXC LGPL-2.1 jdk(GPL-2

36、.0) lxc(LGPL-2.1) 數據來源:中國信息通信研究院 熱門開源容器編排技術中，Kubernetes 發現少量使用傳染性許可 證的開源組件。本白皮書對企業選擇最多的三個開源容器編排技術 （Kubernetes、 Mesos 和 Swarm） 進行掃描， 結果顯示： Mesos 和 Swarm 0 2 4 6 8 10 12 14 16 DockerRKTLXC 開源組件數量 GPLLGPLApacheBSDMIT 19 暫未發現使用傳染性許可證的開源組件，Kubernetes 中發現 3 個使用 GPL 許可證的開源組件。 圖 25 熱門開源容器編排技術許可證情況調查 軟件名稱 許可

37、證類型 組件名稱（帶有傳染性的許可證名稱） Kubernetes Apache-2.0 heketi(GPL-3.0) duplicatecheck(GPL-3.0) goproxy(GPL-2.0) 數據來源:中國信息通信研究院 OpenStack 的 7 大常用組件未發現傳染性許可證。本白皮書對 7 個 OpenStack 常用組件進行掃描，結果顯示：以上組件主要應用的許 可證是 Apache 2.0，其中 Swift、Ironic、Cinder 等開源組件也包含其 他的許可證，如：MIT 和 ECL-2.0。 0 5 10 15 20 25 30 35 40 45 KubernetesM

38、esosSwarm 開源組件數量 GPLLGPLApacheBSDMIT 20 圖 26 OpenStack 常用組件許可證情況調查 數據來源:中國信息通信研究院 熱門開源微服務框架中，Spring Cloud 發現使用傳染性許可證的 開源組件。本白皮書對企業選擇最多的三個開源微服務框架技術 （Dubbo、 Service Comb 和 Spring Cloud） 進行掃描， 結果顯示： Dubbo 和 Service Comb 中暫未發現使用傳染性許可證的開源組件，其主要 許可證是 Apache 2.0。Spring Cloud 的眾多組件中發現 1 個使用 GLP 許可證和 1 個使用 L

39、GLP 許可證的開源組件。 圖 27 熱門開源微服務框架許可證情況調查 0 2 4 6 8 10 12 開源組件數量 Apache其他 0 5 10 15 20 25 30 35 Spring CloudService CombDubbo 開源組件數量 GPLLGPLApacheBSDMIT 21 軟件名稱 許可證類型 組件名稱 （帶有傳染性的許可證名稱） Spring Cloud Apache-2.0 git(GPL-2.0+) postgresql-mingw-w64(LGPL-3.0) Service Comb Apache-2.0 / Dubbo Apache-2.0 / 數據來源:中

40、國信息通信研究院 DevOps 領域熱門開源軟件所含組件的許可證情況較為復雜，隱 含風險需引起關注。本白皮書對企業選擇較多的四個 DevOps 領域開 源軟件 （Ansible、 Jenkins、 Go CD、 Chef） 進行掃描， 結果顯示： Jenkins 和 Go CD 中暫未發現使用傳染性許可證的開源組件，Ansible 發現 1 個使用 GLP 的開源組件，Go CD 發現 3 個使用 GLP 的開源組件和 1 個使用 LGPL 的開源組件。 圖 28 DevOps 領域熱門開源軟件許可證情況調查 軟件名稱 許可證類型 組件名稱 （帶有傳染性的許可證名稱） Ansible GPL-

41、3.0 ansible(GPL-3.0) Jenkins MIT / Go CD Apache-2.0 codexmapping(GPL-2.0) tesnuke(GPL-2.0) git(GPL-2.0+) kafs(LGPL-3.0) Chef Apache-2.0 / 數據來源:中國信息通信研究院 0 1 2 3 4 5 6 AnsibleJenkinsGo CDChef 開源組件數量 AGPLGPLLGPLApacheBSDMIT 22 總體來看，開源軟件許可證問題較為復雜，企業在引入包含帶有 傳染性許可證的開源組件時， 應特別注意相關傳染性組件的源代碼后 續是否可能在二次開發中被修改

42、，如可能涉及修改，應注意修改后的 軟件是否可能涉及對外分發（如：對外公開銷售軟件等）。以 GPL 許 可證為例，使用依 GPL 開源的軟件并涉及到修改和分發時，用戶需要 將后續修改代碼開源，如未遵循開源許可證的要求，可能會構成違約 給企業帶來風險。 （二）（二）安全風險安全風險 1、風險分析 由于開源軟件具有多人協作完成、 開源許可證存在免責條款等特 性，企業在使用開源軟件時必須注意數據安全及隱私風險，若開源軟 件存有惡意代碼、病毒或造成隱私泄露，將給使用者帶來較為嚴重的 危害。 總體來看，開源軟件存在的安全問題較為嚴重，安全漏洞是主要 的問題， 后門等問題同樣存在。 開源軟件的安全缺陷密度較

43、高， 據SNYK 發布的2019 年開源安全現狀調查報告顯示， 過去兩年內應用程序 的漏洞數量增長了 88，僅 2018 年 NPM 的漏洞數量增長了 47。 系統信息泄露、 密碼管理、 資源注入、 跨站請求偽造、 跨站腳本、 HTTP 消息頭注入、SQL 注入、越界訪問、命令注入、內存泄漏是開源軟件 主要的安全風險。 本次調查對部分熱門開源軟件進行了代碼安全掃描， 所用漏洞庫與美國國家漏洞庫（NVD）保持同步。 23 2、調查結果 熱門開源容器運行技術中，LXC 存在漏洞問題，Docker 和 RKT 暫未發現漏洞。本白皮書對企業選擇最多的三個開源容器運行技術 （Docker、RKT 和 L

44、XC）進行安全漏洞掃描，結果顯示： LXC 中包 含 1 個嚴重風險漏洞，1 個中風險漏洞以及 3 個低風險漏洞。 圖 29 熱門開源容器技術安全漏洞情況調查 軟件名稱 嚴重風險 高風險 中風險 低風險 LXC CVE-2016-8649 / CVE-2015-1331 CVE-2017-5985 CVE-2015-1335 CVE-2015-1334 數據來源:中國信息通信研究院 熱門開源容器編排技術中，Swarm 漏洞問題突出，Kubernetes 和 Mesos 暫未發現漏洞。本白皮書對企業選擇最多的三個開源容器編排 技術 （Kubernetes、 Mesos 和 Swarm） 進行安全

45、漏洞掃描， 結果顯示： Swarm 中包含 1 個嚴重風險漏洞，1 個高風險漏洞以及 1 個中風險漏 0123 LXC RKT Docker 安全漏洞數量 低風險中風險高風險嚴重風險 24 洞。 圖 30 熱門開源容器編排技術安全漏洞情況調查 軟件名稱 嚴重風險 高風險 中風險 低風險 Swarm CVE-2018- 1002105 CVE-2019-9946 CVE-2019- 1002100 / 數據來源:中國信息通信研究院 OpenStack 的 7 大常用組件中只有 Keystone 發現漏洞問題。 本白 皮書對 7 個 OpenStack 常用組件進行掃描，結果顯示：Keystone 包含 2 個高風險漏洞， 5 個中風險漏洞。 其他幾個常用組件暫未發現漏洞。 圖 31 OpenStack 常用組件安全漏洞情況調查 0123 Swarm Mesos Kubern