《新思科技（Synopsys）：2023年開源安全和風險分析報告（19頁）.pdf》由會員分享，可在線閱讀，更多相關《新思科技（Synopsys）：2023年開源安全和風險分析報告（19頁）.pdf（19頁珍藏版）》請在三個皮匠報告上搜索。

1、簡介12023開源安全和風險分析報告22023年開源安全和風險分析報告|2023 Synopsys,Inc.目錄簡介.3關于2023年開源安全和風險分析報告與新思科技網絡安全研究中心(CyRC).3概述.42022回顧.4行業概況.5術語 .6漏洞與安全性.7開源漏洞與安全性.7戈爾迪之結：開源軟件風險與供應鏈安全.8行業漏洞情況.9五年回顧.11許可.13開源許可.13了解許可證風險 .14開源代碼的維護.15開源代碼開發者維護概況 .15已知風險之外的風險.16開源代碼使用者維護概況 .17結語.18“信任，但要驗證”.18信任的問題.18通過SBOM進行驗證.1832023年開源安全和風

2、險分析報告|2023 Synopsys,Inc.簡介關于2023年開源安全和風險分析報告與新思科技網絡安全研究中心(CyRC)歡迎閱讀2023年第8版 開源安全和風險分析(OSSRA)報告。今年的OSSRA提供了新思網絡安全研究中心（CyRC）對商業軟件中的開源安全性、合規性、許可和代碼質量風險當前狀態的年度深入研究。我們分享了這些調查研究結果，以幫助安全、法律、風險和開發團隊更好地了解安全和許可證風險狀況。新思科技網絡安全研究中心(CyRC)為本報告提供了數據。該中心的任務是發布安全建議和調研報告，以幫助企業更好地開發和使用安全的高質量軟件。OSSRA年度報告代表CyRC從上一年數據中得出的

3、結論。因此，我們的2023年報告顯示的是2022年的數據。在2022年，CyRC對來自17個行業的超1,700個商業代碼庫的匿名調查結果進行了研究。我們的審計服務團隊每年為客戶審計數千個代碼庫，主要目的是識別并購(M&A)交易中一系列的軟件風險。盡管2022年經濟前景不明朗，科技領域的并購也相應放緩，但審計代碼庫的數量依然可觀。近20年來，新思科技Black Duck軟件組成分析(SCA)產品團隊和CyRC審計服務團隊一直在幫助世界各地的安全、開發和法律團隊加強其項目的安全性和許可證合規。Black Duck SCA使企業能夠識別和跟蹤開源代碼，并在其現有的開發環境中集成自動化的開源實施策略。

4、Black Duck審計通常在并購交易背景下進行，涵蓋軟件風險的方方面面。該審計還提供全面的、高度準確的軟件物料清單(SBOM)，涵蓋企業應用中的開源代碼、第三方代碼、Web服務和應用編程接口(API)。審計服務團隊依靠Black Duck KnowledgeBase知識庫的數據識別潛在的許可證合規與安全風險。該知識庫由CyRC創建、管理和多年積累，存儲了來自2.8萬多個開源代碼倉庫超610萬個開源組件的數據。無論您經營什么行業，或者您在企業安全和風險管理方面扮演什么角色，OSSRA持續強調，日益普及的開源軟件推動著業務發展，同時也存在無法進行有效管理的困難。我們每年都在強調，開源軟件是我們今

5、天所依賴的每個應用程序的基礎。因此，有效地識別、跟蹤和管理開源代碼對于成功的軟件安全計劃至關重要。本報告提供了關鍵的建議和洞察，以幫助開源軟件的開發者和使用者更好地了解開源生態系統以及如何對其進行負責任的管理。無論您經營什么行業，OSSRA持續強調，日益普及的開源軟件推動著業務發展，同時也存在難以進行有效管理的困難。42023年開源安全和風險分析報告|2023 Synopsys,Inc.概述 包含開源代碼的庫的百分比 代碼庫中開源代碼的百分比 至少包含一個漏洞的代碼庫的百分比 包含高風險漏洞的代碼庫的百分比54%的代碼庫存在許可證沖突54%31%的代碼庫包含沒有許可證或使用定制許可證的開源代碼

6、31%89%的代碼庫包含至少已過期四年的開源代碼89%91%的代碼庫包含兩年內未更新的組件91%2022年審查的1,703個代碼庫中，87%包括安全和運營風險評估。96%76%84%48%201920202021202220180408020601002023年開源安全和風險分析報告|2023 Synopsys,Inc.5按行業劃分的開源代碼使用情況 包含開源代碼的代碼庫的百分比 代碼庫中開源代碼的百分比航空航天、汽車、運輸和物流計算機硬件和半導體 醫療保健、健康科技和生命科學互聯網和軟件基礎架構能源與清潔科技金融服務和金融科技互聯網和移動應用大數據、AI、BI和機器學習 制造業、工業和機器人

7、零售和電子商務虛擬現實、游戲、娛樂和媒體物聯網營銷科技電信和無線概述教育科技201820192020202120221000204060802018201920202021202210002040608020182019202020212022100020406080201820192020202120221000204060802018201920202021202210002040608020182019202020212022100020406080網絡安全201820192020202120221000204060802018201920202021202210002040608020

8、18201920202021202210002040608020182019202020212022100020406080201820192020202120221000204060802018201920202021202210002040608020182019202020212022100020406080企業軟件/SaaS201820192020202120221000204060802018201920202021202210002040608020182019202020212022100020406080201820192020202120221000204060802023年

