奇安信：2022中國軟件供應鏈安全分析報告（45頁）.pdf

《奇安信：2022中國軟件供應鏈安全分析報告（45頁）.pdf》由會員分享，可在線閱讀，更多相關《奇安信：2022中國軟件供應鏈安全分析報告（45頁）.pdf（45頁珍藏版）》請在三個皮匠報告上搜索。

1、 1 2022 中國軟件供應鏈安全 分析報告 奇安信代碼安全實驗室 2022 年 6 月 I 目 錄 一、概述一、概述.11、軟件供應鏈安全攻擊事件保持持續高發.12、開源軟件安全風險是當前軟件供應鏈安全的焦點問題.3二、國內二、國內企業自主開發源代碼安全狀況企業自主開發源代碼安全狀況.51、編程語言分布情況.52、典型安全缺陷檢出情況.6三、開源軟件生態發展與安全狀況三、開源軟件生態發展與安全狀況.71、開源軟件生態發展狀況分析.72、開源軟件源代碼安全狀況分析.9（1）編程語言分布情況.9（2）典型安全缺陷檢出情況.103、開源軟件公開報告漏洞狀況分析.10（1）大型開源項目漏洞總數及年度

2、增長 TOP20.10（2）主流開源軟件包生態系統漏洞總數及年度增長 TOP20.124、開源軟件活躍度狀況分析.14（1）7 成開源軟件項目處于不活躍狀態.14II（2）近 2 萬個開源軟件一年內更新發布超過 100 個版本.155、關鍵基礎開源軟件分析.16（1）主流開源生態關鍵基礎開源軟件 TOP50.16（2）2/3 的關鍵基礎開源軟件從未公開披露過漏洞.19（3）關鍵基礎開源軟件的整體運維風險較高.20四、國內企業軟件開發中開源軟件應用狀況四、國內企業軟件開發中開源軟件應用狀況.201、開源軟件總體使用情況分析.21（1）平均每個軟件項目使用 127 個開源軟件.21（2）流行開源軟

3、件被超過 1/3 的軟件項目使用.212、開源軟件漏洞風險分析.22（1）77%的軟件項目存在容易利用的開源軟件漏洞.22（2）平均每個軟件項目存在 69 個已知開源軟件漏洞.23（3）影響最廣的開源軟件漏洞存在于超 3 成的軟件項目中.23（4）16 年前的開源軟件漏洞仍然存在于多個軟件項目中.253、開源軟件許可協議風險分析.25（1）最流行的開源許可協議在超 3/4 的項目中使用.26（2）45.6%的項目使用了含有高風險許可協議的開源軟件.264、開源軟件運維風險分析.27（1）20 年前的老舊開源軟件版本仍在被使用.27III（2）開源軟件各版本使用更加混亂.28五、典型軟件供應鏈安

4、全風五、典型軟件供應鏈安全風險實例分析險實例分析.291、某主流網絡接入存儲(NAS)設備供應鏈攻擊實例分析.292、某主流 VPN 路由器供應鏈攻擊實例分析.313、三款國產操作系統供應鏈攻擊實例分析.334、某國產郵件系統供應鏈攻擊實例分析.355、Edge 瀏覽器供應鏈攻擊實例分析.36六、總結及建議六、總結及建議.38附錄：奇安信代碼安全實驗室簡介附錄：奇安信代碼安全實驗室簡介.401 一、概述一、概述 數字化時代，軟件的重要性和軟件供應鏈安全問題的嚴峻性已成為各方共識。為此，奇安信代碼安全實驗室去年發布了2021 中國軟件供應鏈安全分析報告（https:/ 漏洞”的攻擊效果。上述報告

5、內容的變化，感興趣的讀者在閱讀時可以重點關注。1 1、軟件供應鏈安全攻擊事件保持持續高發、軟件供應鏈安全攻擊事件保持持續高發 在過去的一年中，針對軟件供應鏈的安全攻擊事件依然呈現出高發態勢，造成的危害也非常嚴重。2 2021 年 8 月，臺灣芯片設計廠商 Realtek 稱，其 WiFi 模塊的三款開發包(SDK)中存在 4 個嚴重漏洞。攻擊者可利用這些漏洞攻陷目標設備并以最高權限執行任意代碼。這些 SDK 用于至少 65 家廠商制造的近 200 款物聯網設備中。2021 年 10 月，攻擊者劫持了 NPM 包 ua-parser-js 作者的賬戶約 4 小時，意圖安裝惡意軟件。ua-pars

6、er-js 每周下載量超過 700 萬次，廣泛應用于 Facebook、蘋果、亞馬遜、微軟、IBM 等硅谷巨頭企業中。2021 年 11 月，熱門 NPM 包 coa 和 rc 連續遭劫持，并被植入惡意代碼，影響全球 React 管道。coa 庫每周下載量約 900 萬，用于GitHub 上近 500 萬個開源庫中，rc 庫每周下載量達 1400 萬。2021 年 12 月，Apache Log4j2 曝出 Log4Shell 漏洞(CVE-2021-44228)，Apache Log4j2 是 Java 應用最廣泛的開源日志組件，廣泛應用于政府、企業和公共服務機構的平臺、應用和業務系統中，該

7、漏洞覆蓋范圍廣而且利用門檻低，對大量系統和機構造成了嚴重影響。2022 年 3 月，俄烏沖突中，NPM 開源包 Node-ipc 的作者RIAEvangelist 作為反戰人士，在代碼倉庫中進行了“供應鏈投毒”，添加的惡意 js 文件能夠在包使用者的桌面創建反戰標語。Node-ipc使用非常廣泛，每周下載量超過 100 萬次。2022 年 4 月，以色列安全公司發現高通和聯發科芯片的音頻解碼器存在三個漏洞（CVSS 評分為 9.8、7.8 和 5.5），來源于 11 年前蘋果公司開發的開源無損音頻編解碼器 Apple Lossless。利用這些3 漏洞進行攻擊，可獲取受影響移動設備媒體、音頻會

8、話的訪問權限及攝像頭數據流等，漏洞影響范圍包括數百萬安卓設備。2022 年 5 月，安全研究人員在 NPM 注冊表中發現了一些惡意軟件包，與大多數惡意軟件相比，其危險性更大，攻擊者可以通過后門完全控制被感染的機器。分析人員稱，這是一次依賴混淆攻擊，其目標非常明確，并且掌握了非常機密的內部信息。德國的著名媒體、物流和工業企業等機構受到攻擊。2 2、開源軟件安全風險是當前軟件、開源軟件安全風險是當前軟件供應鏈安全供應鏈安全的焦點問題的焦點問題 奇安信代碼安全實驗室通過數據對比分析發現，與前一年度相比，國內企業自主開發源代碼的安全狀況有較明顯的改善，千行代碼缺陷密度和十類典型安全缺陷的總體檢出率均有

9、明顯下降，這應該得益于軟件源代碼安全缺陷分析工具的持續應用,以及程序員編寫代碼時的安全意識提高。但開源軟件安全風險仍然居高不下，開源軟件的安全風險管控是當前軟件供應鏈安全保障需要解決的核心焦點問題。1 1）國內企業自主開發源代碼安全性明顯改善）國內企業自主開發源代碼安全性明顯改善2021 年，國內企業自主開發源代碼的整體缺陷密度和高危缺陷密度相比 2020 年均有所下降，其中高危缺陷密度下降較為明顯，從1.08 個/千行降為 0.65 個/千行；十類典型安全缺陷的總體檢出率從2020 年的 77.8%下降到 59.9%，下降了近 18%。2 2）開源生態保持蓬勃發展，開源軟件自身安全問題更加嚴

