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

1、2024年開源安全和風險分析報告您的開源供應鏈安全指南|2024年開源安全和風險分析報告|2目錄3|綜述3|關于OSSRA 20244|概述6|開源漏洞與安全性7|采取措施，防止漏洞進入您的軟件供應鏈8|10大漏洞中有8個可以追溯到同一個CWE9|為何某些BDSA沒有CVE10|按行業劃分的漏洞情況11|開源許可12|了解許可證風險14|防范AI編碼工具帶來的安全和知識產權合規風險15|影響開源風險的運營因素15|開源使用者需要改進維護實踐16|研究結果與建議17|創建安全的軟件開發框架17|了解代碼的構成18|術語18|貢獻者|2024年開源安全和風險分析報告|3本報告提供了一些建議，旨在幫

2、助開源軟件創建者和使用者負責任地管理軟件，特別是在保障軟件供應鏈安全的背景下。無論您是軟件的使用者還是提供者，您都是軟件供應鏈的一部分，需要保護您所使用的應用免受上游和下游風險的影響。在接下來的幾頁中，我們將探討：對開源安全的持續關注 為何說開發者需要改進以保持開源組件的持續更新 軟件供應鏈管理需要軟件物料清單(SBOM)如何防范AI編碼工具帶來的安全和知識產權合規風險近十年來，開源安全和風險分析(OSSRA)報告的主題一直是“您是否知道貴組織的代碼構成情況？”2024年，這個問題比以往任何時候都更加重要。如今，隨著開源的廣泛使用以及AI生成代碼的日益增多，使用第三方代碼構建的應用越來越多。如

3、果無法全面了解代碼的構成情況，無論是您自己，還是您的供應商和最終用戶，都將無法確定軟件可能包含的風險。保障軟件供應鏈的安全首先要知道代碼中包含哪些開源組件，并識別它們各自的許可證、代碼質量和潛在漏洞。關于OSSRA 2024歡迎閱讀2024年第9版開源安全和風險分析(OSSRA)報告。今年的OSSRA提供了新思網絡安全研究中心（CyRC）對商業軟件中的開源安全性、合規性、許可和代碼質量風險當前狀態的年度深入研究。我們分享這些調查研究結果，也是為了幫助安全、法務、風險和開發團隊更好地了解安全和許可證風險狀況。本報告使用的數據來自新思科技Black Duck審計服務團隊在2023年間對來自17個行

4、業的1,067個商業代碼庫的匿名調查結果。20多年來，審計服務團隊一直在幫助世界各地的安全、開發和法務團隊加強其項目的安全性和許可證合規。審計服務團隊每年為客戶審計數千個代碼庫，主要目的是識別并購(M&A)交易中一系列的軟件風險。該審計還提供全面、高度準確的軟件物料清單(SBOM)，涵蓋企業應用中的開源代碼、第三方代碼、Web服務和應用編程接口(API)。審計服務團隊依靠Black Duck KnowledgeBase知識庫的數據識別潛在許可證合規與安全風險。該知識庫由CyRC創建、管理并積累多年，存儲了來自3.1萬+開源代碼倉庫的780萬+開源組件。本OSSRA報告強調了開源代碼在軟件領域的

5、廣泛使用，以及管理不善可能帶來的風險。開源代碼是當今各種企業和個人應用程序的基石。有效地識別、跟蹤和管理開放源代碼，對于成功實施軟件安全計劃非常重要，也是提高軟件供應鏈安全水平的關鍵因素。綜述|2024年開源安全和風險分析報告|4概述經過風險評估的代碼庫中，14%包含10年以上的漏洞10年經過風險評估的代碼庫中，49%包含24個月內未更新的組件24月經過風險評估的代碼庫中，漏洞平均年齡為2.8年2.8年12月經過風險評估的代碼庫中，1%包含至少12個月內未被更新/修補的組件936個代碼庫經過風險評估2023年審查了1,067個代碼庫=10個數據庫經過風險評估的代碼庫中，84%包含漏洞經過風險評

6、估的代碼庫中，74%包含高風險漏洞84%74%經過風險評估的代碼庫中，91%包含了比最新版本落后10個以上版本的組件91%31%31%的被審代碼庫中包含沒有許可證或使用定制許可證的開源代碼53%53%的被審代碼庫中存在許可證沖突96%96%的被審代碼庫中包含開源代碼77%77%的開源代碼存在于被審的代碼庫中|2024年開源安全和風險分析報告|5圖1：本次研究審查的1,067個代碼庫，按行業劃分航空航天、汽車、運輸和物流69%100%虛擬現實、游戲、娛樂和媒體53%97%制造業、工業和機器人88%100%物聯網50%100%教育科技87%95%互聯網和移動應用64%100%大數據、AI、BI和機

7、器學習 70%96%零售和電子商務84%100%醫療保健、健康科技和生命科學85%88%計算機硬件和半導體74%100%金融服務和金融科技74%99%營銷科技87%100%能源與清潔科技83%91%互聯網和軟件基礎架構75%100%網絡安全78%95%電信和無線85%100%企業軟件/SaaS79%99%代碼庫中開源代碼的百分比包含開源代碼的代碼庫百分比|2024年開源安全和風險分析報告|6在Black Duck審計服務團隊為今年的OSSRA報告分析的1,067個代碼庫中，有96%包含開源代碼。所有被審查的源代碼和文件中，有77%來自開源代碼。今年，給定應用中的開源組件的平均數量為526個 證