9、開源安全和風險分析報告|2023 Synopsys,Inc.6概述術語 代碼庫 組成應用程序或服務的代碼及相關的庫。二進制分析 靜態分析的一種，用于在無法訪問源代碼時識別應用程序的內容。Black Duck Security Advisory(BDSA)由CyRC安全研究團隊研究和分析的關于開源漏洞的詳細、及時、一致的信息。BDSA為新思科技客戶提供了開源漏洞的早期預警通知和升級/修補指導。Black Duck Security Advisory 的漏洞庫超越了美國國家漏洞數據庫(NVD)，提供增強的數據、更為完整和準確的信息，從而用戶能夠獲得漏洞預警和全面的洞察。BDSA提供當天通知、實際可

10、操作的漏洞消減指導和變通解決方案信息、嚴重性評分和參考信息等。軟件組件 開發人員可以添加到其軟件中的預先寫好的代碼。軟件組件可以是日歷函數等實用程序，也可以是支持整個應用程序的綜合軟件框架。依賴項 當某個軟件組件被其他軟件使用時，也就是說當這些軟件依賴于該組件時，該軟件組件就變成了依賴項。任何給定的應用程序或服務都可能有許多依賴項，而這些依賴項本身也可能依賴于其他組件。開源許可證 當軟件中使用開源組件或開源組件的代碼片段時，用于闡述最終用戶義務的一組條款和條件，包括如何使用和重新分發該等組件。開源許可證基本上分為兩類。寬松型許可證(Permissive License)寬松型許可證基本不設任何

11、使用限制。一般來說，此類許可證的主要要求是原始代碼的歸屬權屬于其原始開發者。著作權許可證(Copyleft license)此類許可證通常涵蓋互惠義務，規定代碼的修改和擴展版本必須在與原始代碼相同的條款和條件下發布，并且有改動的源代碼必須按要求提供。商業實體對在其軟件中使用著作權許可證的開源代碼十分謹慎，因為它的使用可能會帶來整個代碼庫的知識產權(IP)問題。軟件組成分析(SCA)一種用于自動化開源軟件管理流程中的應用程序安全工具。SCA工具可以集成在軟件開發生命周期中，用于識別代碼庫中使用的開源代碼，提供風險管理和緩解建議，并執行許可證合規驗證。軟件物料清單(SBOM)代碼庫中的軟件組件和依

12、賴項的全面目錄清單，通常由軟件組成分析工具生成。正如美國國家電信與信息管理局(NTIA)所說，“SBOM應包括一個機器可讀的軟件組件和依賴項清單，以提供關于這些組件及其層次關系的信息?！庇捎赟BOM旨在跨公司和社區共享，因此，具有一致的格式(即人可讀和機器可讀)和一致的內容至關重要。美國政府指南中，目前將兩種格式指定為已被批準的標準格式：Software Package Data Exchange(SPDX)和CycloneDX。第14028號行政命令(EO 14028)2021年5月，美國總統拜登發布了一項名為“改善國家網絡安全狀況”(Improving the Nation s Cyber

13、security)的命令，指示各聯邦政府機構為與聯邦政府開展業務的企業制定軟件安全指南。該命令中包括一個時間表，里面列出了截至本報告撰寫之際不要求強制履行合同義務的各項活動。然而，盡管不存在硬性要求，但該命令已經促使很多企業重新審查其安全實踐，并嚴格審查其軟件安全風險水平。EO 14028大力提倡使用軟件物料清單（SBOM），因為這可以促進軟件生產者和消費者之間軟件供應鏈信息的交流。Apache Log4j2漏洞（BDSA-2021-3887和CVE-2021-44228等）開源組件ApacheLog4J2（通常稱為Log4j）在Java社區中用于實現應用程序日志記錄。Log4j中已經發現了多

14、個漏洞，包括遠程代碼執行(RCE)、拒絕服務和LDAP漏洞。0-day漏洞 不為軟件供應商或作者（他們往往對修復感興趣）所知曉的漏洞，或者雖已知曉卻尚無補丁來修復的漏洞。OpenSSL漏洞2022年11月，常用的開源命令行工具OpenSSL針對兩個嚴重漏洞（CVE-2022-3602和CVE-2022-3786）發布了官方警告。這兩個漏洞的嚴重程度后被降為“高級”。它們是證書驗證過程中存在的緩沖區溢出（Buffer overflow/Buffer overrun）漏洞。利用前一個漏洞可能導致系統崩潰，并有可能導致任意代碼執行；利用后一個漏洞則可能帶來內存損壞問題。緩沖區溢出（Buffer ov

15、erflow/overrun）漏洞緩沖區是應用程序執行期間的臨時內存區域。當寫入緩沖區的數據量超過緩沖區的容量時，就會發生緩沖區溢出，這可能會導致系統崩潰、內存問題或其他意外行為。攻擊者可以利用該漏洞實施篡改文件和訪問敏感信息等行為。72023年開源安全和風險分析報告|2023 Synopsys,Inc.漏洞與安全性開源漏洞與安全性在Black Duck審計服務團隊今年分析的1,703個代碼庫中，有96%包含開源代碼。在所有的被測代碼庫中，76%為開源代碼庫，這意味著在我們研究的所有代碼庫中，76%為開源代碼庫。今年，給定應用程序中的開源組件的平均數量為595個。如果只有區區幾個組件，則手工監