10、峻）開源生態保持蓬勃發展，開源軟件自身安全問題更加嚴峻2020 年底和 2021 年底，主流開源軟件包生態系統中開源項目總4 量分別為 3814194 個和 4395386 個，一年間增長了 15.2%，開源生態依然保持蓬勃發展的態勢。與此同時，開源軟件漏洞數量持續增長，2021 年新增的開源軟件漏洞達到 6346 個；不活躍的開源項目占比從去年報告的 61.6%提升至 69.9%。根據“奇安信開源項目檢測計劃”的實測數據顯示，所檢測開源軟件的總體缺陷密度和高危缺陷密度略高于去年，依然處于較高的水平；十類典型缺陷的總體檢出率為73.5%，遠高于去年的56.3%?？傮w來看，開源軟件自身的安全問題

11、日益嚴峻。3 3）國內企業軟件開發中，開源軟件安全風險問題未見改善）國內企業軟件開發中，開源軟件安全風險問題未見改善2021 年，奇安信代碼安全實驗室對 3354 個國內企業軟件項目中使用開源軟件的情況進行了分析，從數據分析情況來看，國內企業使用開源軟件時的安全風險問題沒有得到改善，開源軟件安全風險是當前企業軟件開發中亟待解決的首要問題。在 2021 年分析的 3354 個軟件項目中，平均每個項目使用 127 個開源軟件；存在已知開源軟件漏洞的項目占比 86.4%，平均每個項目存在 69 個已知開源軟件漏洞，十幾年前的古老開源軟件漏洞依然存在于多個項目中；20 年前的老舊開源軟件版本仍然在使用

12、，同一開源軟件各版本的使用更加混亂，被使用版本最多的開源軟件有 235 個版本在使用。整體的安全風險狀況與 2020 年相比沒有任何改善，風險水平仍處于較高狀態。與此同時，我們觀察到 2021 年很多機構和企業開始關注開源軟件供應鏈安全，但僅有少數的機構和企業應用了相關的開源安全治理工具。相信隨著開源安全治理工具的推廣和持續應用，國內企業軟件5 開發中的開源軟件安全風險問題會逐步得到改善。二、國內企業自主開發源代碼安全狀況二、國內企業自主開發源代碼安全狀況 源代碼安全是軟件供應鏈安全的基礎。2021 年全年，奇安信代碼安全實驗室對 2406 個國內企業自主開發的軟件項目源代碼進行了安全缺陷檢測

13、，檢測的代碼總量為 550808816 行，共發現安全缺陷5427125 個，其中高危缺陷 359055 個，整體缺陷密度為 9.85 個/千行，高危缺陷密度為 0.65 個/千行。與 2020 年相比，整體缺陷密度和高危缺陷密度均有下降，其中高危缺陷密度下降較為明顯，從 1.08個/千行下降至 0.65 個/千行。1 1、編程語言分布情況、編程語言分布情況 在 2406 個國內企業自主開發的軟件項目中，使用數量排名前 3的編程語言為 Java、C/C+、PHP，對應的軟件項目數量分別為 1441個、516 個和 102 個，其中 Java 語言項目占比達 60%。相關國內企業在進行軟件開發時

14、，Java 語言仍然是首選。編程語言的分布情況如下圖所示。6 2 2、典型安全缺陷檢出情況、典型安全缺陷檢出情況 輸入驗證、路徑遍歷、跨站腳本、注入、NULL 引用、資源管理、密碼管理、API 誤用、配置管理、日志偽造等十類典型安全缺陷的總體檢出率（檢出率指含有某類缺陷的軟件項目數占軟件項目總數的比例）為 59.9%，低于去年報告的 77.8%。每類典型缺陷的檢出率、排名及排名變化情況如下表所示。除API誤用類缺陷的檢出率從去年報告中的 28.7%升至 31.5%外，其他缺陷的檢出率均有不同程度的下降。排名 缺陷類型 檢出率 排名變化 1 輸入驗證 41.8%0 2 跨站腳本 35.1%1 3

15、 API 誤用 31.5%5 4 NULL 引用 30.2%1 5 資源管理 29.9%1 6 路徑遍歷 28.4%4 7 注入 26.3%3 7 8 密碼管理 22.8%1 9 配置管理 18.2%0 10 日志偽造 12.5%0 三、開源軟件生態發展與安全狀況三、開源軟件生態發展與安全狀況 開源軟件是現代軟件開發最基礎的原材料，其代碼自身的安全狀況，會直接影響最終軟件的安全性。本年度報告從開源軟件生態發展狀況、開源軟件源代碼安全狀況、開源軟件公開報告漏洞狀況、開源軟件活躍度狀況、關鍵基礎開源軟件分析等五個方面對 2021 年開源軟件生態發展與安全狀況進行綜合分析。相比于去年的報告，本章節新

16、增了“關鍵基礎開源軟件分析”部分，針對使用廣泛的關鍵性、基礎性開源軟件進行分析，希望能夠初步刻畫當前軟件世界的“底座”及其安全狀況。1 1、開源軟件生態發展狀況分析、開源軟件生態發展狀況分析 據奇安信代碼安全實驗室監測和統計，2020 年底和 2021 年底，主流開源軟件包生態系統中開源項目總量分別為 3814194 個和4395386 個，一年間增長了 15.2%；截至 2021 年底，主流開源軟件包生態系統中平均每個開源項目有 11.8 個版本，較去年報告的 10.2 個版本有所增加?？梢钥闯?，2021 年開源軟件生態依然繁榮。對 Maven、NPM、Packagist、Pypi、Godo

17、c、Nuget、Rubygems、Swift 等八個典型開源軟件包生態系統的具體分析如下：NPMNPM 包生態項目數量最多，包生態項目數量最多，GodoGodoc c 包生態增速最快。包生態增速最快。這一狀況與8 去年報告保持一致。八個典型的開源軟件包生態系統中開源項目數量和增長率情況如下圖所示，其中開源項目數量最多的是 NPM 包生態系統，截至 2021 年底，其開源項目數量達到了 1892984 個；開源項目數量增速最快的是 Godoc 包生態系統，2021 年一年間的項目總量增速達到了 39.9%。MavenMaven、NPMNPM、NugetNuget 三個包生態系統的開源項目開發者仍

18、然是“最三個包生態系統的開源項目開發者仍然是“最勤奮”，開源項目的平均版本數超過勤奮”，開源項目的平均版本數超過 1212 個。個。截至 2021 年底，八個典型的開源軟件包生態系統的開源項目數量和版本數量如下表所示。其中，Maven 包生態系統平均每個開源項目有高達 19.9 個版本，各包生態系統的開源項目平均版本數較去年均有不同程度的增長。序號 包生態系統 2021 年項目數 2021 年版本數 平均版本數 1 Maven 542743 10803609 19.9 2 NPM 1892984 23453934 12.4 3 Packagist 340541 3687777 10.8 4 P

19、ypi 352973 3209147 9.1 5 Godoc 328261 2758135 8.4 9 6 Nuget 375614 4773760 12.7 7 Rubygems 168436 1169942 6.9 8 Swift 82999 529584 6.4 2 2、開源軟件源代碼安全狀況分析、開源軟件源代碼安全狀況分析 2021 年全年,“奇安信開源項目檢測計劃”對 1780 個開源軟件項目的源代碼進行了安全檢測，代碼總量為 164414083 行，共發現安全缺陷 2648242 個，其中高危缺陷 162959 個。2021 年檢測的 1780 個開源軟件項目整體缺陷密度為 16.

20、11 個/千行，高危缺陷密度為 0.99個/千行，均略高于去年報告的 14.96 個/千行和 0.95 個/千行。（1 1）編程語言分布情況）編程語言分布情況檢測的 1780 個開源項目中，共涉及 7 種編程語言，分別是 Java、C/C+、Python、OC、Go、JavaScript、Kotlin，編程語言的分布情況如下圖所示。10（2 2）典型安全缺陷檢出）典型安全缺陷檢出情況情況2021 年檢測的 1780 個開源軟件項目中，輸入驗證、路徑遍歷、跨站腳本、注入、NULL 引用、資源管理、密碼管理、API 誤用、配置管理、日志偽造等十類典型安全缺陷的總體檢出率為 73.5%，遠高于去年報