8、明自動安全測試非常重要甚至絕對必要的實際證據。如果只有區區幾個組件，則手工測試也許是可行的，但在這種規模下，開展此類活動將變得舉步維艱，幾乎不可能實現，需要使用軟件組成分析(SCA)之類的自動化解決方案。與手工測試不同，自動安全測試可以快速且一致地執行，允許開發者在開發過程的早期階段識別問題，而不會影響交付進度或生產力。在包含風險評估的代碼庫中，84%包含至少一個已知開源漏洞。這些代碼庫有74%包含高風險漏洞，與2022年相比有顯著增長，2022年只有48%的代碼庫包含高風險漏洞。高風險漏洞是指已被主動利用、已有POC（證明漏洞存在）記錄或已被歸類為遠程代碼執行的漏洞。2022至2023年間，

9、高風險漏洞增加了54%（26個百分點），造成這種情況的原因可能不止一個。例如，有可能是經濟衰退和隨之而來的裁員導致用于尋找和修補漏洞的人員數量減少。此外，審查發現，91%的代碼庫包含了比最新版本落后10個或更多版本的組件，由此可以得出一個簡單的結論：絕大多數開源軟件使用者并沒有更新他們使用的組件。49%的代碼庫中包含過去24個月內未進行任何更新的組件，1%的代碼庫中包含至少12個月未被代碼維護人員更新/修補的組件。廣義上說，術語“維護者”指的是那些領導開源項目的貢獻者。他們可能是決定編譯或發布哪些部分源代碼的最終決策者，他們可能負責所有的代碼審查工作，并在其名下托管較小的項目，他們也可能對項目

10、的方向做出最終決定。他們的日常工作可能有所不同，但都包括審查拉取請求和其他提交、發布新版本的軟件、分類和處理安全修復以及社區管理和協調。大多數維護者都會努力使其參與的開源項目保持最新狀態。實際上，許多公司還專門雇人來維護公司軟件所依賴的開源項目。開源使用者也需要具備同樣的勤奮精神。他們需要時刻關注使用的版本，定期進行更新，并在使用開源軟件時注意軟件衛生 只從那些擁關于本次審計的說明所有的Black Duck審計都會檢查開源許可證的合規性，但客戶可以自行決定放棄該審計的漏洞/運營風險評估部分。2023年，Black Duck審計服務團隊共進行了1,067次審計。在這些審計中，88%的客戶（936

11、家）接受了安全和運營風險評估。在2024年的OSSRA報告中，“開源漏洞與安全性”以及“影響開源風險的運營因素”部分的數據基于包含風險評估的936個代碼庫，而“開源許可”部分的數據則基于全部的1,067個代碼庫。開源漏洞與安全包含高風險漏洞的代碼庫數量比去年增加了54%74%(2023)48%(2022)84%的代碼庫包含至少一個開源漏洞|2024年開源安全和風險分析報告|7有健康的維護者和貢獻者生態系統的項目下載?！巴ㄓ萌毕萘斜怼保–WE）和“公共漏洞和暴露”（CVE）是用于識別和分類軟件中安全缺陷和漏洞的常用列表。Black Duck Security Advisories(BDSA)是新

12、思科技的專有報告，旨在為客戶提供比國家漏洞數據庫(NVD)CVE通知更高水平、更及時、更詳細的信息。BDSA針對影響客戶SBOM中項目的漏洞提供可操作的建議和細節，以幫助確保他們全面了解開源代碼漏洞可能帶來的風險。如圖2所示，CWE-707是CWE 20、79、80、97、937的支柱。CWE-707涉及從上游組件讀取數據或發送數據到下游組件之前，沒有滿足安全需求。不能正確地凈化輸入可能會帶來跨站腳本(XSS)和SQL注入等漏洞利用攻擊。XSS是一種常見且危險的漏洞利用，與本報告中強調的大多數Top 10漏洞有關。當攻擊者利用網站中的漏洞發送通常使用JavaScript編寫的惡意的畸形代碼時，

13、就會出現跨站腳本攻擊。由于該輸入沒有正確凈化或轉義，導致攻擊者可以操縱原本值得信賴的主機執行惡意任務。不過，大多數XSS攻擊的最終目標并不是主機本身，而是Web應用的其他用戶。惡意腳本一旦注入，便可用來竊取敏感信息，如會話cookies。XSS不僅是十大漏洞之一，也是OWASP Top 10列表中的一個漏洞 該列表列出了10種最嚴重的Web應用安全風險。在其列表中，OWASP將XSS歸類為“A03:2021-注入”。XSS漏洞的普遍存在與組織機構日益依賴基于Web的應用與客戶交互有關。例如，許多電子商務公司、銀行、互聯網服務提供商和保險公司等組織機構都提供Web體驗來吸引客戶和合作伙伴。數據再

14、次清楚地表明，開發團隊需要改進開源組件更新工作，特別是在涉及jQuery等常用的開源組件時。使用更易受攻擊的舊版開源軟件，后果可能很嚴重。例如，在審計發現的十大漏洞中，排名第二的BDSA-2020-0686(CVE-2020-11022)是影響從jQuery 1.2到3.5.0之間所有版本的XSS漏洞。該漏洞允許將不可信來源的HTML傳遞給jQuery的一種DOM操作方法 即使經過了清理也不例外 并且可能執行不可信的代碼。這個問題在jQuery 3.5.0中得到了修復，但正如我們的數據所示，有三分之一的被測代碼庫仍在使用易受攻擊的jQuery版本。惡意數據可能被用來入侵系統，或者泄露密碼和信用