16、控其安全漏洞并對其執行安全維護活動也許是可行的，但在這種規模下，開展此類活動將變得舉步維艱，幾乎不可能實現，因此需要使用SCA之類的自動化解決方案。84%的代碼庫包含至少一個已知開源漏洞，比2022年版的OSSRA報告增加了近4%。我們檢查的代碼庫中有48%包含高風險漏洞，僅比去年減少了2%。高風險漏洞是指已被主動利用、已有POC（證明漏洞存在）記錄、或已被歸類為遠程代碼執行的漏洞。漏洞和高風險漏洞 包含開源代碼的代碼庫的百分比 包含至少一個漏洞的代碼庫的百分比 包含高風險漏洞的代碼庫的百分比包含漏洞的組件包含易受攻擊組件的代碼庫的百分比 47%jQuery 31%Lodash 23%Boot

17、strap(Twitter)11%jackson-databind 10%Spring Framework 6%Netty Project 5%XStream 5%Apache Tomcat*.4%PHP*.1%Linux Kernel*包含高風險漏洞的組件所有的Black Duck審計都會檢查開源許可證的合規性，但客戶可以自行決定放棄該審計的漏洞/運營風險評估部分。2023年，Black Duck審計服務團隊共進行了1,703次審計。在這些審計中，87%的客戶（1,481家）選擇了安全和運營風險評估。在2023年的OSSRA報告中，“開源漏洞與安全性”以及“開源代碼的維護”部分的數據基于包含

18、風險評估的 1,481個代碼庫，而“許可”部分的數據則基于全部的1,703個代碼庫。020406080100201820222021202020192023年開源安全和風險分析報告|2023 Synopsys,Inc.8漏洞與安全性戈爾迪之結：開源軟件風險與供應鏈安全新思科技與Enterprise Strategy Group共同發起的一份最新研究報告 一往無前：GitOps與安全左移(Walking the Line:GitOps and Shift Left Security)探討了市場關注的問題以及企業如何應對當前的安全挑戰。73%的受訪企業表示，近期的軟件供應鏈攻擊促使他們“大大加強了

19、對開源軟件、容器鏡像和第三方軟件組件的安全保護”。令人不安的是，34%的受訪者還表示，他們在過去12個月內經歷過“利用開源軟件已知漏洞發起的攻擊”。如今，任何稍微涉及軟件安全的人都可能會關心軟件供應鏈。軟件供應鏈安全問題頻繁出現在新聞報道中，并已觸及各行各業的各個組織。但是，距離拜登總統簽發第14028號行政命令(EO 14028)已近兩年，各組織仍然未能解決供應鏈基礎問題，包括了解其軟件供應鏈的廣度、對其所依賴的軟件建立可視性、以及滿足其分發和銷售的軟件日益增長的透明度要求。那么，該如何應對呢？保護軟件供應鏈的第一步是管理應用程序中的開源代碼和第三方代碼。如果您不能有效地管理并確保開源軟件及

20、第三方軟件的安全性，那么，您為了保護供應鏈而開展的所有其他工作都將徒勞，或者坦白說，根本無濟于事。管理這類軟件，您需要完全了解貴組織對它們的依賴情況，并能夠針對這些組件引入的風險輕松收集相關信息。一旦確定了風險，您將需要借助適當的工具和實踐對其進行管理、確定優先級并進行補救。此外，將已識別的所有風險悉數告知關鍵利益相關者也很重要，只有這樣他們才能了解這些風險，為風險管理活動和計劃提供支持。再者，所有這些能力和實踐均應構建到現有的開發管道中，并盡可能自動執行。聽起來很復雜？因為事實就是如此。供應鏈的最終產品及其用戶都會受到其創建過程中涉及的每個組件、人員、活動、材料和程序的影響。只有獲得對供應鏈

21、及其眾多相關元素的完全可視性，您才能開始保護它。而這種可視性則是從驗證您是否真正安全開始的。俄羅斯的古老諺語“要信任，但要驗證”用在這里再合適不過了；管理開源軟件和第三方軟件的前提是您已經驗證了其安全性。如果不進行驗證，就相當于您毫無根據地信任供應鏈中最薄弱的環節。到2025年，全球將有超過45%的組織遇到軟件供應鏈攻擊問題Gartner+45%那么，該如何應對呢？保護軟件供應鏈的第一 步是管理應用程序中的開源代碼和第三方代碼。開源軟件風險和供應鏈安全密不可分。2023年開源安全和風險分析報告|2023 Synopsys,Inc.9漏洞與安全性 包含開源代碼的代碼庫的百分比 代碼庫中開源代碼的

22、百分比 包含漏洞的代碼庫的百分比按行業劃分的漏洞情況我們看到，包含開源代碼的代碼庫占比逐年上升。今年，即便是占比最低的行業（制造業、工業和機器人），也有92%的代碼庫中包含開源代碼。然而，開源與漏洞的密切相關令我們感到不安，尤其是航空航天、汽車、運輸和物流行業。我們在該領域審查的所有代碼庫中都包含開源代碼，且開源代碼占到代碼總數的73%。63%的代碼庫中包含高風險漏洞（嚴重程度為7分或更高）。能源與清潔科技領域的情況基本相同，其中78%的代碼為開源代碼，69%的代碼中包含高風險漏洞。該領域中包含開源代碼的代碼庫占比為95%。其他行業雖然程度較輕，但情況大致相同，這給安全團隊敲響了警鐘。我們今年