21、告的 56.3%。每類典型缺陷的檢出率、排名及排名變化情況如下表所示。排名 缺陷類型 檢出率 排名變化 1 路徑遍歷 36.7%1 2 Null 引用 36.5%2 3 資源管理 33.0%3 4 輸入驗證 25.1%3 5 密碼管理 23.5%4 6 日志偽造 22.9%2 7 注入 21.4%4 8 API 誤用 18.2%3 9 跨站腳本 15.0%2 10 配置管理 10.8%0 3 3、開源軟件公開報告漏洞狀況分析、開源軟件公開報告漏洞狀況分析 據奇安信代碼安全實驗室監測與統計，截至 2021 年底，CVE/NVD、CNNVD、CNVD 等公開漏洞庫中共收錄開源軟件相關漏洞 5271

22、6 個，其中有 6346 個漏洞為 2021 年新增漏洞。（1 1）大型開源項目）大型開源項目漏洞漏洞總數及年度增長總數及年度增長 TOPTOP2020截至 2021 年底，歷史漏洞總數排名前 20 的大型開源項目信息如11 下表所示。歷史漏洞數排在前三的項目與 2020 年相同，是 Linux Kernel、Chromium(Google Chrome)和 Mozilla Firefox。序號 大型開源項目 主頁地址 歷史漏洞總數 1 Linux Kernel https:/www.kernel.org/4653 2 Chromium(Google Chrome)http:/www.chro

23、mium.org/2695 3 Mozilla Firefox https:/www.mozilla.org/en-US/firefox/2241 4 MySQL https:/ 5 Thunderbird https:/ 6 Adobe Flash Player plugin https:/ 1087 7 Firefox ESR https:/www.mozilla.org/en-US/firefox/enterprise/863 8 SeaMonkey https:/www.seamonkey-project.org/706 9 Drupal(core)https:/www.drupal.

24、org/699 10 PHP https:/ 11 ImageMagick https:/imagemagick.org/index.php 624 12 GitLab https:/ 13 Wireshark https:/www.wireshark.org/623 14 WebKitGTK http:/webkitgtk.org/591 15 WordPress https:/wordpress.org/575 16 OpenJDK https:/ 17 Moodle https:/moodle.org/442 18 Xen Project(Hypervisor)https:/xenpro

25、ject.org/411 19 FFmpeg https:/ffmpeg.org/392 20 QEMU https:/www.qemu.org/384 2021 年一年間，公開報告漏洞數量增長排名前 20 的大型開源項目信息如下表所示，Linux Kernel 一年來增加的漏洞最多，達到 419個。12 序號 大型開源項目 主頁地址 2021 年漏洞增量 1 Linux Kernel https:/www.kernel.org/419 2 Chromium(Google Chrome)http:/www.chromium.org/346 3 TensorFlow https:/www.ten

26、sorflow.org/201 4 MySQL https:/ 5 GitLab https:/ 6 Mozilla Firefox https:/www.mozilla.org/en-US/firefox/123 7 gpac https:/gpac.wp.imt.fr/116 8 Electron-Cross-platform desktop application shell https:/www.electronjs.org/83 9 Thunderbird https:/ 10 FFmpeg https:/ffmpeg.org/66 11 Firefox ESR https:/www

27、.mozilla.org/en-US/firefox/enterprise/62 12 WebKitGTK http:/webkitgtk.org/60 13 MediaWiki https:/www.mediawiki.org/wiki/MediaWiki 50 14 Oracle VM VirtualBox https:/www.virtualbox.org/49 15 QEMU https:/www.qemu.org/41 16 Magento https:/ 17 Nextcloud https:/ 18 Xen Project(Hypervisor)https:/xenproject

28、.org/34 19 libredwg https:/www.gnu.org/software/33 20 SWFTools http:/www.swftools.org/32（2 2）主流開源軟件）主流開源軟件包生態包生態系統系統漏洞漏洞總數及年度增長總數及年度增長 TOP20TOP20截至 2021 年底，主流開源軟件包生態系統中歷史漏洞總數排名13 前 20 的開源軟件信息如下表所示。序號 開源軟件 所屬包生態系統 歷史漏洞總數 1 Apache Tomcat Maven 183 2 FFmpeg-iOS Swift 177 3 TYPO3 CMS Packagist 130 4 Mag

29、ento Core Packagist 117 5 Ruby on Rails Rubygems 108 6 Plone Pypi 90 7 Puppet Rubygems 86 8 Django Pypi 86 9 Dolibarr ERP&CRM Packagist 80 10 Apache Struts Maven 80 11 Symfony Packagist 78 12 silverstripe-framework Packagist 78 13 keycloak Maven 72 14 Ansible Pypi、Conda 69 15 jackson-databind Maven

30、68 16 Data Mapper for Jackson Maven 58 17 jackson-mapper-asl maven 56 18 OpenShift Origin godoc 55 19 salt Pypi 46 20 Kubernetes godoc 46 2021 年一年間，主流開源軟件包生態系統中公開報告漏洞數量增長排名前 20 的開源軟件信息如下表所示。序號 開源軟件 所屬包生態系統 2021 年漏洞增量 1 FFmpeg-iOS Swift 67 2 Magento Core Packagist 23 3 Go programming language Godoc 2

31、0 14 4 Python Pillow Pypi 20 5 Vaadin Maven 19 6 Quarkus Maven 19 7 keycloak Maven 16 8 TYPO3 CMS Packagist 16 9 salt Pypi、Conda 14 10 jackson-databind Maven 13 11 OpenEXR Conan 13 12 Firefly III Packagist 12 13 dubbo Maven 12 14 Synapse homeserver for Matrix.org Pypi 12 15 Elasticsearch Maven 12 16

32、 Data Mapper for Jackson Maven 12 17 jackson-mapper-asl Maven 12 18 Apache Solr Maven 11 19 Plone Pypi 11 20 WebP Swift 11 4 4、開源軟件活躍度狀況分析、開源軟件活躍度狀況分析 活躍度也是衡量開源軟件安全性的一個重要維度。不活躍的開源軟件，一旦出現安全漏洞，難以得到及時的修復；活躍的開源軟件中，如果其版本更新發布的頻率過高，同樣會增加使用者運維的成本和安全風險。（1 1）7 7 成開源軟件項目處于不活躍狀態成開源軟件項目處于不活躍狀態我們將超過一年未更新發布過版本的開源軟

33、件項目定義為不活 15 躍項目。2021 年全年，主流開源軟件包生態系統中不活躍的開源軟件項目數量為 3071132 個，占比達到 69.9%，與去年報告的 61.6%相比，有所增加。對八個典型的開源軟件包生態系統進行分析和比較發現，各包生態系統中不活躍項目的占比較去年報告數據均有小幅升高，其中 NPM的不活躍項目數量最多，達 1318868 個，Rubygems 的不活躍項目比例最高，占比達到 89.6%。具體數據見下表。序號 包生態系統 項目總數 不活躍項目數 不活躍項目比例 1 Maven 542743 352390 64.9%2 NPM 1892984 1318868 69.7%3 P

34、ackagist 340541 240325 70.6%4 Pypi 352973 217348 61.6%5 Godoc 328261 222079 67.7%6 Nuget 375614 255619 68.1%7 Rubygems 168436 150912 89.6%8 Swift 82999 70621 85.1%（2 2）近）近 2 2 萬個萬個開源開源軟件一年內更新發布超過軟件一年內更新發布超過 1 10000 個版本個版本 2021 年全年，主流開源軟件包生態系統中，更新發布 100 個以上版本的開源項目有 19265 個，高于去年報告的 13411 個。八個典型的開源軟件包生