15、信息等敏感數據。正如前面提到的，跨站腳本是應用中最常見的漏洞之一，通常用于對瀏覽器中的各種語言解釋器（如HTML或JavaScript）發動代碼注入攻擊。jQuery并非天生不安全。事實上，它是一個維護良好的開源庫，擁有龐大的用戶、開發者和維護者社區。但是，隨著普及度的提高，問題緩解風險：安全地使用jQuery和其他常用開源軟件的技巧 在審計中現的10大開源組件中，全部都是使用JavaScript編寫的。審計中發現的大部分漏洞也與JavaScript庫相關，尤其是過時版本的jQuery JavaScript庫中的漏洞。使用最新版本的jQuery。正如本報告所示，jQuery的舊版本通常都存在安

16、全漏洞?？紤]訂閱安全咨詢服務，如Black Duck Security Advisories，以獲取最新的漏洞信息。jQuery時不時就會出現新的安全漏洞。使用安全的編碼框架來幫助您識別并避免代碼中的潛在安全漏洞。使用自動安全測試，包括靜態分析、軟件組成分析和動態分析，貫穿整個軟件開發生命周期來解決代碼質量和安全問題。Top 10的漏洞中，有8個都可以映射到CWE的同一個支柱缺陷，即CWE-707。也就是說，沒有滿足安全需求可能導致跨站腳本和SQL注入等攻擊。往往也會隨之而來。審計結果顯示，jQuery是最有可能存在漏洞的組件，盡管本報告中列出的每個jQuery漏洞都已經有了可用的補丁。對于j