23、審查的所有代碼庫中幾乎都包含開源代碼；開源代碼幾乎出現在各行各業的所有代碼庫中，并且包含企業未能修補的大量已知漏洞，這些漏洞很容易被利用，著實令人感到不安。請切記，盡管開源本身不會帶來任何固有的風險，但如果管理不善，就會帶來風險。20182019202020212022020406080100按行業劃分的開源代碼和安全漏洞情況航空航天、汽車、運輸和物流計算機硬件和半導體網絡安全教育科技201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100大數據、AI、BI和

24、機器學習2018201920202021202202040608010020182019202020212022020406080100物聯網制造業、工業和機器人營銷科技零售和電子商務電信和無線虛擬現實、游戲、娛樂和媒體2018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100能源與清潔科技企業軟件/SaaS 金融服務和金融科技醫療保健

25、、健康科技和生命科學互聯網和軟件基礎架構互聯網和移動應用2018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002023年開源安全和風險分析報告|2023 Synopsys,Inc.10漏洞與安全性CVEs/BDSAs高風險CVE/BDSA 具有10種最常見CVE/BDS

26、A之一的代碼庫的百分比BDSA-2020-0964(CVE-2020-11023)BDSA-2014-0063BDSA-2021-3651CVE-2019-5428BDSA-2021-0392(CVE-2021-23337)BDSA-2019-1138(CVE-2019-11358)BDSA-2015-0567BDSA-2017-2930(CVE-2015-9251)BDSA-2021-0375(CVE-2020-28500)BDSA-2020-3839 具有10種最常見的高風險CVE/BDSA之一的代碼庫的百分比BDSA-2015-0753(CVE-2015-6420)CVE-2020-80

27、22CVE-2021-41720CVE-2018-1000613CVE-2017-7657CVE-2021-31597CVE-2016-1000027CVE-2021-3749CVE-2017-1000487BDSA-2018-4597(CVE-2018-14719)漏洞嚴重性評分新思科技漏洞嚴重性評分系統在確定分數時收集大量的影響評分的變量信息。這些分數是我們Black Duck Security Advisory(BDSA)的一部分。BDSA利用FIRST.org規定的CVSS評分系統，以確保漏洞嚴重性分數與CVSS相一致，但新思科技的漏洞嚴重性分數是由CyRC給出的，而不是簡單地模仿NV

28、D發布的評分。在評分時，BDSA會考慮可利用性等諸多因素，這有助于確保最精確的CVSS分數。此外，不同于NVD等評分系統，BDSA在評分時還會考慮時間指標。我們的目標是盡可能提供最精細、最準確的評分，以幫助客戶合理分配活動的優先級。2023年開源安全和風險分析報告|2023 Synopsys,Inc.11漏洞與安全性五年回顧今年，為了發現顯著趨勢，我們對OSSRA報告數據進行了五年回顧。我們的調查結果如下。調查結果1.開源代碼的采用因行業而異我們每年都會報告開放源代碼的持續增長和采用情況，但通過五年回顧，我們發現不同的垂直領域在開源代碼的采用方面存在較大差異。正如我們之前提到的那樣，今年，所有

29、的垂直領域都有92%以上的代碼庫中包含開源代碼。然而，當我們查看過去五年中開源代碼在代碼庫中的總占比時，發現了巨大的不同。2018到2022年間，在教育科技領域的審計代碼庫中，開源代碼占比增長了163%；航空航天、汽車、運輸和物流領域增長了97%；制造業和機器人領域增長了74%。我們認為，開源代碼在教育科技領域的這一爆炸性增長是新冠疫情導致的；隨著教育被推到線上，軟件成為教育的關鍵基礎，因此這種增長是合理的。由于開源是免費的（盡管它必須得到妥善管理），因此，它對希望在短時間內做出重大改進但預算緊張的行業特別有吸引力。許多教育科技系統都是由志愿者自行開發和維護的，因此，開源很可能成為新興教育科技

30、技術的基礎。通過五年回顧，我們發現開源代碼在航空航天、汽車、運輸和物流領域的采用速度相對較慢（但去年突然增長了22%）可能是這些垂直行業受到嚴格監管的緣故。在過去，由于這些行業中的組織缺乏足夠的資源和能力來有效保護開放源代碼，因此會更加刻意地避免使用開源代碼。包含開源代碼的代碼庫的百分比 代碼庫中開源代碼的百分比 包含高風險漏洞的代碼庫的百分比按行業劃分的開源和高風險漏洞大數據、AI、BI和機器學習航空航天、汽車、運輸和物流計算機硬件和半導體網絡安全教育科技201820192020202120220204060801002018201920202021202202040608010020182

31、0192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100企業軟件/SaaS能源與清潔科技金融服務和金融科技醫療保健、健康科技和生命科學互聯網和移動應用互聯網和軟件基礎架構20182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100201820192020202120220204

32、0608010020182019202020212022020406080100制造業、工業和機器人物聯網營銷科技零售和電子商務電信和無線虛擬現實、游戲、娛樂和媒體2018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002023年開源安全和風險分析報告|2023 Syno