35、態系統中，一年內更新發布超過 100 個版本的項目數量見下表。排名 包生態系統 對應的開發語言 一年內發布超過 100 個版本的項目數量 1 NPM Javascript 9961 2 Maven Java 4161 16 3 Nuget.NET 1624 4 Godoc Go 1403 5 Pypi Python 1085 6 Packagist PHP 883 7 Rubygems Ruby 51 8 Swift Swift 16 5 5、關鍵基礎開源軟件分析、關鍵基礎開源軟件分析 現代軟件開發的“大廈”可以說構建在開源生態基礎之上。在開源生態中，有一些開源軟件的地位非常重要，它們被眾多其

36、他的開源軟件所依賴，被廣泛的使用在各種軟件系統之中，這些開源軟件可以說是現代軟件開發的核心基礎設施和底座，我們將其稱為“關鍵基礎開源軟件”。因為“Log4Shell”漏洞(CVE-2021-44228)而被更多人熟知的Apache Log4j2 就是關鍵基礎開源軟件中的一員，“Log4Shell”漏洞也讓我們認識到，關鍵基礎開源軟件一旦出現漏洞，其放大效應非常顯著，影響范圍巨大且難以消除。本節將分析主流開源生態中的關鍵基礎開源軟件及其安全狀況，希望通過此分析，可以讓我們看到還有哪些開源軟件可能會成為下一個 Apache Log4j2，也可以啟發我們關于開源軟件安全更進一步的思考。（1 1）主流

37、開源生態關鍵基礎開源軟件主流開源生態關鍵基礎開源軟件 T TOP50OP50 關于開源軟件重要性的度量，目前并沒有被廣泛認可的標準，OpenSSF 的“關鍵性評分（Criticality Score）”是可參考的一種方 17 法，但其更像是對軟件健康度的度量，不夠直觀。從安全的視角來看，如果開源軟件出現漏洞后，造成的放大效應越大，影響的范圍越廣，那么這個軟件就越重要，這樣直接依賴數將是決定一個開源軟件重要與否的關鍵性指標。本報告將使用直接依賴數作為開源軟件重要性度量的唯一指標，并且基于經驗參考將直接依賴數大于 1000 的開源軟件定義為關鍵基礎開源軟件。分析發現，Maven、NPM、Nuget

38、、Pypi、Packagist、Rubygems 等主流開源生態中直接依賴數大于 1000 的開源軟件共有 1068 款，直接依賴數排名 TOP50 的軟件見下表。從表中可以看出，開源軟件junit:junit 的直接依賴數高達 95614，排名第一，大名鼎鼎的 Apache Log4j2 并沒有出現在 TOP50 中，其直接依賴數為 7233，排在第 103名。換句話說，如果 TOP50 表里的任何一款開源軟件曝出嚴重漏洞，其影響可能都會大過 Apache Log4j2 的“Log4Shell”漏洞(CVE-2021-44228)。排名 開源軟件 所屬包生態系統 直接依賴數 1 junit:

39、junit Maven 95614 2 rake Rubygems 78524 3 bundler Rubygems 68683 4 org.scala-lang:scala-library Maven 68469 5 rspec Rubygems 58262 6 org.slf4j:slf4j-api Maven 49376 7 Newtonsoft.Json Nuget 48964 8 tslib NPM 42259 9 chalk NPM 34576 18 10 commander NPM 34494 11 lodash NPM 33964 12 requests Pypi 32640

40、13 numpy Pypi 32498 14 illuminate/support Packagist 29657 15 guzzlehttp/guzzle Packagist 26706 16 com.google.guava:guava Maven 26094 17 express NPM 24863 18 request NPM 24479 19 ch.qos.logback:logback-classic Maven 23898 20 org.mockito:mockito-core Maven 22417 21 inquirer NPM 21485 22 react NPM 2039

41、1 23 pandas Pypi 20223 24 axios NPM 20146 25 commons-io:commons-io Maven 19481 26 com.fasterxml.jackson.core:jackson-databind Maven 19229 27 mons:commons-lang3 Maven 19084 28 fs-extra NPM 18713 29 pytest Pypi 17708 30 org.clojure:clojure Maven 17304 31 pry Rubygems 14197 32 matplotlib Pypi 14015 33

42、log4j:log4j Maven 13749 34 org.projectlombok:lombok Maven 13735 35 laravel/framework Packagist 13472 36 scipy Pypi 13459 37 org.jetbrains.kotlin:kotlin-stdlib-common Maven 13386 19 38 org.jetbrains.kotlin:kotlin-stdlib-jdk8 Maven 13349 39 org.slf4j:slf4j-log4j12 Maven 13294 40 yiisoft/yii2 Packagist

43、 13094 41 typescript NPM 12921 42 rails Rubygems 12805 43 activesupport Rubygems 12791 44 minitest Rubygems 12624 45 react-dom NPM 12584 46 simplecov Rubygems 12520 47 moment NPM 12460 48 org.mockito:mockito-all Maven 12049 49 com.google.code.gson:gson Maven 11821 50 org.assertj:assertj-core Maven 1

44、1773（2 2）2 2/3 3 的關鍵基礎開源軟件從未公開披露過漏洞的關鍵基礎開源軟件從未公開披露過漏洞 公開披露產品漏洞信息，將漏洞進行編號，相關信息收錄到主流漏洞庫中，有助于漏洞的消控工作，也是目前軟件產品廠商的常規做法，目前國際軟件大廠在產品漏洞信息的公開披露方面可以說都做的比較優秀，但是對于開源軟件來說，目前的情況參差不齊，既有漏洞披露流程很正規的優秀開源項目，也有很多沒有漏洞披露流程的開源項目。分析發現，在上述的 1068 款關鍵基礎開源軟件中，有 711 款從未公開披露過漏洞，占比高達 66.6%。然而，從未公開披露過漏洞并不代表沒有漏洞，對于關鍵基礎開源軟件來說，如果沒有正規的

45、漏洞披露流程，安全風險很大。造成這種現象的原因主要有兩個，一是有很多漏洞被修補但沒有 20 公開披露，甚至沒有被記錄，這種情況在開源社區中比較常見，其隱藏的安全風險很大；二是這些開源軟件還沒有引起足夠的關注，針對其的漏洞挖掘研究不多，還是“一片未開墾的荒地”，而對于漏洞挖掘來說，這種“荒地”可能意味著未來的“產糧大戶”，隨著軟件供應鏈攻擊越來越被攻擊者青睞，這些關鍵基礎開源軟件將是未來防范的重點和難點。（3 3）關鍵基礎開源軟件的）關鍵基礎開源軟件的整體運維風險較高整體運維風險較高 從“版本更新時間”和“周提交頻率”兩個維度來分析，近一半的關鍵基礎開源軟件活躍度很低。其中，半年內沒有發布過新版

46、本的關鍵基礎開源軟件有 428 款，占比為 40.1%；一年內周平均提交次數小于 5 的關鍵基礎開源軟件數量為 503，占比為 47.1%；一年內周平均提交次數小于 1 的關鍵基礎開源軟件數量為 334，占比為 31.3%。另外，在 TOP50 的關鍵基礎開源軟件中，只有 24 款軟件明確已獲得大廠或者基金會的支持，有 9 款軟件的 Github 貢獻者數量小于100，而 npm 生態中的 fs-extra 則主要是由 JP Richardson 個人來維護的。整體來看，關鍵基礎開源軟件的運維狀況并不樂觀，相關安全風險較大。四、國內企業軟件開發中開源軟件應用狀況四、國內企業軟件開發中開源軟件應

