2022年開源軟件供應鏈安全風險研究報告

2022年開源軟件供應鏈安全風險研究報告PAGEPAGE10目錄前言 1一、開漏洞展現(xiàn)趨勢 3發(fā)現(xiàn)一開源件漏體呈增趨勢，2020增長率有下降 3發(fā)現(xiàn)二：CVE方未錄的開軟件洞數(shù)遞增 4發(fā)現(xiàn)三開源件漏由POC披露到NVD首公開時長達11年 4發(fā)現(xiàn)四近4，高以上開漏洞比均超40% 5發(fā)現(xiàn)五：2020，最要缺陷型為CWE-79 6二、開組件態(tài)安全險分析 8發(fā)現(xiàn)六開源件生的漏洞呈上趨勢，2020年環(huán)增長40% 8發(fā)現(xiàn)七近6中Maven倉庫洞數(shù)最多 9發(fā)現(xiàn)八超半倉庫洞數(shù)均上年所增長 10發(fā)現(xiàn)九：2020高危洞占比高，比去加2.6左右 10發(fā)現(xiàn)十：2020，含危以上洞占最多是Rubygems 12發(fā)現(xiàn)十：平每版洞最多的TOP25組件五成來自Composer倉庫 12三、組漏洞賴層播范圍析 15發(fā)現(xiàn)十：一傳播范圍擴大125，二播影響圍擴大173倍 15發(fā)現(xiàn)十：npm倉庫中組件經(jīng)2輪傳，影件數(shù)量多 16發(fā)現(xiàn)十：一傳播范圍最的倉是Composer 16發(fā)現(xiàn)十：二傳播范圍最的倉是Nuget 17發(fā)現(xiàn)十：傳影響最小的庫是Maven 18四、開文件在漏險傳播析 20發(fā)現(xiàn)十：超80%漏件在開項目有同件 20發(fā)現(xiàn)十：漏文件源項目傳播圍擴大54倍 21案例分析 21五、開安全險建議 23一、開源漏洞發(fā)展現(xiàn)狀及趨勢開源軟件具有代碼公開、易獲取、可重用的特點，這一特點是開源軟件熱度攀升的重要原因。隨著開源軟件的廣泛使用，一旦軟件發(fā)現(xiàn)安全漏洞，必將給開發(fā)、安全團隊帶來嚴峻的挑戰(zhàn)。然而，開源漏同時，對于軟件使用者，由于缺少漏洞信息跟蹤能力，使得漏洞修復具有滯后性，提升了軟件被攻擊的風險，為軟件供應鏈安全管控增加了難度。本次研究收錄了官方漏洞庫、開源社區(qū)等渠道的數(shù)據(jù)120152020年發(fā)布的開源漏洞為研究對象，本報告展示了近6年開源安全漏洞發(fā)展現(xiàn)狀及趨勢。發(fā)現(xiàn)一：開源軟件漏洞整體呈增長趨勢，2020年增長率略有下降圖1 開源漏洞時間分布201551國家信息安全漏洞CNVD共享平臺（/）、美國國家漏洞庫（https://nvd.nist.gov/）、通用漏洞披露庫（/）等2018GitHub官方數(shù)1/320186756320152.85倍；201792.86%；201920202019年發(fā)1746條。發(fā)現(xiàn)二：CVE官方未收錄的開源軟件漏洞數(shù)逐年遞增圖2 CVE官方未收錄開源漏洞情況CVE官方網(wǎng)站22020CVE1362202023.78%；CVE2017133.52%。POCNVD11年2020CVE-2009-4067Linux內核AuerswaldLinuxUSBPOC披露到NVD11年。POC20091019日披露3；20091124日獲得CVE2020112NVD（NVD等440%圖3 含高危以上漏洞占比62015年30.87202056%；其中，20172020年高危及46.9120205成。圖4 2020年漏洞危害等級占比發(fā)現(xiàn)五：2020CWE-79圖5 2020年開源漏洞TOP10CWE缺陷類型CWE-792020110CWE很容易并被利用，往往通過系統(tǒng)信息暴露、竊取數(shù)據(jù)或阻止應用程序CWE可以幫助開發(fā)人員、測試人員、用戶、項目經(jīng)理以及安全研究人員深入了解當前最嚴重的安全漏洞。表1 2020年開源漏洞TOP10CWE缺陷類型CWE編號中文名稱個數(shù)CWE-79在Web頁面生成時對輸入的轉義處理不恰當（跨站腳本）824CWE-506內嵌的惡意代碼726CWE-400未加控制的資源消耗（資源窮盡）510CWE-200信息暴露305CWE-20輸入驗證不恰當212CWE-94對生成代碼的控制不恰當（代碼注入）201CWE-119內存緩沖區(qū)邊界內操作的限制不恰當142CWE-125跨界內存讀134CWE-78OS命令中使用的特殊元素轉義處理不恰當（OS命令注入）124CWE-325缺少必要的密碼學步驟117二、開源組件生態(tài)安全風險分析開源組件生態(tài)蓬勃發(fā)展，重要原因是組件獨立、可復用。組件化可以大幅度提高開發(fā)效率、可測試性、可復用性、提升應用性能。同組件標準化使得優(yōu)質好用的組件越來越多，用戶也更愿意使用，形成開源組件被廣泛使用，根據(jù)官方數(shù)據(jù)顯示，Maven倉庫數(shù)據(jù)量已650930712億，PyPI49萬。CocoaPods4Composer5Maven7npm8Nuget9、PyPI10、Rubygems1186年各倉發(fā)現(xiàn)六：開源組件生態(tài)中的漏洞數(shù)呈上漲趨勢，2020年環(huán)比增長40%6304.48倍。圖6 開源組件生態(tài)漏洞時間分布6年中Maven倉庫漏洞數(shù)量最多圖7 近6年中各組件倉庫漏洞情況6Maven3533個；Go3481413個。發(fā)現(xiàn)八：超半數(shù)倉庫的漏洞數(shù)均較上年有所增長圖8 近6年各倉庫漏洞分布圖6年，Composer、、Maven、、PyPI、Rubygems6Rubygems倉庫漏10.5倉庫和PyPI252132%；Maven2020發(fā)現(xiàn)九：20202.6倍左右20201826202053%，201920202.6220182019171個。圖9 近6年新增漏洞風險等級時間分布圖10 近6年新增漏洞各風險等級占比發(fā)現(xiàn)十：2020Rubygems圖11 2020年各倉庫中含高危以上漏洞占比402020年,RubygemsRubygems倉庫新增漏2020Go倉庫新增25組件約五成來自Composer倉庫202025/1257Maven47圖12平均版本漏洞最多TOP25組件倉庫分布圖13Composer倉庫組件分布圖14PyPI倉庫組件分布圖15Maven倉庫組件分布圖16npm和Nuget倉庫組件分布三、組件漏洞依賴層級傳播范圍分析軟件工程中經(jīng)常引用組件來實現(xiàn)某些功能，組件之間存在相互依ABCABBCAC組件存在安全漏洞，組件之間又存在相互依賴關系，導致漏洞在組件Maven、npm、Rubygems、PyPI、Composer、Nuget66,41612，6,416定義，稱該組件范圍為一級傳播；第二輪實驗，查找直接依賴一級傳6,416125倍，二級傳播影響范圍擴173倍圖17組件漏洞依賴層級傳播范圍6,416801,164125倍。第1,109,5196,416173發(fā)現(xiàn)十三：npm2輪傳播，影響組件數(shù)量最多圖18各倉庫組件漏洞傳播范圍RubygemsPyPIComposerNuget61,962Maven6npm倉庫。1,962459,876個組件,漏洞的影響范圍擴大了234倍；二級傳播共波及601,5741,962307Composer圖19各倉庫一級傳播影響范圍Composer380個，為651播波影響范圍最廣的倉庫是Composer。經(jīng)過一級傳播共波及99,611262發(fā)現(xiàn)十五：二級傳播影響范圍最廣的倉庫是Nuget1726組2廣的倉庫是Nuget23,24013584,995172個494圖20各倉庫二級傳播影響范圍發(fā)現(xiàn)十六：傳播影響范圍最小的倉庫是Maven圖21兩輪漏洞傳播組件漏洞影響范圍分布圖Maven2,289個，經(jīng)2次傳播，6Maven94,72441145,8272,28964倍。從整體上看，開源組件生態(tài)中漏洞影響范圍遠超預期，組件間的依賴層級關系會導致組件之間漏洞存在傳播風險。因此，要保證軟件的安全風險控制，應通過自動化的手段識別軟件工程中的組件成分，梳理組件間的依賴關系；在已知成分清單基礎上對組件漏洞風險實施管控；同時，還要對已知成分進行動態(tài)監(jiān)控，建立組件生態(tài)的漏洞威脅警報，在動態(tài)變化中將安全漏洞風險降到最低。四、開源文件潛在漏洞風險傳播分析開源項目中往往存在相互引用關系，同一開源文件可能被多個項目所引用或包含?？紤]到開源文件這一特性，本研究選取已公開漏洞17,5701317,570發(fā)現(xiàn)十七：超80%漏洞文件在開源項目具有同源文件圖22漏洞文件同源占比分布17,57080.35%14,1183,452個文件未找到同源文件。54倍圖23漏洞文件在開源項目中傳播范圍分布14,118766,877個542,410,476個開源項目171案例分析LibTIFF項目中tif_next.c2個中危漏洞CVE-2015-1547CVE-2015-8784tif_next.c237tif_next.c1000tif_next.c26大托管平臺引用tif_next.c表26大托管平臺tif_next.c文件的同源開源項目舉例托管平臺開源項目名稱版本號同源文件路徑GitHubreactos/reactos14backups/ros-branch-0_4_2@73087見注釋15Giteemirrors-opencv162.4.10見注釋17Gitlablimbo18v2.2.1-Limbo-armv7-hf見注釋19Bitbucketxray20FirstAddedTBB見注釋21Sourceforgewxhaskell22wxInstall-Abriline-32-0.1見注釋23CodePlexcasaengine24master見注釋25從整體上看，本次研究發(fā)現(xiàn)相同的文件被多個開源項目所引用的現(xiàn)象遠多于預期?？紤]到漏洞利用的復雜性，本研究團隊認為這些結構一致的同源文件具有潛在漏洞風險，漏洞是否能真正的被利用，還需要深入研究。五、開源安全風險建議開源生態(tài)帶來的正面效應已在信息經(jīng)濟生活中發(fā)揮重要影響，如何在安全可控的情況下使用開源，已成為開源生態(tài)的關鍵任務。開源安全風險防范措施應貫穿軟件開發(fā)的整個生命周期。本報告給出了如下六點建議：（一）建立開源管理領導組織。隨著軟件開發(fā)過程中開源軟件的使用越來越多，開源軟件事實上已經(jīng)成為了軟件開發(fā)的核心基礎設施。開源軟件由于其特殊性，從軟件供應鏈視角看，將橫跨采購、選型設計、研發(fā)編碼、運維交付等多個環(huán)節(jié)，需要跨組織、跨部門協(xié)同管理。具備條件的企業(yè)、機構建議設立開源管理辦公室或領導小組，全面學習開源生態(tài)知識，了解開源生態(tài)運作機制，開展開源風險意識培訓，強化開源風險管控手段。（二）識別開源成分。開源軟件全面滲透至軟件供應鏈體系中，需準確識別軟件中的開源成分（包括開源源代碼成分、開源二進制成分、引用依賴的開源組件成分等），形成開源成分清單和圖譜，做到對軟件開源成分的可知可控。同時精確繪制開源組件依賴鏈條，防止安全風險隨著開源組件依賴鏈條的逐層傳播，是進行開源安全風險防范的基礎。（三）修復已知開源漏洞。已知軟件的開源成分清單和圖譜，明確開源成分及依賴鏈條后，通過相關工具檢測或知識庫查詢，可有效識別已知開源漏洞。結合項目實際情況進行漏洞修復，降低軟件安全明確相關應急響應機制，最大程度降低風險。已知的開源漏洞修復，相較于代碼安全審計，往往是將帶有漏洞的組件升級至最新或較安全的組件版本，操作簡單，易于實施，是一個投入產(chǎn)出比較高的風控措施。（四）建立開源威脅情報體系。軟件安全是動態(tài)發(fā)展的，開源軟（共同貢獻分享。開源威脅情報呈現(xiàn)無統(tǒng)一組織，散落在互聯(lián)網(wǎng)海量信息中。需建立對已知開源成分及依賴鏈條漏洞威脅情報的實時監(jiān)控跟蹤機制，搜集多維度多渠道的開源威脅情報，并針對企業(yè)、機構已有的開源成分清單和圖譜，在第一時間內將有效的開源威脅情報同步給（五）棄用過老的開源組件和版本，及時安全更