33、psys,Inc.12漏洞與安全性新思科技政府與關鍵基礎設施項目前主管Joe Jarzombek對這些數字發表了另一種看法。Jarzombek指出：“軟件質量不佳所帶來的技術債務阻礙了新功能的交付。與其他工業領域和政府部門一樣，國防工業基地將大部分時間和精力花費在糾正技術債務上，而不是開展主動的、創造性的或預防性的工作上?！彼又赋?，近期的網絡安全成熟度模型認證”有助于“許多行業減輕與數據保護相關的安全顧慮”，從而使這些行業提高了創新能力和敏捷性。也就是說，開源代碼的采用速度緩慢及其所提供的創新、速度和靈活性導致過時的做法得以繼續。但技術債務和繁瑣的法規正在慢慢讓位，推動開源代碼得到更廣泛地

34、使用。調查結果2.企業未修復高風險漏洞當我們按行業比較高風險漏洞的發生率時，我們看到所有行業都存在不同程度的高風險漏洞。自2018年以來，高風險漏洞在營銷科技領域至少增加了42%；在零售和電子商務領域更是猛增557%，著實令人擔憂。讓我們再次回到航空航天、汽車、運輸和物流領域（高風險漏洞在這個垂直領域大幅增加了232%），該領域是否根本不需要降低風險呢？漏洞修復的一個關鍵驅動因素是漏洞利用的可能性和潛在影響。這些行業使用的大部分軟件和固件都在封閉系統中運行，因此能夠降低漏洞被利用的可能性，從而修補漏洞的緊迫性不高。此外，這些行業的漏洞還可以通過無需更新組件的其他方式進行緩解。如果我們考慮到軟件

35、在該垂直領域的部署、分發和操作方式，則能夠為存在如此大量的高風險漏洞找到另一種可能的解釋。嵌入式軟件和固件通常用于無法訪問網絡的硬件上，這意味著更新包無法在網絡中輕松自動地發布，就像SaaS應用一樣。當安裝補丁意味著必須下載并安裝更新版本，或將U盤插入設備，則補丁的安裝頻率勢必有所減少，從而導致未修補的漏洞有所增加。此外，這個領域的軟件采用了不同的標準與實踐，這與獨立軟件供應商和公司構建企業級軟件及SaaS應用的標準不同。這種區別或許是該垂直領域無法解決高風險開源軟件漏洞問題的原因之一。在物聯網(IoT)領域，我們看到了不同的情況。自2020年以來，我們掃描的所有代碼庫中都包含開源代碼，且每個

36、代碼庫中的開源代碼總量也在增加；開源代碼占比自2018年以來增長了35%，今年的總占比高達89%。IoT是開源優勢的絕佳體現；IoT公司面臨著快速開發新軟件的巨大壓力，例如，Ring、Amazon和Nest迫切需要為其提供的智能設備開發新軟件。在競爭白熱化的行業，開源可以讓企業快速行動起來。如果沒有開源，他們將不可能跟上飛速發展的步伐。但問題在于開源代碼中存在安全漏洞。自2018年以來，IoT領域的高風險漏洞增加了130%，今年，53%的審計應用中包含高風險漏洞，是我們調查中高風險漏洞占比較高的領域之一。當考慮到IoT設備的功能和作用時，這一點尤其令人擔憂；我們將許多日常生活事務交給這些設備，

37、并認為它們天生安全。IoT設備可以根據我們設置好的時間表自動開燈，因此這些設備存儲著我們何時在家以及何時外出的數據?？梢耘臄z家里圖像的攝像頭、大門上的智能鎖以及嬰兒監控器等等，都存在安全隱患。高風險漏洞五年增幅最大的行業+317%計算機硬件和半導體+277%制造業、工業和機器人+236%大數據、AI、BI和機器學習+232%航空航天、汽車、運輸和物流+557%零售和電子商務 10%增長率132023年開源安全和風險分析報告|2023 Synopsys,Inc.許可開源許可Black Duck審計服務團隊發現，2022年審計的代碼庫中有54%包含存在許可證沖突的開源代碼，比上一年略微增加了2%，

38、但相對2020年的65%仍然大幅減少了17%。Creative Commons ShareAlike 3.0(CC BY-SA 3.0)許可證是今年許可沖突的最主要的原因；22%的審計代碼庫存在與該許可證相關的某種形式的沖突。CC BY-SA 3.0許可證沖突數據揭示出開源許可證方面經常被忽視的一個問題。商業和開源開發人員經常將代碼片段、函數、方法和操作代碼片段引入到他們的軟件中，通常稱為“依賴項”（因為整個軟件都依賴于該代碼）。因此，開源項目通常涉及一些子組件，這些子組件與整個項目在不同的許可證下授予許可，其條款和條件也不同于主許可證中的條款和條件，從而引發沖突。在Black Duck審計服

39、務團隊發現的許可證沖突中，85%涉及來自Stack Overflow的內容 Stack Overflow是用于查找和共享技術知識的在線問答平臺?？紤]到Stack Overflow廣受歡迎，并且CC BY-SA 3.0許可證在分布式和SaaS部署模式中都是主要的沖突來源，因此，Stack Overflow成為最大的沖突來源也就不足為奇了。我們看到各行各業的開源許可證沖突均大幅減少。去年，計算機硬件和半導體行業有93%的代碼庫存在開源許可證沖突。這一數字在今年降至75%?？傮w而言，我們看到各行各業均取得了類似的改進；今年，開源許可證沖突占比最高的垂直領域是物聯網領域，為78%。開源許可證沖突的這一