47、用狀況 2021 年，奇安信代碼安全實驗室對 3354 個國內企業軟件項目中 21 使用開源軟件的情況進行了分析，這些軟件項目的應用領域涉及政府、金融、能源等重要行業。本年度報告中，新增了開源軟件許可協議風險分析以及漏洞的可利用性分析。從數據分析來看，國內企業使用開源軟件時的安全風險沒有得到改善，開源軟件安全風險是當前企業軟件開發中亟待解決的首要問題。1 1、開源開源軟件軟件總體使用情況總體使用情況分析分析 （1 1）平均每個軟件項目使用）平均每個軟件項目使用 127127 個開源軟件個開源軟件 在被分析的 3354 個國內企業軟件項目中，全部使用了開源軟件，使用率為 100%。最多的項目使用

48、了 4862 個開源軟件，平均每個項目使用 127 個開源軟件，平均值與去年報告的 126 相當。使用開源軟件最多的 10 個項目情況如下表所示。項目名稱 使用的開源軟件數量 項目 1 4862 項目 2 4220 項目 3 3878 項目 4 3838 項目 5 3832 項目 6 3778 項目 7 3536 項目 8 3205 項目 9 3062 項目 10 2997（2 2）流行開源軟件被超過）流行開源軟件被超過 1/31/3 的的軟件軟件項目使用項目使用 在分析的 3354 個國內企業軟件項目中，使用最多的開源軟件為 22 Simple Logging Facade for Java

49、(SLF4J)，被 1213 個項目所使用，占比達 36.2%，遠超去年報告中最高的 24.3%。被使用最多的前 10 名開源軟件如下表所示。開源軟件名稱 使用的項目數 被使用率 Simple Logging Facade for Java(SLF4J)1213 36.2%Apache Commons Lang 1187 35.4%Commons IO 1070 31.9%log4j 1047 31.2%Spring Framework 1009 30.1%Apache Commons Codec 1005 30.0%Guava:Google Core Libraries for Java 9

50、64 28.7%Apache HttpComponents Client(aka Apache HttpClient)960 28.6%jackson-databind 959 28.6%Jackson JSON processor 959 28.6%2 2、開源軟件漏洞風險分析、開源軟件漏洞風險分析 （1 1）77%77%的的軟件項目存在容易利用的開源軟件漏洞軟件項目存在容易利用的開源軟件漏洞 分析發現，在 3354 個國內企業軟件項目中，存在已知開源軟件漏洞的項目有 2897 個，占比高達 86.4%；存在已知高危開源軟件漏洞的項目有 2680 個，占比為 79.9%；存在已知超危開源軟件

51、漏洞的項目有 2400 個，占比為 71.6%。本年度報告中還針對漏洞的利用難度進行了分析，綜合漏洞的POC/EXP 情況以及 CVSS 可利用性指標等因素，我們將漏洞的利用難度分為容易、一般、困難。容易利用的漏洞風險極高，需要被及時修 23 補。在分析的3354個項目中，存在容易利用的漏洞的項目有2581個，占比高達 77.0%。（2 2）平均每個軟件項目存在）平均每個軟件項目存在 6969 個個已知開源軟件漏洞已知開源軟件漏洞 在 3354 個國內企業軟件項目中，共檢出 231368 個已知開源軟件漏洞（涉及到 7269 個唯一 CVE 漏洞編號），平均每個軟件項目存在 69個已知開源軟件

52、漏洞，略高于去年報告中的 66 個，最多的軟件項目存在 1555 個已知開源軟件漏洞。存在已知開源軟件漏洞數量排名前10 的項目情況如下表所示。項目 存在開源軟件漏洞數量 項目 1 1555 項目 2 1368 項目 3 1214 項目 4 1209 項目 5 798 項目 6 771 項目 7 770 項目 8 762 項目 9 740 項目 10 718（3 3）影響最廣的）影響最廣的開源開源軟件軟件漏洞漏洞存在于超存在于超 3 3 成的軟件項目中成的軟件項目中 從漏洞的影響度來分析，影響范圍最大的開源軟件漏洞為 CVE-2022-22965，存在于 31.7%的軟件項目中。2021 年影

53、響度排名前 10的開源軟件漏洞如下表所示。24 漏洞名稱 CVE 編號 影響項目數量 影響度 Spring Framework 遠程代碼執行漏洞 CVE-2022-22965 1063 31.7%Vmware Spring Framework 安全漏洞 CVE-2022-22950 1009 30.1%Vmware Spring Framework 安全特征問題漏洞 CVE-2022-22968 1009 30.1%Vmware Spring Framework 代碼問題漏洞 CVE-2016-1000027 1009 30.1%FasterXML jackson-databind 緩沖區錯誤

54、漏洞 CVE-2020-36518 946 28.2%Apache Commons IO 路徑遍歷漏洞 CVE-2021-29425 893 26.6%Google Guava 訪問控制錯誤漏洞 CVE-2020-8908 878 26.2%Apache Log4j 信任管理問題漏洞 CVE-2020-9488 859 25.6%jQuery 跨站腳本漏洞 CVE-2020-11022 819 24.4%jQuery 跨站腳本漏洞 CVE-2020-11023 819 24.4%容易利用的漏洞更易被用來發起攻擊，這類漏洞風險極高。影響度排名前 10 的容易利用的開源軟件漏洞情況如下表所示。從表

55、中我們可以看到，Apache Log4j2 的“Log4Shell”漏洞（CVE-2021-44228）排在容易利用的漏洞影響度第 10 名。容易利用的漏洞名稱 CVE 編號 影響項目數量 影響度 Spring Framework 遠程代碼執行漏洞 CVE-2022-22965 1063 31.7%Vmware Spring Framework 代碼問題漏洞 CVE-2016-1000027 1009 30.1%jQuery 跨站腳本漏洞 CVE-2020-11022 819 24.4%jQuery 跨站腳本漏洞 CVE-2020-11023 819 24.4%Apache HttpClien

56、t 安全漏洞 CVE-2020-13956 796 23.7%OpenSSL 緩沖區錯誤漏洞 CVE-2021-3711 774 23.1%jQuery 跨站腳本漏洞 CVE-2019-11358 765 22.8%FasterXML jackson-databind 代碼問題漏洞 CVE-2020-8840 763 22.7%jQuery 跨站腳本漏洞 CVE-2015-9251 689 20.5%25 Apache Log4j 代碼問題漏洞 CVE-2021-44228 666 19.9%（4 4）1 16 6 年前的開源軟件年前的開源軟件漏洞漏洞仍然存在于多個軟件項目中仍然存在于多個軟件

57、項目中 分析發現，與 2020 年結果一樣，部分軟件項目中仍然存在十幾年前公開的古老開源軟件漏洞，最古老的漏洞是 2005 年 8 月公開的CVE-2005-2541，仍然存在于 13 個項目中。部分古老開源軟件漏洞的影響情況如下表所示。漏洞名稱 CVE 編號 發布日期 影響項目數量 GNU Tar 安全漏洞 CVE-2005-2541 2005.08.10 13 Apache Tomcat 目錄列表拒絕服務漏洞 CVE-2005-3510 2005.11.06 29 Apache Struts 錯誤響應跨站腳本漏洞 CVE-2005-3745 2005.11.22 1 Apache Tomc

58、at 跨站腳本攻擊漏洞 CVE-2005-4838 2005.12.31 30 Apache Software Foundation(ASF)Struts org.apache.struts.taglib.html.Constants.CANCEL參數安全繞過漏洞 CVE-2006-1546 2006.03.30 17 Apache Software Foundation(ASF)Struts ActionForm 拒絕服務漏洞 CVE-2006-1547 2006.03.30 17 Apache Struts 多個遠程漏洞 CVE-2006-1548 2006.03.30 17 GnuPG