17、query用戶（實際上是所有開源軟件的用戶）來說，意識到舊版本軟件可能帶來的潛在安全風險并采取措施減輕這些風險是非常重要的。采取措施，防止漏洞進入您的軟件供應鏈 創建并維護軟件物料清單(SBOM）。在防范軟件供應鏈攻擊的斗爭中，擁有一個列出開源組件的準確并實時更新的SBOM，對于評估風險以及確保代碼質量、合規性和安全至關重要。全面的SBOM列出了您的應用中包含的所有開源組件，以及這些組件的許可證、版本和補丁狀態，構成了防范供應鏈攻擊的有力武器，包括那些使用惡意軟件包的攻擊。了解最新情況。確保您有辦法了解新發現的惡意軟件包、惡意軟件和公開的開源漏洞。查閱新聞報道或定期發布的通知，以便針對影響SB

18、OM中開源組件的問題獲得實用性的建議和詳細信息。開展代碼審查。在將軟件引入項目之前，仔細檢查其代碼，看看是否存在任何已知漏洞。為了獲取更多的信息，您可以考慮對源代碼進行靜態分析，以發現未知的安全缺陷。積極主動。一個組件今天沒有漏洞，不代表明天也沒有。故意設計的惡意軟件包可能永遠不會被發現或標記為“可能有漏洞”。所以，在使用之前，請檢查組件的健康狀況和來源，以免將來出現安全問題。使用自動化的軟件組成分析(SCA)工具。SCA工具可以自動執行軟件安全問題的識別、管理和緩解任務，使開發者能夠專注于編寫代碼。此類工具可以評估開源和第三方代碼。|2024年開源安全和風險分析報告|8圖2：Top 10 C

19、VE/BDSATop 10的安全漏洞中，有8個可以追溯到同一個CWECWE項目將“支柱缺陷”定義為最高級別的缺陷，是與之相關的所有類別/變體缺陷的基礎。|2024年開源安全和風險分析報告|9為何某些BDSA沒有CVE公共數據源（如國家漏洞數據庫(NVD)）是獲取公開披露的開源軟件漏洞信息的首選渠道。但是，任何NVD CVE條目的報告都可能存在滯后。及時性一直都是影響NVD發布安全漏洞數據能力的因素之一。事實上，從漏洞首次披露到在NVD上發布，通常會間隔很長一段時間，一些研究報告稱，從漏洞首次披露到在NVD上發布的平均時間間隔長達一個月之久。NVD的另一個問題是，它提供的漏洞數據經常不完整。NV

20、D中發布的許多CVE都不包括受影響的版本范圍，并且通常太短，無法發揮作用。這通常是因為缺乏研究此類條目的資源造成的。顯然，僅僅依靠NVD來獲取漏洞信息是不明智的。許多商業SCA解決方案不僅可以提供比NVD更豐富的漏洞數據，而且還可以更準確地發現問題，并在必要時幫助您更快地修復它們。例如，如果您正在使用新思科技的SCA解決方案Black Duck，則可以利用新思科技安全研究團隊開發的開源漏洞通告“BDSA”。這些通告通常能夠更早地通知您影響代碼庫的漏洞 提前于NVD幾天甚至幾周。BDSA還提供更完整的漏洞數據，提供超越當今任何其他商用產品的安全洞察、技術細節和升級/補丁指導。例如，對于我們在20

21、23年Top 10漏洞列表中列出的漏洞，有三個BDSA在NVD中找不到對應的CVE。BDSA-2021-3651根據BDSA，某些版本的jQuery中包含對被劫持域名的注釋引用。這是一個安全問題，最穩妥的解決方法就是刪除被劫持域名的鏈接，正如第3.6.1版jQuery所做的那樣，因為如果用戶不知道域名的狀態，他們仍然可能在嘗試訪問被劫持的網站時遭受未知攻擊。雖然這些網站不能通過運行代碼來訪問，但標記這個問題還是有價值的，因為開發者或任何擁有訪問權限的人都有可能不小心點開惡意網站。新思科技CyRC團隊建議將此BDSA標記為“信息性的”。當供應商提供的“修復”僅僅是在代碼或產品文檔中添加警告時，或

22、者供應商拒絕了CVE或對發現的漏洞提出了質疑，認為這是組件的預期/設計行為時，可以使用這種標簽。類別CWE-546:可疑的注釋CVSS v3.1 評分5.10 BDSA-2014-0063這是一個較早的漏洞，最初在2014年1月被提出，與jQuery中因為缺乏用戶提供的輸入驗證而導致的潛在XSS漏洞有關。該漏洞可能允許攻擊者注入任意的web腳本并竊取受害者的會話cookies。根據BDSA，函數會將HTML字符串解析為DOM節點的數組。傳遞給該函數的事件屬性中所包含的任何腳本都會立即執行。如果函數調用者在將不可信的輸入傳遞給函數之前沒有正確地清理它，則可能導致XSS攻擊的風險。攻擊者可以利用這

23、一點，制作一些惡意的HTML，然后讓受害者訪問。如果受害者的瀏覽器處理了這些代碼，那么，其中包含的任何Web腳本都會在其系統上執行。該漏洞在jQuery 3.0.0-rc1中得到了緩解。但這種緩解并沒有清理惡意的輸入，仍允許腳本執行。它只是修改了解析器的默認行為，使其在上下文未指定或者指定為“null/undefined”的情況下，創建一個新的文檔。這樣就會延遲被解析的HTML的執行，直到其被注入到文檔中，從而給jQuery開發者提供了機會，使他們可以在函數調用后使用工具遍歷已創建的DOM，并移除不安全的內容。類別CWE:79:在網頁生成過程中不當地凈化輸入（“跨站腳本”）CAPEC-588:

24、基于DOM的XXSSCVSS v3.1 評分8.60 BDSA-2015-0567這也是一個較早的漏洞，與容易受到任意代碼執行攻擊的jQuery有關 jQuery版本使用了未修補的UglifyJS解析器，容易受到惡意JavaScript文件發起的任意代碼執行的攻擊。最終，這可能允許攻擊者運行惡意代碼。該漏洞已在 1.12.0 和 2.2.0.版本中修復。類別CWE Category A9:使用包含已知漏洞的組件CAPEC-251:本地代碼包含（Local Code Inclusion）。The Common Attack Pattern Enumeration and Classificati

25、on CAPEC是公開的攻擊模式目錄，提供了全面的模式架構和分類體系。CVSS v3.1 評分7.9|2024年開源安全和風險分析報告|10按行業劃分的漏洞情況與“計算機硬件和半導體”行業相關的代碼庫中，有88%包含高風險漏洞（嚴重程度評分為7分或更高），緊隨其后的是“制造業、工業、機器人”以及“零售和電子商務”，分別為87%和84%。每個行業都有類似發現。即使是占比最低的行業 航空航天、汽車、運輸和物流 也仍然令人不安，該行業有1/3的代碼庫中包含高風險漏洞。如圖1所示，我們在每個行業的代碼庫中都發現了開源代碼，而且占比很高。圖3表明，這些代碼庫中還包含組織機構尚未修補的大量已知開源漏洞，容

26、易被利用。計算機硬件和半導體88%制造業、工業和機器人87%零售和電子商務84%營銷科技81%企業軟件/SaaS80%教育科技75%能源與清潔科技75%金融服務和金融科技73%醫療保健、健康科技和生命科學73%網絡安全73%互聯網和移動應用72%互聯網和軟件基礎架構67%大數據、AI、BI和機器學習66%電信和無線63%物聯網50%虛擬現實、游戲、娛樂和媒體49%航空航天、汽車、運輸和物流33%圖3：包含高風險漏洞的代碼庫的百分比|2024年開源安全和風險分析報告|11有效的軟件供應鏈管理需要同時考慮許可證和安全合規性。您使用開源組件和庫來構建軟件，并且知道這些組件受到開源許可證的約束，但您是

27、否清楚這些許可證的具體內容？即使您的軟件只涉及一個不合規的許可證，這也可能導致法律問題，失去利潤豐厚的知識產權，花費大量時間進行補救并推遲產品的上市時間。Black Duck審計服務團隊發現，在2023年審計的代碼庫中，超過一半(53%)包含存在許可證沖突的開源軟件。開源許可55%43%42%39%36%ISC LicenseCreative Commons Zero v1.0 UniversalGNU Lesser General Public License v2.1 or LaterMozilla Public License 2.0The UnlicenseMIT LicenseApa

28、che License 2.0BSD 3-Clause“New”or“Revised”LicenseBSD 2-Clause“Simplified”LicensePublic Domain*92%89%81%69%56%*組件附帶的聲明表明它屬于公共領域，但沒有使用特定的公共領域許可證，比如Unlicense或Creative Commons圖4：代碼庫中發現的Top 10許可證的百分比|2024年開源安全和風險分析報告|12圖5：存在沖突的Top 10許可證的百分比Creative Commons Attribution Share Alike 3.0Creative Commons Att

29、ribution Share Alike 4.0GNU Lesser General Public License v2.1 or LaterGNU General Public License v2.0 or LaterApache License 2.0GNU General Public License v3.0 or LaterCreative Commons Attribution 3.0GNU Library General Public License v2 or LaterGNU Lesser General Public License v3.0 or LaterMozill

30、a Public License 2.017%8%15%6%16%8%13%6%8%5%在Black Duck審計服務團隊于2023年審計的開源軟件中，有92%使用了MIT許可證。作為允許在專有軟件中重用的寬松許可證，MIT許可證具有與其他軟件許可證高兼容和低風險的特點?？梢钥隙ǖ氖?，如果您在軟件中引入第三方組件，則很可能會涉及一些常用的寬松許可證，如MIT、Apache、BSD、ISC和Unlicense。需要注意的是，諸如“低風險”之類的術語只是一個參考，不能作為決定使用哪些開源軟件的依據。例如，盡管Apache 2軟件通常被認為使用了低風險的許可證，可以引入到使用GNU General

31、Public License 3.0(GPLv3)的項目中，但GPLv3軟件卻不能在Apache項目中使用。這是因為Apache軟件基金會的許可證理念與GPLv3作者對版權法的解釋導致了許可證之間的不兼容。對于開發者來說，最穩妥的做法是咨詢本公司的企業政策和法務團隊，以獲得有關許可證合規問題的具體指導。在2023年的審計中，Creative Commons是引發許可證沖突的最主要的原因。僅Creative Commons ShareAlike 3.0(CC-SA 3.0)就引發了17%的許可證沖突。Black Duck審計中頻繁發現“代碼片段”復制粘貼到源代碼中的代碼行。它們通常來自頗受歡迎的

32、博客網站Stack Overflow，該網站根據Creative Commons ShareAlike許可證自動授權所有可公開訪問的用戶貢獻。遺憾的是，這個一攬子許可證也涵蓋了網站上發布的代碼片段。我們之所以表示“遺憾”，是因為這些許可證根本不是針對軟件設計的，Creative Commons在其常見問題解答中明確表示：“我們不建議對軟件使用Creative Commons許可證?！蹦承┣闆r下，CC-SA許可證可以被理解為具有類似于GNU Public License的“病毒”效應（即，任何源自Copyleft許可作品的作品也必須適用相同的Copyleft條款），這可能會引起法律方面的擔憂。了

33、解許可證風險在美國和許多其他地方，創造性的工作（包括軟件）默認即受專有版權的保護。未經創作者/作者以授權許可證的形式明確允許，任何人對該等軟件的使用、復制、分發或修改均不合法。即使最友好的開源許可證也會規定用戶在使用軟件時需要承擔的義務。如果代碼庫中包含的開源代碼許可證與該代碼庫的總體許可證存在沖突，就可能存在潛在的許可證風險。GNU通用公共許可證(GPL)是應用于開源項目的最常見Copyleft許可證。如果商用閉源軟件中包含由GPL許可的代碼，就會產生沖突。標準開源許可證的變體或定制許可證可能會對被許可方提出不必要的要求，并且要求對可能的知識產權問題和其他問題進行法律評估。例如，JSON許可

34、證便是定制許可證的典型。JSON許可證基于寬松型MIT許可證，只不過添加了“該軟件嚴禁用于惡意用途，僅限用于善意用途”的限制。該聲明的含糊不清導致“善意用途”和“惡意用途”很難界定，許多律師都建議避免使用基于此類許可模式的軟件，尤其是在并購的情況下。在2023年審計的代碼庫中，1/3的代碼庫使用了沒有可識別許可證或具有定制許可證的代碼，與去年的審計結果基本相同。在開源審計中，經常會在一些不像Stack Overflow那樣有明確服務條款或軟件條款的網站中發現代碼片段。導致開源代碼缺乏許可證條款的另一個常見原因是開發者使用了代碼片段，但卻沒有將該片段的相關許可證一起帶過來。另外，隨著AI輔助編碼

35、工具的使用越來越普遍，也會導致沒有關聯許可證的代碼出現問題（詳見下一節）。|2024年開源安全和風險分析報告|13導致多個行業具有如此高比例開源許可證風險（見圖6）的原因可能包括：許多沖突較多的行業都傾向于將其軟件作為本地產品進行許可和分發。許多限制性的許可證只適用于這種方式分發的軟件。而沖突較少的其他行業則更多地采用基于訂閱或SaaS類型的部署方式，這些部署通常不被視為“分發”，也不受同樣的許可條款的限制。半導體和硬件公司嚴重依賴軟件和固件，其中大部分都包含開源代碼（見圖1）。復雜的片上系統設計可能包含不同來源的數百萬行代碼。在這種規模下跟蹤許可證和義務極具挑戰性。開源在底層系統軟件、固件和

36、驅動程序等方面非常普遍，這些都是硬件產品不可或缺的一部分。這些軟件很多都是基于GPL類型的Copyleft許可證，分發時需滿足程度極高的共享要求。軟件供應鏈在公司之間以及硬件設計者和制造商之間共享固件、驅動程序和工具，從而導致開源傳播，但沒有通過SBOM清單跟蹤其來源或許可證。計算機硬件和半導體92%制造業、工業和機器人81%大數據、AI、BI和機器學習64%電信和無線62%物聯網60%企業軟件/SaaS54%能源與清潔科技53%網絡安全52%互聯網和軟件基礎架構50%零售和電子商務50%虛擬現實、游戲、娛樂和媒體49%教育科技45%金融服務和金融科技42%互聯網和移動應用41%航空航天、汽車

37、、運輸和物流40%醫療保健、健康科技和生命科學36%營銷科技19%圖6：存在許可證沖突的代碼庫的百分比|2024年開源安全和風險分析報告|14防范AI編碼工具引入的安全和知識產權合規風險隨著AI驅動的編碼推薦工具的使用，圍繞生成代碼的所有權、版權和許可問題也隨之產生。例如，一項針對GitHub、Microsoft和OpenAI的集體訴訟聲稱，GitHub Copilot 一種基于云的AI工具，為開發者在編碼時提供自動完成式的推薦 違反了版權法和軟件許可要求。該訴訟還聲稱，Copilot推薦的代碼使用了未經許可的內容，沒有歸屬、版權聲明，或者不遵守原始許可條款。Copilot案例凸顯出使用AI生

38、成代碼的法律復雜性。對軟件開發者來說，在法律或政府做出解決這一問題的決策之前，避免使用AI輔助編碼工具顯然是避免因許可證或版權侵權而被起訴的最安全方法。如果開發者想要使用AI輔助工具，應該謹慎行事，避免不必要的風險。至少，他們應該讓公司詢問AI工具提供商，看看推薦的內容中是否包含受開源許可證約束的源代碼，如果是，是否可以將這些代碼標出或從推薦中排除。另一種解決辦法是使用新思科技Black Duck等現成的代碼掃描工具，利用代碼片段分析功能來掃描源代碼，并將每一行代碼與它們可能來自的任何開源項目進行匹配。使得開發團隊可以識別AI代碼助手引入的開源代碼所適用的許可證和相關條款。軟件供應鏈治理中開源

39、許可證管理的最佳實踐 對軟件中的所有第三方軟件組件進行全面清點，包括開源和商業軟件。注意AI輔助編碼工具可能會產生違反許可證條款和侵犯知識產權的代碼。評估每個組件的許可條款和條件，并評估它們是否符合產品的預期用途。檢查不同組件之間的許可證兼容性，因為有些許可證彼此可能不兼容。使用自動掃描工具來識別和跟蹤每個組件的許可義務和限制。實施一個流程，以確保許可證始終合規，包括定期許可證掃描和許可證合規程序的周期性審查。針對新的或不熟悉的許可證建立審查流程和工作流。確保法務、技術和業務的相關人員之間能夠有效溝通，以便合理地安排和執行許可證清理工作（也就是公司決定是否可以使用某個組件的許可證的過程）。記錄

40、所有的許可證清理活動，包括許可證評估與合規程序，以保留合規工作的證據，方便以后的審計。|2024年開源安全和風險分析報告|15理想情況下，開源軟件的使用者應該只使用那些有著強大社區支持的組件。例如，每天都有來自數百個組織的成千上萬名開發者改進Linux。然而，在Black Duck審計服務團隊對經過風險評估的936個代碼庫進行審查時，發現有49%的代碼庫中包含了兩年內未進行任何更新的開源軟件。如果一個項目不再有人維護，尤其是較小的項目，就不會有功能升級、代碼改進或者已知安全問題的修復。這在開源項目中并不少見。一些報告顯示，在2022年還在維護的Java和JavaScript開源項目中，有近20

41、%在2023年不再有人維護，使得這些項目面臨著漏洞利用和攻擊的風險。開源軟件很大程度上是志愿貢獻者和維護者的產物。雖然有些組織（如Microsoft、Red Hat和Google）制定了一些激勵計劃來促進開源項目的維護和參與，但絕大多數公司并沒有這樣做。當維護者停止維護項目時，必然會導致安全風險升高。開源軟件的使用者需要改進維護實踐Black Duck審計服務團隊在2023年對經過風險評估的936個代碼庫進行審查時發現，91%的代碼庫中包含了比最新版本落后10個或以上版本的組件。開源軟件的使用者有時候不更新開源組件，這可能有一些合理的理由。如果他們知道自己使用的開源軟件的情況，則可以做出正確的

42、決定，但遺憾的是，很多人并不知道 開發團隊可能會認為，更新開源組件可能帶來的意外風險大于升級到新版本所帶來的好處。例如，嵌入式軟件受到只能從外部來源引入的攻擊風險可能很小。這也可能是時間/資源的問題。許多團隊在構建和測試新代碼時，已經沒有多余的時間和資源去更新現有軟件，除非是非常緊急的問題。新思科技 2023年全球DevSecOps狀況調查報告 指出，對1,000名IT安全專業人士進行的調查顯示，28%的受訪者表示其組織機構需要長達三周的時間來修補已部署應用中的重大安全風險/漏洞，另有20%的受訪者表示，這可能需要一個月的時間。這些數字適用于所有的漏洞 自有、商業、第三方軟件和開源軟件。OSS

43、RA報告近十年來一直都在強調，開源軟件不同于商業軟件 沒有孰優孰劣的區別，只是單純的不同 需要不同的管理技巧。例如，商業軟件和開源軟件的補丁處理方式就大不相同。購買商業軟件通常需要根據供應商管理程序進行一些審查，而開源軟件可能只是由開發者自行下載。對開源軟件的使用可能存在一些組織規則 例如，只使用具有許可證的代碼 但在很多組織機構中，甚至連這樣的指導都不存在。使用商業軟件的組織都知道，他們的軟件會被自動“推送”補丁和更新，或者至少會收到供應商的通知，告訴他們有更新可以下載 通常是非常重要的更新。但這種情況在開源軟件中很少出現，開源軟件的使用者需要自己關注組件的狀態，自己去下載可用的新版本。要保

44、持對您使用的開源版本的了解，只有一種可行的解決方案，那就是制作準確、全面的開源軟件清單，并且自動監測軟件中開源組件的漏洞、更新情況和整體健康狀況。影響開源風險的運營因素在經過風險評估的代碼庫中，有49%包含了兩年內未進行任何更新的開源代碼在2023年分析的代碼庫中，有88%經過風險評估|2024年開源安全和風險分析報告|16無論是個人開發者還是大型企業，都有責任維護軟件供應鏈的安全以降低風險。隨著軟件供應鏈攻擊數量的增加，有效地管理開源軟件的使用、組件和依賴關系對于風險管理變得越來越重要。所有使用開源軟件的組織機構 正如本報告指出，這幾乎包括了所有組織機構 都應該主動管理開源風險，將其作為安全

45、軟件開發實踐的一部分。美國網絡安全和基礎設施安全局(CISA)于2023年底發布的 保障軟件供應鏈安全：管理開源軟件和軟件物料清單的推薦做法（Securing the Software Supply Chain:Recommended Practices for Managing Open Source Software and Software Bill of Materials）為在軟件供應鏈中使用開源軟件提供了詳細指導，包括：安全團隊通常會定義與開源組件相關的安全策略、流程和工具。理想情況下，開發者應該從經過預先審核的內部倉庫中選擇具有所需功能的組件 即已經使用SCA安全分析工具進行了初

46、始漏洞評估 然后在開發和/或構建階段開展進一步掃描，以盡早發現問題。跟蹤開源軟件的更新，并監控問題和漏洞。當發現漏洞時，應評估受影響的軟件，以確定組件的普及程度及其在產品中的使用情況。更新組件，或者，如果組件不再得到維護，應考慮尋找替代方案。使用SBOM。了解軟件中包含哪些組件對于準確、完整地管理代碼至關重要。SBOM是包含軟件中組件細節和供應鏈關系的正式記錄。SBOM可以提高軟件的透明度并記錄組件的來源。對于漏洞管理，SBOM可以支持漏洞的識別和修復。從代碼質量的角度來看，SBOM的存在可能表明供應商在整個軟件開發生命周期中使用了安全的軟件開發實踐。第14028號行政命令(EO)“提升國家網

47、絡安全”規定，軟件供應商必須直接向采購方提供SBOM，或者在公共網站上公開其SBOM，并且政府和非政府方面可能都需要查看SBOM，以確保軟件產品符合SBOM的最低要求。該行政命令還指示商務部以及國家電信和信息管理局(NTIA)發布 軟件物料清單最低要求（The Minimum Elements for a Software Bill of Materials(SBOM)），以簡要說明SBOM所需的活動和數據，并給出滿足SBOM要求的示例格式。該文件將SPDX和CycloneDX確定為兩種最常用的機器可讀SBOM格式。2023年中期，管理和預算辦公室(OMB)發布了OMB-23-16備忘錄，更新

48、了早期的OMB備忘錄，允許聯邦機構對SBOM提出以下要求：SBOM可根據軟件的重要性或其他標準而有所不同，具體由每個機構自行決定 SBOM必須采用NTIA定義的其中一種格式 研究結果與建議|2024年開源安全和風險分析報告|17創建安全的軟件開發框架為了保障客戶和用戶的利益，軟件生產商在保證軟件供應鏈的安全方面扮演著重要的角色。美國國家標準與技術研究院(NIST)的“安全軟件開發框架”(SSDF)提出了一系列實踐，作為以標準化方式安全開發軟件的基準。美國政府已經暗示，符合NIST SSDF可能會成為美國政府直接或間接采購的所有軟件的必要條件，而且軟件供應商很可能需要在不久的將來自證其遵守SSD

49、F。評估工具（如新思科技SSDF評估服務(Synopsys SSDF Readiness Assessment)）可以確定貴組織的軟件開發實踐是否與SSDF的實踐和任務相一致，以便您可以自信地證明貴組織的軟件開發過程符合SSDF標準。同樣，新思科技SBOM服務建立在Black Duck審計服務流程的基礎上，可以對您的軟件進行全面的安全審計，并生成一個SBOM，這對那些還沒有SBOM生成能力但卻需要一個基準SBOM的組織來說是一項很有價值的服務。軟件生產商可能因為法規或合同的要求，需要提供經過審計的SBOM。軟件使用者可能希望審查某個供應商制作的SBOM。這些情況下，需要一個聲譽良好的第三方機構

50、對軟件進行審計。新思科技SBOM審計和驗證服務就是基于這些驗證過的流程對軟件進行審計，并確認客戶提供的SBOM是否準確地反映了供應鏈的情況。了解代碼的構成本報告的研究結果總結如下：在掃描的1,000多個代碼庫中，有96%包含開源代碼 77%的源代碼和文件來自開源 53%的代碼庫存在開源許可證沖突 84%的代碼庫在安全風險評估中發現了漏洞；74%有高風險漏洞 91%的代碼庫中包含比最新版本落后10個或更多版本的組件 無論貴組織是開發還是使用軟件，幾乎可以肯定的是，軟件中都包含開源組件。您是否清楚地知道這些組件是什么，以及它們是否會帶來安全或許可證風險？2024年度報告顯示，96%的代碼中包含開源

51、組件，因此，了解代碼的具體情況是非常重要的。當風險評估發現91%的代碼庫都在使用遠遠落后于最新版本的開源組件時，軟件使用者需要更好地保持代碼的及時更新，尤其是在涉及到常用的開源組件時。始終及時更新開源軟件與貴團隊開發的代碼同樣重要。創建并維護一個SBOM，記錄您的代碼中包含了哪些軟件組件，以及它們的版本、許可證和來源。定期升級開源軟件，尤其是在使用了活躍項目的開源庫的情況下。如果缺乏對代碼的全面了解，并且沒有采用主動的軟件衛生實踐，您的軟件就會暴露在開源漏洞和知識產權合規問題的潛在攻擊之下。首先，您應該使用自動化SCA工具，在SDLC的早期階段發現并解決安全、代碼質量和許可證問題，因為您需要毫

52、無疑問地知道代碼構成情況。.如果缺乏對代碼的全面了解，并且沒有采用主動的軟件衛生實踐，您的軟件就會暴露在開源漏洞和知識產權合規問題的潛在攻擊之下。新思科技與眾不同新思科技提供的集成解決方案，可以改變您構建和交付軟件的方式，在應對業務風險的同時加速創新。與新思科技同行，您的開發人員可以在編寫代碼的時候快速兼顧安全。您的開發和DevSecOps團隊可以在不影響速度的情況下在開發管道中自動進行安全測試。您的安全團隊可以主動管理風險并將補救工作聚焦在對貴組織最重要的事情上。我們無與倫比的專業知識可以幫助您規劃和執行所需的安全計劃。只有新思科技能夠滿足您構建可信軟件的一切需求。欲了解有關新思科技軟件完整

53、性小組的更多信息，請訪問： Synopsys,Inc.版權所有，保留所有權利。新思科技是Synopsys,Inc.在美國和其他國家/地區的商標。新思科技商標列表可在 Weakness Enumeration,CWE）是由社區開發的列出軟件和硬件缺陷類型的列表，分為三層。CWE涵蓋了600多個類別，包括緩沖區溢出、路徑/目錄樹遍歷錯誤、競爭條件、跨站腳本、硬編碼密碼和不安全隨機數等。CVE公共漏洞和暴露（Common Vulnerabilities and Exposures,CVE）列出了公開披露的信息安全缺陷的列表。Black Duck Security Advisory(BDSA)關于開源

54、漏洞的詳細、及時、一致的信息。BDSA為新思科技客戶提供了開源漏洞的早期預警通知和升級/修補指導。BDSA提供當天通知、實際可操作的漏洞消減指導和規避方案信息、嚴重性評分和參考信息等。軟件組件開發人員可以添加到其軟件中的預先寫好的代碼。軟件組件可以是日歷函數等實用程序，也可以是支持整個應用程序的綜合軟件框架。依賴項當某個軟件組件被其他軟件使用時，也就是說當這些軟件依賴于該組件時，該軟件組件就變成了依賴項。任何給定的應用程序或服務都可能有許多依賴項，而這些依賴項本身也可能依賴于其他組件。代碼片段代碼片段是開發者可以復制粘貼到自己代碼中的一小段可重用的代碼。即使軟件中只包含一小段的開源代碼片段，軟

55、件用戶也必須遵守與該代碼片段相關的任何許可協議。開源許可證當軟件中使用開源組件或開源組件的代碼片段時，包括如何使用和重新分發這些組件，用于闡述最終用戶義務的一組條款和條件。開源許可證基本上分為兩類。寬松型許可證(Permissive License)寬松型許可證基本不設任何使用限制。一般來說，此類許可證的主要要求是原始代碼的歸屬權屬于其原始開發者。著佐權許可證(Copyleft license)此類許可證通常涵蓋互惠義務，規定代碼的修改和擴展版本必須在與原始代碼相同的條款和條件下發布，并且有改動的源代碼必須按要求提供。商業實體對在其軟件中使用著佐權許可證的開源代碼應十分謹慎，因為它的使用可能會

56、帶來整個代碼庫的知識產權問題。軟件組成分析(SCA)一種用于自動化開源軟件管理流程的應用程序安全工具。SCA工具可以集成在軟件開發生命周期中，用于識別代碼庫中使用的開源代碼，提供風險管理和緩解建議，并執行許可證合規驗證。軟件物料清單(SBOM)代碼庫中的軟件組件和依賴項的全面目錄清單，通常由軟件組成分析工具生成。正如美國國家電信與信息管理局所說，“SBOM應包括一個機器可讀的軟件組件和依賴項清單，以提供關于這些組件及其層次關系的信息?！庇捎赟BOM旨在跨公司和社區共享，因此，具有一致的格式(即人可讀和機器可讀)和一致的內容至關重要。美國政府指南中，目前將兩種格式指定為已被批準的標準格式：Sof

57、tware Package Data Exchange(SPDX)和CycloneDX。貢獻者開源安全和風險分析報告 是由新思科技軟件完整性小組的多個團隊共同完成的，包括審計服務、咨詢、研究、法律和市場團隊。他們的辛苦付出使OSSRA在過去十年成為了有關開源代碼質量、安全性及許可證合規性的權威報告。特別感謝Nancy Bernstein、Scott Handy、Siobhan Hunter、Matt Jacobs、Natalie Lightner、Merin McDonell、Mike McGuire、Phil Odence、Rie Sekine、Liz Samet、Jenny Stout和Jack Taylor為今年的報告做出的貢獻。Rachel Bay連續九年參與了OSSRA報告的編制工作，并展現了她令人難以置信的設計才華。能夠撰寫這份報告是我的榮幸 Fred Bals