40、總體改進可能是經濟不確定性和人們對供應鏈風險的普遍焦慮所致。包含開源代碼的代碼庫的百分比 代碼庫中開源代碼的百分比 包含許可證沖突的審計代碼庫的百分比按行業劃分的開源和許可證沖突航空航天、汽車、運輸和物流大數據、AI、BI和機器學習計算機硬件和半導體網絡安全教育科技2018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100能源與清潔科技

41、企業軟件/SaaS金融服務和金融科技醫療保健、健康科技和生命科學互聯網和軟件基礎架構互聯網和移動應用201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100物聯網制造業、工業和機器人營銷科技零售和電子商務電信和無線虛擬現實、游戲、娛樂和媒體2018201920202021

42、202202040608010020182019202020212022020406080100201820192020202120220204060801002018201920202021202202040608010020182019202020212022020406080100201820192020202120220204060801002023年開源安全和風險分析報告|2023 Synopsys,Inc.14l許可 包含具有10種最常見沖突之一的許可證的代碼庫的百分比 存在許可沖突的代碼庫的百分比 包含沒有許可證或定制許可證的開源代碼的代碼庫的百分比許可證沖突許可問題Creati

43、ve Commons Attribution ShareAlike 3.0Apache License 2.0GNU Lesser General Public License v2.1 or laterGNU General Public License v3.0 or laterEclipse Public License 1.0Creative Commons Attribution ShareAlike 4.0Creative Commons Attribution 3.0GNU General Public License v2.0 or laterGNU Lesser Genera

44、l Public License v3.0 or laterMozilla Public License 2.0在43%的審計代碼庫中使用在90%的審計代碼庫中使用在34%的審計代碼庫中使用了解許可證風險 在美國和許多其他地方，創造性的工作（包括軟件）默認受專有版權的保護。未經創作者/作者以授權許可證的形式明確允許，任何人對該等軟件的使用、復制、分發或修改均不合法。即使最友好的開源許可證也會規定用戶在使用軟件時需要承擔的義務。當代碼庫中包含的開源代碼許可證與該代碼庫的總體許可證存在沖突時，就可能存在潛在的許可證風險。GNU通用公共許可證(GPL)是應用于開源項目的最常見的著作權許可證。如果商用

45、閉源軟件中包含在GPL下授予許可的代碼，就會產生沖突。在2022年審計的代碼庫中，1/3的代碼庫使用了沒有可識別許可證或具有定制許可證的代碼，比去年增長了55%。這一結果可能是兩個原因導致的。首先，這可能是因為開發人員手動將代碼片段或部分組件添加到代碼庫中。這樣做的時候，開發人員通常無法將代碼片段的相關許可證一并添加。其次，這可能僅僅是因為項目維護人員制訂的許可證和條款偏離了已知標準許可證。未能充分理解許可證的含義雖然看似沒有問題，但可能會有風險，應盡量避免。在Github上，可以找到大量無許可證的項目代碼，開發人員已經公開了代碼，但是無論是在代碼中、.txt文件中、還是與項目相關的元數據中，

46、都沒有聲明許可。因此，GitHub中可能存在未經許可的代碼?；蛘?，開發人員可能會從博客或網站復制代碼，理所當然地認為這些公開提供的源代碼是可以隨意使用的。這種想法看似合理，但版權法卻不這么認為。此外，標準開源許可證的變體或定制版本許可證可能會對被許可方提出不必要的要求，并且要求對可能的知識產權問題和其他問題進行法律評估。例如，JSON許可證便是定制許可證的典型示例。JSON許可證基于寬松型MIT許可證，只不過添加了“該款軟件嚴禁用于惡意用途，僅限用于善意用途”的限制。該聲明的含糊不清導致“善意用途”和“惡意用途”成為很難界定的東西，許多律師都建議避免使用采用該等許可模式的軟件，尤其是在并購的情

47、況下。02040608020182022202120202019152023年開源安全和風險分析報告|2023 Synopsys,Inc.開源代碼的維護 包含過去兩年未進行任何更新的組件的代碼庫的百分比 包含至少已過期四年的開源代碼的代碼庫的百分比代碼庫的可持續性由開源代碼的開發者進行維護 按理說，開發人員應選擇由強大社區提供支持的開源組件。以Linux為例，來自數百個組織的數千名開發人員每天都在改進Linux。然而，在Black Duck審計服務團隊審查的1,481個含風險評估的代碼庫中(見第7頁),91%都包含過去兩年內未進行任何更新的開源代碼 在過去24個月中未開展任何功能升級、代碼改進

48、和安全問題修復活動。這可能意味著相關方不再對該項目進行維護，尤其是在小型項目的情況下。顧名思義，開源項目是由不確定數量的貢獻者和維護者共同努力的結果。這種結構使開源成為一種協作項目，但挑戰在于開展維護活動的貢獻者缺乏激勵。諸如Kubernetes之類的重要項目通?？梢垣@得良好的支持，但也有很多項目僅由少數幾個人進行維護。近期，有關開源項目的一篇評論性文章指出，“對于軟件所嚴重依賴的重要開源項目，大多數維護人員幾乎都沒有得到任何認可?！北M管Microsoft、RedHat和Google等部分企業已經制訂了適當的獎勵計劃來激勵開源項目的維護和參與，但絕大多數企業都沒有相應舉措。其結果是為我們每天依