59、parse-packet.c 遠程緩沖區錯誤漏洞 CVE-2006-3082 2006.06.19 5 Apache Tomcat遠 程 目 錄 index.jsp信息泄露漏洞 CVE-2006-3835 2006.07.25 9 Direct Web Rendering 安全繞過漏洞 CVE-2007-0184 2007.01.12 1 3 3、開源軟件許可協議風險分析、開源軟件許可協議風險分析 開源許可協議是開源社區為了維護開源軟件作者和貢獻者的合 26 法權利，而定義的一組條款和條件，其他人必須在遵循這些條款和條件的基礎上，使用、修改或共享開源軟件的源代碼、設計和文檔。有些開源許可協議是

60、不允許將開源軟件修改后做為閉源的商業軟件發布和銷售的，如 AGPL、GPL 等。企業如未按許可協議的要求使用開源軟件，可能會帶來知識產權方面的風險。（1 1）最流行的開源）最流行的開源許可協議許可協議在超在超 3 3/4/4 的項目中使用的項目中使用 在 3354 個被分析的國內企業軟件項目中，共發現 488 個開源許可協議。涉及項目數最多的協議是 Apache License 2.0，在 2586 個項目中使用，占比為 77.1%。涉及軟件項目數排名前 10 的許可協議如下表所示。開源許可協議 涉及項目數 所占比例 Apache License 2.0 2586 77.1%MIT Licen

61、se 2428 72.4%BSD 3-Clause New or Revised License 1716 51.2%Eclipse Public License 1.0 922 27.5%BSD 2-Clause Simplified License 764 22.8%GNU General Public License v2.0 or later 690 20.6%BSD 4-Clause Original or Old License 660 19.7%ISC License 556 16.6%GNU Lesser General Public License v2.1 only 472

62、 14.1%Mozilla Public License 1.1 426 12.7%（2 2）4 45.6%5.6%的項目使用了含有高風險許可協議的開源軟件的項目使用了含有高風險許可協議的開源軟件 在 3354 個被分析的國內企業軟件項目中，存在高風險許可協議 27 的項目 1530 個，占比 45.6%。所謂高風險許可協議，是指這類許可協議中包含了一些限制性較強的條款，在使用過程中一旦違反這些條款，可能對企業的商業利益和聲譽造成嚴重的損害。這些限制性條款主要包括：“禁止本軟件及其衍生品用于商業目的”，“禁止在未支付費用和版稅的情況下將該軟件用于非公開、非商業用途”,“軟件發布時必須公開軟件的

63、源代碼”等。涉及軟件項目數排名前 10 的高風險許可協議如下表所示。開源許可協議 涉及項目數 所占比例 Eclipse Public License 1.0 919 27.4%Mozilla Public License 1.1 425 12.7%GNU General Public License v2.0 or later 248 7.4%GNU Lesser General Public License v2.1 only 231 6.9%GNU Affero General Public License v3.0 173 5.2%GNU General Public License v

64、2.0 only 123 3.7%GNU General Public License v3.0 only 85 2.5%GNU Library General Public License v2.1 or later 74 2.2%GNU General Public License v3.0 or later 62 1.8%GNU Library General Public License v2 only 56 1.7%4 4、開源開源軟件運維風險分析軟件運維風險分析 開源軟件運維風險復雜多樣，報告主要從老舊開源軟件的使用和開源軟件多版本的使用角度進行分析。（1 1）2020 年前的老舊

65、開源軟件版本仍在被使用年前的老舊開源軟件版本仍在被使用 分析發現，與去年報告數據一致，許多軟件項目中仍然在使用十 28 幾年甚至 20 年前發布的開源軟件版本，存在很大的運維風險。被使用的老舊開源軟件版本中，最老舊的一個是 2002 年 5 月 15 日發布的JDOM 1.0-FCS，已經有 20 年之久，但仍然被 28 個軟件項目所使用。按老舊程度排名前 10 的開源軟件如下表所示。開源軟件名稱 版本號 版本發布日期 使用它的項目數量 JDOM 1.0-FCS 2002.05.15 28 Apache Xalan 2.5.D1 2003.03.03 1 XML Pull Parsing AP

66、I 1.1.3.1 2003.06.17 228 JUnit 3.8.1 2004.03.05 100 Log4j 1.2.8 2004.03.05 52 SSLExt 1.2-0 2004.10.04 26 jaxen 1.0-FCS 2005.04.27 13 Mockobjects Core 0.09 2005.04.27 3 Mockobjects Jdk1 4 J2ee1 3 0.09 2005.04.27 3 JLine 0.9.1 2005.05.18 3（2 2）開源軟件各版本使用更加混亂）開源軟件各版本使用更加混亂 分析發現，各個項目中開源軟件使用的版本非?；靵y，并非使用的都

67、是最新版本。Spring Data 是被使用版本最多的開源軟件，有 235個版本在被使用，比去年報告中最多的 162 高出很多，說明開源軟件版本使用混亂的狀況更加嚴重。按照被使用版本的數量排序，排名前10 的開源軟件情況如下表所示。開源軟件名稱 被使用的版本數量 Spring Data 235 Spring Framework 226 29 Apache Tomcat 206 types/node 186 jackson-databind 170 electron-to-chromium 168 Hibernate ORM 162 Jetty 158 Spring TestContext Fr

68、amework 155 Spring Boot 145 五、典型軟件供應鏈安全風險實例分析五、典型軟件供應鏈安全風險實例分析 1 1、某主流網絡接入存儲、某主流網絡接入存儲(NAS)NAS)設備設備供應鏈攻擊實例分析供應鏈攻擊實例分析 網絡接入存儲 NAS 基于標準網絡協議實現數據傳輸，為網絡中的Windows/Linux/Mac OS 等各種不同操作系統的計算機提供文件共享和數據備份，在云存儲、數據容災、Web 服務器等中廣泛使用。本實例中我們分析的 NAS 系統在市場占有率方面具有領先優勢，且預裝了磁盤站管理系統。經分析發現，該磁盤站管理系統中使用了 SQLite、libssh2、Neta

69、talk 等在內的超過 200 款開源軟件，并由此引入了 1000 余個已知開源軟件漏洞，其中包括超危漏洞 195 個、高危漏洞 461 個。該磁盤站管理系統使用的部分開源軟件及漏洞情況如下表所示。序號 開源軟件名稱 開源軟件版本 漏洞情況 1 SQLite 3.10.2 超危:5,高危:6,中危:7 2 libssh2 1.7.0 超危:5,高危:6 3 libpng 1.6.28 超危:2,高危:3,中危:9 4 zlib 1.2.8 超危:2,高危:3 30 5 OpenSSL 1.0.2n 超危:1,高危:4,中危:12,低危:3 6 6 NetatalkNetatalk 3.1.83

70、.1.8 超危超危:1,:1,高危高危:1:1 7 bzip2 1.0.6 超危:1,中危:1 8 libTIFF 4.0.8 高危:6,中危:15 9 c-ares 1.12.0 高危:2,中危:1 10 pip 8.1.1 高危:2,中危:1 這其中，Netatalk 是一款開源的 Apple Filing Protocol(AFP)服務程序，Linux 或 BSD 等系統可使用它提供 Mac 文件服務器文件共享功能，被應用于多家主流 NAS 廠商的設備中。CVE-2021-31439 是 Netatalk 的一個高危歷史漏洞（上表中所示），Netatalk 組件在處理 DSI 數據包時存

71、在堆溢出問題，未認證的用戶通過發送精心構造的數據包，可實現任意代碼執行，從而獲取設備的控制權。該漏洞影響 Netatalk 組件當前所有版本。進一步分析驗證發現，利用該漏洞，可成功攻擊磁盤站管理系統所屬的 NAS 設備，如下圖所示，成功攻擊后可獲取反彈 Shell，且對應的權限為 root。本實例中，軟件供應鏈風險傳播鏈條如下：Netatalk 組件被 NAS設備的磁盤站管理系統所使用，且該服務默認開啟，因此 Netatalk 組件的漏洞影響了該 NAS 設備，導致可針對其成功實施軟件供應鏈攻擊。31 2 2、某主流某主流 VPNVPN 路由器供應鏈攻擊實例分析路由器供應鏈攻擊實例分析 某國際