49、賴的軟件提供動力的基礎性開源項目無人維護，有時一放就是數年。201820222021202020192023年開源安全和風險分析報告|2023 Synopsys,Inc.16開源代碼的維護版本控制問題 91%的代碼庫中包含非最新版本的組件 88%的代碼庫中包含過去24個月未進行任何更新且不是最新版本的組件 72%的代碼庫中包含過去24個月未進行任何更新但卻是最新版本的組件 15%的代碼庫中包含同一組件的10個以上版本例如，Twitter因放棄開源項目而在最近幾個月引起了巨大轟動。據Twitter前開源負責人Will Norris稱，Twitter已經“放棄了開源開發”。他表示：“在Twitte

50、r從事開源工作的大多數關鍵人物都已經離開了。和我一起開發開源軟件的所有工程師都不在了。隨著新的管理層到位，新的業務優先事項出臺，曾經備受重視的開源項目開始降級，取而代之的是管理層新確定的重點項目?！睆闹T如Twitter的情況來看，因缺乏維護而帶來的后果是開源項目面臨的主要挑戰。如果項目沒人維護，輕則帶來技術債務，重則導致安全風險。已知風險之外的風險除了被放棄的項目之外，還發現開源項目被惡意破壞的情況。對于供應鏈安全性，我們經常聽說某某組織發現并緩解了已知漏洞，但在供應鏈中引起關注的新形式的開源軟件風險又是什么呢？惡意開源軟件包、“抗議軟件”(protestware)、依賴混淆和誤植域名(typ

51、o-squatting)都對開源安全構成了令人擔憂的新威脅?；仡欉^去五年的泄密事件和重大漏洞，我們發現信任是通病。企業和最終用戶必須對其使用的軟件以及該類軟件的開發者和提供者給予一定程度的信任。簡單說，企業相信其供應鏈中的每個節點都有相應的安全和質量保障措施，這個假設無疑是危險的。新思科技與Consortium for Information and Software Quality聯合發起的名為 美國軟件質量差的代價(The Cost of Poor Software Quality in The US)的最新報告指出，勒索軟件、加密劫持、IoT和OT攻擊以及供應鏈攻擊是2022年最熱門的網

52、絡犯罪趨勢。這里的病根仍然是信任問題：我們相信開源代碼的維護人員和開發人員能夠發現并修復漏洞。我們相信開源貢獻者和我們擁有相同的想法和動機。遺憾的是，情況并非總是如此。請切記，開源項目會帶來已知漏洞之外的運營風險。因此，降低運營風險還需要預測未來威脅并采取措施加以防范。去年夏天，在npm（JavaScript運行時環境Node.js的默認包管理器）中發現了幾個能夠從嵌入在移動應用和網站的表單中獲取敏感數據的惡意軟件包。這些被下載了數千次的軟件包對其他受到信賴的常見軟件包進行域名誤植攻擊。這些軟件包的任何版本都應被認為是易受攻擊的和惡意的，如Icon-package、Ionicio和Ajax-l

53、ibs等。當您讀到這個例子時，您是否知道自己使用了npm？貴組織中的安全責任人是否對其進行了適當的檢查并能夠確保安全？如果不是，您可能有點過于輕信了。清楚地掌握項目的聲譽以及項目維護人員，這一點至關重要，因為他們開展這些活動的動機可能與您不同。惡意的維護人員可能會利用您對供應鏈的信任，在未經盡職調查的情況下將惡意代碼植入您的應用程序。2023年開源安全和風險分析報告|2023 Synopsys,Inc.17開源代碼的維護由開源代碼的使用者進行維護 在Black Duck審計服務團隊審計的1,481個包含風險評估的代碼庫中（見第7頁)，91%包含過時版本的開源組件。也就是說，尚未安裝最新的升級包

54、或補丁。他們不對軟件進行及時更新是情有可原的。DevSecOps團隊可能認為引入新版本會帶來意外后果，引入新版本產生的風險會超過由此帶來的任何好處。嵌入式軟件僅存在從外部來源引入的漏洞風險，因此風險最低。他們不對軟件進行及時更新也可能是因為時間/資源問題。由于構建和測試新代碼已經耗掉了許多團隊的全部精力，因此，除了最關鍵的問題外，對現有軟件進行更新可能會淪為較低優先級的事項。對于包含過時版本開源組件的91%的代碼庫而言，有很大一部分原因是因為DevSecOps團隊并不知道該開源組件的新版本已經可用，甚至根本不知道該組件的存在。企業最熟悉的通常是商業軟件，因為這些軟件的補丁和更新是自動推送的，所

55、以無需他們時刻關注組件更新情況。開源軟件的運作方式則完全不同。使用開源軟件意味著用戶有責任了解和控制組件的安全性和穩定性，并時刻關注組件的新版本和補丁。5%的被審計代碼庫中包含易受攻擊的Log4J版本5%11%的Java代碼庫中包含易受攻擊的Log4J版本11%修補失敗一年后，Log4Shell成為長尾漏洞的典型案例。盡管它受到了媒體關注，企業可以采取多種措施來確認其在代碼庫中的存在并進行補救，但在今年的審計中，我們發現其仍然存在。我們在5%的全部代碼庫和11%的Java代碼庫中發現了易受攻擊的Log4J版本。易受攻擊的Log4J版本之所以仍然存在，最有可能的原因是企業根本不知道它們的存在。L