72、 TOP 廠商主流千兆 VPN 路由器，廣泛應用于各類企業中。對其固件進行分析發現，固件中使用了 tcpdump、mutt、lldpd 等在內的超過90款開源軟件，并由此引入了500余個已知開源軟件漏洞，其中包括超危漏洞 162 個、高危漏洞 214 個。該固件中使用的部分開源軟件及漏洞情況如下表所示。序號 開源軟件名稱 版本 漏洞情況 1 tcpdump 4.9.2 超危:85,高危:30,中危:2,低危:1 2 mutt 1.5.16 超危:11,中危:10 3 SQLite 3.21.0 超危:3,高危:6,中危:6 4 PCRE 8.35 超危:2,高危:21,中危:7 5 zlib

73、1.2.8 超危:2,高危:3 6 openldap-LDAP support libraries 2.4.23 超危:1,高危:17,中危:13,低危:1 7 OpenSSL 1.0.2o 超危:1,高危:4,中危:11,低危:3 8 8 lldpdlldpd 0.6.00.6.0 超危超危:1,:1,高危高危:3:3 9 bzip2 1.0.6 超危:1,中危:1 10 GNU Binutils 2.24 高危:10,中危:24,低危:1 這其中，開源軟件 lldpd 是 LLDP 行業標準（旨在取代 EDP、CDP之類的專有鏈路層協議）的 ISC 許可實現，適用于各種 Unix 系統，并

74、被廣泛應用于主流廠商的網絡設備(AP、交換機、路由器和攝像頭等)中。CVE-2015-8011 是 lldpd 的一個超危歷史漏洞（上表中所示），攻擊者可通過發送精心構造的數據包，使得在處理 lldp 數據包中的Management Address TLV 時發生緩沖區溢出，從而引發代碼執行。部分廠商雖然采用了防御性編程,但程序仍會崩潰，造成拒絕服務危害。32 值得注意的是，盡管該漏洞是 7 年前被發現的，且 lldpd 官方倉庫也發布了相應的更新，但它至今依然存在于部分廠商的網絡設備中。進一步分析驗證發現，利用該漏洞可成功攻擊此案例中的 VPN 路由器，因設備采用了防御性編程，漏洞可造成拒絕

75、服務的危害。如下圖所示，gdb 調試器捕獲到了 SIGABRT 信號，同時對應的進程退出，攻擊成功。本實例中，軟件供應鏈風險傳播鏈條如下：開源組件 lldpd 被該 33 該款主流 VPN 路由器中的固件所使用，進而 lldpd 組件的漏洞影響該路由器，即針對路由器成功實施了軟件供應鏈攻擊。3 3、三款國產操作系統供應鏈攻擊實例分析、三款國產操作系統供應鏈攻擊實例分析 Polkit 是一個開源應用程序框架，通過定義和審核權限規則，實現不同優先級進程間的通訊，使得控制決策集中在統一的框架之中，決定低優先級進程是否有權訪問高優先級進程。分析發現，開源軟件Polkit 廣泛應用于基于 Linux 內

76、核的國產操作系統中，其漏洞可能引發針對這些操作系統的軟件供應鏈攻擊。驗證發現，至少 3 款主流國產操作系統會受到 Polkit 歷史漏洞的影響。以某主流國產操作系統為例，它基于 Linux 內核，是一款通用的桌面電腦操作系統，并加入了大量的本地優化功能。經分析發現，該國產操作系統中使用了 libssh2、libpng、PolKit等在內的超過 1000 款開源軟件，并由此引入了 1000 余個已知開源軟件漏洞，其中包括超危漏洞 267 個、高危漏洞 599 個。該操作系統中使用的部分開源軟件及漏洞情況如下表所示。序號 開源軟件名稱 開源軟件版本 漏洞情況 1 libssh2 1.4.3 超危:

77、5,高危:6 2 libpng 1.6.28 超危:2,高危:3,中危:9 3 libproxy 0.4.15 超危:1,高危:1 4 OpenJPEG 2.3.1 高危:6,中危:7 5 5 PolKitPolKit 0.1050.105 高危高危:4,:4,中危中危:6,:6,低危低危:1:1 6 urllib3 1.25.8 高危:1,中危:1 7 python-rsa 4.0 高危:1,中危:1 8 httplib2 0.14.0 高危:1,中危:1 34 9 ReportLab 3.5.34 中危:1 10 paramiko 2.6.0 中危:1 CVE-2021-4034 是 Po

78、lkit 的 pkexec 組件中的一個高危歷史漏洞（上表中所示），利用此漏洞可在沒有參數的情況下越界讀寫參數，從而提升普通用戶的權限，實現本地權限提升攻擊，危害極大。進一步分析驗證發現，利用 CVE-2021-4034 可對該國產操作系統進行攻擊，如下圖所示，漏洞被成功利用后完成了從普通用戶“aa”到超級用戶“root”的切換，實現了權限提升。本實例中，軟件供應鏈風險傳播鏈條如下：開源軟件 Polkit 被國產操作系統所使用，Polkit 中 pkexec 組件的漏洞影響了這些操作系統，導致可針對其實施權限提升方面的軟件供應鏈攻擊。35 4 4、某國產郵件系統供應鏈攻擊實例分析某國產郵件系統

79、供應鏈攻擊實例分析 某國產郵件系統是一款通用郵件管理系統，在國內擁有大量的用戶，用戶量達數億級。經分析發現，該國產郵件系統中使用了 jackson-databind、Spring Framework、Apache Tomcat 等在內的超過 100 款開源軟件，并由此引入了800余個已知開源軟件漏洞，其中包括超危漏洞56個、高危漏洞 151 個。該郵件系統中使用的部分開源軟件及漏洞情況如下表所示。序號 開源軟件名稱 開源軟件版本 漏洞情況 1 jackson-databind 2.7.4 超危:25,高危:38,中危:4 2 Jetty:Java based HTTP/1.x,HTTP/2,S

80、ervlet,WebSocket Server 6.1.14 超 危:3,高 危:5,中危:10,低危:1 3 Spring Framework 5.1.5.RELEASE 超危:2,高危:2,中危:6 4 4 Apache TomcatApache Tomcat 9.0.279.0.27 超 危超 危:1,:1,高 危高 危:15,:15,中中危危:5:5 5 MySQL Connector/J 5.1.44 超 危:1,高 危:4,中危:6,低危:2 6 CXF 3.3.0 超危:1,高危:3,中危:4 7 nginx 1.14.2 超危:1,高危:3,中危:3 8 Protocol Bu

81、ffers 2.6.1 高危:2,中危:1 9 Apache Portable Runtime 1.5.1 高危:2 10 Apache Ant 1.10.5 高危:1,中危:3 其中，Tomcat 是全世界最著名的基于 Java 語言的輕量級應用服務器，是一款完全開源免費的 Servlet 容器實現，是 Apache 軟件基金會（Apache Software Foundation）的 Jakarta 項目中的一個核心項目。Tomcat 由于技術先進、性能穩定、而且免費，成為了流行的 36 Web 應用服務器。CVE-2020-1938 是 Tomcat 的 Tomcat AJP Conne

82、ctor 模塊中的一個高危歷史漏洞（上表中所示），可以讀取 Tomcat 上 webapps 目錄下的任意文件，如 webapps 配置文件或源代碼；或者可以通過配合文件上傳漏洞實現 webapps 目錄下本地文件的包含，達到命令執行的目的，危害極大。進一步分析驗證發現，利用 CVE-2020-1938 可對該國產郵件系統進行攻擊，如下圖所示，漏洞被成功利用后完成了下載其中某個 JSP文件的效果。本實例中，軟件供應鏈風險傳播鏈條如下：開源軟件 Tomcat 被某國產郵件系統所使用，Tomcat 中 Tomcat AJP Connector 模塊的漏洞影響了該郵件系統，導致可針對其實施文件下載的