56、og4J是基礎組件，導致其在許多情況下不會被安全團隊所看到?；A組件的修補工作也比表層的客戶端組件更復雜，因此，也許安全團隊知道它們的存在，只是還沒有進行修復。我們預計在未來幾年內，企業的基礎組件中會出現類似Log4J的漏洞。其原因首先是企業對開源的固有信任。他們認為開源軟件會像商業軟件一樣接受相同的安全檢查和保護。其次是因為企業無法識別其應用程序中的開源組件。這究竟是因為缺乏安全措施或安全能力，還是兩者兼而有之，目前尚不清楚。避免開源、專有和商業軟件帶來業務風險的第一步是對企業使用的所有軟件進行全面的盤點，無論其來自何處或是如何獲得的。擁有了這個完整的清單 值得信賴的SBOM 安全團隊才能規

57、劃出前進的道路，并制訂計劃來應對Log4Shell等新披露的安全漏洞帶來的風險。182023年開源安全和風險分析報告|2023 Synopsys,Inc.結語“要信任，但要驗證”“要信任，但要驗證”源于戰爭時期，在當今供應鏈攻擊大量涌入的背景下，這句話聽起來很奇怪。信任您使用和開發的軟件本身不是問題，無法驗證其是否接受了必要的安全分析才是問題。就連Gartner也在強調對供應鏈安全性進行充分驗證的緊迫性。據 Gartner預測，“到2025年，全球45%的企業將經歷軟件供應鏈攻擊，比2021增加三倍?！痹跀底謶馉幍谋尘跋?，企業如何才能為應對不可預測的情況做好充分準備呢？信任的問題如上文所述，盲

58、目地信任應用程序（或包含應用程序的代碼）的安全性可能會帶來毀滅性后果（即安全漏洞）。應摒棄這種內在的信任，像攻擊者一樣思考問題。攻擊者的本質是機會主義。其目標永遠是最平坦的攻擊路徑和最大的收益。如果不能保證軟件安全，您如何能夠確保不會成為攻擊目標呢？預測每一條攻擊路徑是不可能的，但圍繞著業務風險培養組織意識可以幫助企業減少威脅。今天，所有的企業都依賴軟件，這意味著他們都在從事軟件業務。一旦開始從這個角度考慮組織安全性，便能意識到盲目地相信軟件安全性是危險的。用戶有責任保護自己的軟件，無論是繼承的還是內部開發的。通過SBOM進行驗證 在對抗軟件供應鏈攻擊時，軟件物料清單(SBOM)應該是首選武器

59、。SBOM的概念源于制造業，典型的SBOM是一份詳細列出產品中所含全部項目的清單。這樣，一旦發現有缺陷的零部件，制造商便可以知道哪些產品受到了影響，并安排對其進行維修或更換。同理，維護準確的、最新的、列出開源組件的SBOM對于確保代碼的高質量、合規性和安全性是必要的。與制造業一樣，開源組件的SBOM允許用戶快速查明風險組件，并合理確定補救措施的優先級。全面的SBOM列出了應用程序中的所有開源組件，以及這些組件的許可證、版本和補丁狀態，是對供應鏈攻擊的完美防御。SBOM旨在幫助管理開源和第三方代碼的使用，提供對應用程序“成分”的可視性，并標準化信息通信方式。除作為文檔或記錄的基本功能外，我們還建

60、議用戶將SBOM視為一個管理系統或者工具、實踐和過程。用戶應該具備溯源意識來識別開源組件，然后將這些組件映射到漏洞數據。有效的開源管理有助于圍繞戰略和安全計劃的改進展開對話，以實現成功的供應鏈風險管理。2022年，96%的商業代碼中包含開源組件，因此，了解應用程序中使用的組件應該是任何現代DevSecOps項目的基本要求。隨著對業務風險和整體安全性的深入了解，您將不再相信自己是安全的，而是要親自驗證一下。相關讀物 白皮書：一往無前：GitOps與安全左移 Walking the Line:GitOps and Shift Left Security 文章：隨著杠桿收購的萎縮，年底前的并購活動似

61、乎萎靡不振（M&A Activity Looks Anemic Heading to Year-End as LBOs Shrivel）文章：全球并購市場2022年上半年放緩，但顯示出強勁跡象（lobal M&A market slows in 2022 first halfbut shows signs of strength）維基百科詞條：要信任，但要驗證（Trust,but verify）新聞稿：網絡安全成熟度模型認證(CMMC)計劃的戰略方向（Strategic Direction for Cybersecurity Maturity Model Certification(CMMC)

62、Program）網頁：改善國家網絡安全：NIST在2021年5月行政命令下的責任（Improving the Nation s Cybersecurity:NIST s Responsibilities Under the May 2021 Executive Order）采訪：Joe Jarzombek一對一采訪（1:1 with Joe Jarzombek）文章：Twitter放棄了開源開發（Twitter turns its back on open-source development）新思科技與眾不同新思科技提供的集成解決方案，可以改變您構建和交付軟件的方式，在應對業務風險的同時加速創新。與新思科技同行，您的開發人員可以在編寫代碼的時候快速兼顧安全。您的開發和DevSecOps團隊可以在不影響速度的情況下在開發管道中自動進行安全測試。您的安全團隊可以主動管理風險并將補救工作聚焦在對貴組織最重要的事情上。我們無與倫比的專業知識可以幫助您規劃和執行所需的安全計劃。只有新思科技能夠滿足您構建可信軟件的一切需求。2023 Synopsys,Inc.版權所有，保留所有權利。新思科技是Synopsys,Inc.在美國和其他國家/地區的商標。新思科技商標列表可在 獲得。本文提及的所有其他名稱均為其各自所有者的商標或注冊商標。2023年1月簡介19