83、軟件供應鏈攻擊。5 5、EdgeEdge 瀏覽器供應鏈攻擊實例分析瀏覽器供應鏈攻擊實例分析 Chromium 內核是 Google 發布的免費開源項目，在許多主流瀏覽器中都有使用，如微軟 Edge 瀏覽器、Google Chrome 瀏覽器、Opera瀏覽器等。分析發現，Chromium 內核中使用的開源軟件超過 230 款，包括 37 V8、libpng、libxlst、zlib、SQLite 等，其中 V8 是一款 C+語言編寫的高性能 JavaScript 和 WebAssembly 開源引擎，用來高效穩定的解析執行 JavaScript 腳本。CVE-2021-21224 是 V8 的

84、一個高危歷史漏洞，可導致遠程代碼執行。具體而言，V8 的 JIT 模塊存在類型混淆問題，攻擊者可通過構造JavaScript 腳本，實現內存的越界讀寫，造成遠程代碼執行的危害。進一步分析驗證發現，攻擊者可以利用 V8 的 CVE-2021-21224 漏洞，通過“網頁釣魚攻擊”的方式在網頁中隱藏漏洞利用代碼，從而對 Edge 瀏覽器(90.0.818.41 之前版本)進行攻擊，如下圖所示。本實例中的軟件供應鏈風險傳播鏈條如下：Edge 瀏覽器中使用了 Chromium 內核，Chromium 內核又包含開源引擎 V8，因此 V8 引擎的漏洞影響了 Edge 瀏覽器，導致可對其成功實施軟件供應鏈

85、攻擊。38 六、總結及建議六、總結及建議 過去的一年里，我們看到軟件供應鏈安全的一系列國家標準、行業標準正在制定中，軟件供應鏈安全相關的科研課題和建設項目逐漸增多，部分重要行業監管部門還出臺了關于軟件供應鏈安全的具體工作要求，面向軟件供應鏈安全的社區、聯盟、論壇等也在逐漸建立和完善中，軟件供應鏈安全的重要性已經逐步成為各方共識。但另一方面我們也看到，國內大多數機構和企業目前對于軟件供應鏈安全還處于了解和保持關注階段，尚未付諸真正的行動。從本報告中國內企業軟件開發項目的實測數據來看，軟件供應鏈安全相關風險很高，形勢嚴峻且緊迫。鑒于這一現狀，我們呼吁：從現在開始就行動起來，不要讓軟件供應鏈安全成“

86、灰犀?！?。軟件組成成分的透明性是軟件供應鏈安全保障的基礎，我們建議將軟件物料清單（SBOM）作為軟件供應鏈安全的抓手首先推進落地，通過軟件物料清單（SBOM）的推廣應用，牽引軟件供應鏈上下游各個環節的協同，在此基礎之上再采取更多舉措逐步深化，實現軟件供應鏈安全保障的目標。關于軟件物料清單（SBOM）的推進落地，具體建議如下：1 1）從國家與行業監管層面的建議）從國家與行業監管層面的建議 提高關鍵基礎設施和重要信息系統用戶軟件供應鏈安全保障的要求，要求向關鍵基礎設施和重要信息系統用戶銷售軟件產品、提供軟件定制開發的廠商和供應商，在交付軟件系統的同時，需提供軟件 39 物料清單（SBOM），以保持

87、足夠的透明性；組織制定軟件物料清單（SBOM）相關的國家標準、行業標準，規范針對軟件物料清單（SBOM）的格式和內容要求，促進軟件物料清單（SBOM）成為軟件產品的標配；建立相應的公共服務平臺，提供軟件物料清單（SBOM）的檢測驗證、數據查詢、威脅情報等服務。2 2）從軟件廠商和供應商層面的建議）從軟件廠商和供應商層面的建議 在自身軟件開發流程中采用開源安全治理工具，持續監測軟件開發中所使用的開源軟件物料，消減其安全風險；產品正式發布時，應提取和生成產品的軟件物料清單（SBOM），并隨軟件向客戶提供；針對自身軟件產品中所使用的軟件物料，持續監測其安全漏洞等風險情況，并及時為客戶提供相應的技術支

88、持服務。3 3）從軟件最終用戶層面的建議）從軟件最終用戶層面的建議 保持對軟件物料透明性的高度關注，在購買軟件產品或委托定制開發軟件系統時，要求廠商和供應商提軟件物料清單（SBOM），并與其簽訂安全責任協議，要求其對軟件物料的安全性負責并提供后續的技術支持服務；對于運行重要業務的軟件系統，應使用合適的檢測工具驗證廠商和供應商所提供的軟件物料清單（SBOM）的正確性，確認軟件的組成成分及安全風險狀況；在軟件系統日常運行過程中，應基于軟件物料清單（SBOM）持續跟蹤軟件物料相關的威脅情報，及時采取安全措施，消減相關安全風險。40 附錄：奇安信代碼安全實驗室簡介附錄：奇安信代碼安全實驗室簡介 奇安信

89、代碼安全實驗室是奇安信集團旗下，專注于軟件源代碼安全分析技術、二進制漏洞挖掘技術研究與開發的團隊。實驗室支撐國家級漏洞平臺的技術工作，多次向國家信息安全漏洞庫（CNNVD）和國家信息安全漏洞共享平臺（CNVD）報送原創通用型漏洞信息并獲得表彰；幫助微軟、谷歌、蘋果、Cisco、Juniper、Red Hat、Ubuntu、Oracle、Adobe、VMware、阿里云、飛塔、華為、施耐德、Mikrotik、Netgear、D-Link、Netis、ThinkPHP、以太坊、Facebook、亞馬遜、IBM、SAP、NetFlix、Kubernetes、Apache 基金會、騰訊、滴滴等大型廠商

90、和機構的商用產品或開源項目發現了數百個安全缺陷和漏洞，并獲得公開致謝。目前，實驗室擁有國家信息安全漏洞庫（CNNVD）特聘專家一名，多名成員入選微軟全球 TOP 安全研究者、Oracle 安全縱深防御計劃貢獻者等精英榜單。在Pwn2Own 2017世界黑客大賽上，實驗室成員還曾獲得 Master of Pwn 破解大師冠軍稱號?；谄姘残糯a安全實驗室多年的技術積累，奇安信集團在國內率先推出了自主可控的軟件代碼安全分析系統奇安信代碼衛士和奇安信開源衛士。奇安信代碼衛士是一套靜態應用程序安全測試系統，可檢測 2600 多種源代碼安全缺陷，支持 C、C+、C#、Objective-C、Swift、

91、Java、JavaScript、PHP、Python、Cobol、Go 等 20 多種編程語言。奇安信開源衛士是一套集開源軟件識別與安全管控于一體的軟件成分風險分析系統，通過智能化數據收集引擎在全球范圍內廣41 泛獲取開源軟件信息和漏洞信息，幫助客戶掌握開源軟件資產狀況，及時獲取開源軟件漏洞情報，降低由開源軟件帶來的安全風險，奇安信開源衛士目前可識別 9000 多萬個開源軟件版本，兼容 NVD、CNNVD、CNVD 等多個漏洞庫。奇安信代碼衛士和奇安信開源衛士目前已經在數百家大型企業和機構中應用，幫助客戶構建自身的代碼安全保障體系，消減軟件代碼安全隱患，并入選國家發改委數字化轉型伙伴行動、工信部中小企業數字化賦能專項行動，為中小企業提供軟件代碼安全檢測平臺和服務。