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

1、年度開源安全和風險分析報告目錄歡迎閱讀2025年度OSSRA報告 .1本報告的閱讀對象.1您將學到什么？為什么說它很重要？.2關于本報告的數據和Black Duck審計 .3研究結果概覽.4開源風險和漏洞概覽.7軟件安全始于代碼可視性.7了解風險管理并獲得代碼可視性.8使用SCA和SBOM提高軟件安全性和透明度.8分析漏洞的影響.11Log4j和Equifax：關于代碼可視性的兩點經驗教訓.12最危險和最嚴重風險的漏洞.13數據能告訴我們什么.18行業特定的洞察 .18開源許可.19沖突、變體和缺乏許可證如何產生風險.19傳遞性依賴對許可證沖突的影響.202024年的十大開源許可證.20何為寬

2、松式、弱著佐權和互惠開源許可證？.21如何通過SCA管理開源許可證風險 .21按行業劃分的許可證沖突情況.22并購注意事項.23影響風險的維護和運營因素.25結語：發生變化的事物越來越多.27主要建議.282025年度開源安全和風險分析報告|1歡迎閱讀2025年度 OSSRA報告 開源軟件(OSS)徹底顛覆了應用開發工作，它們提供了一個龐大的預構建組件庫，可以帶來節約成本、提高靈活性和可擴展性等諸多好處。然而，在獲得所有這些好處的同時，使用開源軟件的每家公司都需要準備好承認并應對開源風險。2025年度 “開源安全和風險分析”(OSSRA)報告 詳細介紹了Black Duck審計數據的主要分析結

3、果，包括安全漏洞、許可問題、組件維護和行業趨勢。我們的分析表明，開源無處不在，如果不能正確識別和管理，可能會帶來重大風險。本報告的閱讀對象本報告的研究結果將有益于各類讀者，特別是那些參與保護軟件供應鏈的讀者，以及那些直接參與軟件開發、安全和風險管理以及并購(M&A)活動的讀者。開發人員將深入了解我們在開源軟件中發現的常見漏洞類型，包括跨站腳本(XSS)和拒絕服務(DoS)漏洞。例如，OSSRA報告強調了采用輸入驗證和凈化技術的重要性，這可以幫助開發人員構建更安全的應用。此外，本報告還標識了包含漏洞的最常見開源組件，這將有助于開發人員在選擇開源庫和框架時做出明智決策。例如，開發團隊應該意識到，我

4、們的數據顯示，jQuery、jackson-databind和Spring Framework經常包含需要定期管理和修補的漏洞。OSSRA 2025報告還強調了使用過時組件的風險，以及所有組織機構實施及時更新流程的必要性。例如，我們發現90%的被審代碼庫中包含最近四年沒有進行任何維護與更新的過時開源組件。過時組件會放大安全風險，為攻擊者提供更大的攻擊面，并帶來合規性和兼容性問題。過時開源組件的存在也表明，開發人員沒有利用最新的軟件，而是依賴不再維護的代碼?！耙杂荽挥菡邉??！睂O子2025年度開源安全和風險分析報告|2關注安全問題的讀者可以利用 OSSRA 2025報告 提供的數據來改進漏洞管理

5、流程。例如，該報告確定了在審計中發現的最常見的通用漏洞披露(CVE)及其與常見軟件弱點枚舉(CWE)的關系。風險管理專業人員可以使用OSSRA數據就開源軟件采用和風險緩解制定明智的戰略決策。他們還能跨行業來比較漏洞占比和其他指標，從而幫助確定其組織機構在哪些領域表現良好，而哪些領域需要改進。OSSRA數據主要源于對并購目標的代碼分析，能給參與并購交易的專業人士提供關鍵洞察，幫助他們了解交易中可能遇到的各種問題，如常見的開源許可沖突、目標公司的安全狀況，以及可能影響目標公司IP價值的潛在運營挑戰。您將學到什么？為什么說它很重要？您軟件中的開源組件比您想象的多得多：我們評估的代碼庫中有97%包含開

6、源代碼，每個應用平均有911個OSS組件。從行業角度看，包含開源代碼的代碼庫比例從計算機硬件和半導體、教育科技、互聯網和移動應用領域的100%，到制造業、工業和機器人領域“較低的”79%不等。開源代碼庫變得越來越龐大、越來越復雜：我們的數據顯示，在過去四年間，普通應用中的開源文件數量增加了兩倍。這背后的原因之一便是對“傳遞性依賴項”其他軟件組件賴以運行的開源庫 的使用。開源代碼經常會使用其他開源代碼。我們的審計顯示，在我們掃描發現的開源組件中，有64%是傳遞性依賴項，如果不使用自動化工具，幾乎不可能定位或跟蹤它們。如果您缺乏最新的第三方代碼清單，那么，查找傳遞性依賴項的所有實例就像大海撈針一樣

7、困難。所有這些開源代碼的出處：我們的審計顯示，大多數開源代碼都是從包管理器存儲庫下載的。在我們審計中發現的近百萬個OSS組件中，有超過28萬個來自龐大的JavaScript包公共數據庫“npm”。無論您是否認為開源是“免費的”，它都是有代價的：貴組織正在使用的應用中包含高風險或重大風險開源漏洞的幾率超過80%，其中近一半是由傳遞性依賴項引入的。傳遞性依賴項會帶來許可和維護問題以及安全挑戰：我們的審計發現，超過一半的代碼庫存在許可證沖突問題，主要是由于傳遞性依賴項與另一個組件的許可證不兼容造成的。在我們的審計中發現的組件許可證沖突中，近30%是由傳遞性依賴項引起的。靜態應用安全測試(SAST)和

8、動態應用安全測試(DAST)可以幫助識別編碼錯誤：這些測試方法可以發現輸入驗證和敏感信息泄露等問題，以及在互聯網上發送重要數據時不加密、加密方法過時或薄弱、未能正確保護密碼或其他機密信息等問題。使用Web應用和服務的每家組織都應使用軟件組成分析(SCA)和DAST工具對其進行評估：開發和安全團隊需要實施集成了DAST、SAST和SCA的多維安全方法，以滿足現代軟件的全方位安全覆蓋需求。我們的研究結果表明，采用這種全方位的方法可以顯著降低潛在的重大漏洞暴露風險。2025年度開源安全和風險分析報告|3關于本報告的數據和Black Duck審計 本報告使用的數據來自Black Duck審計團隊在20

9、24年對16個行業965個商業代碼庫的1,658次分析所得匿名結果的評估（見下文注釋）。Black Duck提供一系列服務，包括根據不同需求和目標量身定制的開源審計。開源審計利用自動化工具、綜合數據庫和專家分析的組合，可以對組織機構的開源軟件使用情況進行全面評估。作為這些審計的關鍵組成部分，Black Duck KnowledgeBase已建立二十年之久，包含數百萬個開源組件的數據，如許可證、漏洞和潛在風險。該知識庫由Black Duck網絡安全研究中心(CyRC)提供和管理，其中包含來自5.7萬個Forges和存儲庫的超過870萬個開源組件的數據。代碼庫提交：組織機構向Black Duck提

10、供待審代碼庫的訪問權限，包括源代碼、二進制文件和其他相關工件。自動化分析：Black Duck利用自動化工具套件（包括SCA解決方案），通過高級字符串搜索功能掃描代碼庫，識別所有開源組件及其依賴項，包括傳遞性依賴項。專家審查：Black Duck的開源專家團隊審查自動化分析的結果，驗證結果，以確保完整性和準確性。報告生成：Black Duck生成一套全面的報告，針對所有開源組件、相關許可證、已知安全漏洞和潛在運營風險提供詳細的軟件物料清單(SBOM)。該報告還詳細列出了SBOM中的編目問題。補救指導：Black Duck就如何解決已識別的問題提供指導，例如更新易受攻擊的組件、解決許可證沖突和降

11、低運營風險。注：2024年，Black Duck審計團隊對審計數據的評估和呈現方式進行了多項改進。值得注意的是，客戶提交的單個代碼庫現在被拆分為多個分析單位，稱為“項目”。這項新技術提供了一種更精細的代碼庫分析方法，可以給客戶帶來諸多好處，包括更詳細的報告以及更準確的組件識別和依賴項跟蹤。這些變化還會影響審計數據的呈現方式。例如，雖然為了簡單起見，我們仍會在OSSRA中提到“代碼庫”，但在更細粒度的層面上，我們針對這些代碼庫分析了2024年提交給Black Duck的965個代碼庫中的1,658個單獨項目。2025年度開源安全和風險分析報告|4%的代碼庫包含開源代碼%的被掃描代碼來自開源組件個

12、OSS組件出現在每個應用程序中%平均的OSS組件是傳遞性依賴項Black Duck審計團隊共掃描了,個項目在過去四年中，普通應用中的開源文件數量增加了兩倍。,審計發現，超過28萬個開源組件來自npm存儲庫。在我們掃描中發現的大多數OSS包都是用JavaScript編寫的。但不是全部。例如，隨著開發人員對C和C+中的內存安全問題做出反應，Rust包存儲庫的使用大大增加。研究結果概覽原始存儲庫語言2024年審計中發現的組件數量npm JavaScript282,521 yarn(JavaScript)JavaScript162,327 pnpm(JavaScript)JavaScript24,06

13、9 原始存儲庫語言2024年審計中發現的組件數量CargoRust33,327NugetC#,Visual Basic,F#,WiX,C+,Q#29,818go_mod Go24,069 MavenJava14,097packagistPHP6,112GradleJava,C,JavaScript4,6152025年度開源安全和風險分析報告|5研究結果概覽漏洞和安全性互聯網和移動應用 營銷科技計算機硬件和半導體 教育科技企業軟件/SaaS金融服務和金融科技醫療保健、健康科技和生命科學零售和電子商務大數據、AI、BI和機器學習網絡安全互聯網和軟件基礎架構航空航天、汽車、運輸和物流物聯網虛擬現實、

14、游戲、娛樂和媒體 制造業、工業和機器人能源和清潔科技100%88%87%86%86%83%80%80%80%79%78%76%72%71%63%60%86%的風險評估代碼庫中包含易受攻擊的開源代碼81%的風險評估代碼庫中包含高風險或重大風險漏洞10個中的8個 10大高風險漏洞中有8個是在jQuery中發現的圖1：包含高風險漏洞的代碼庫（按行業劃分）行業包含高風險漏洞的代碼庫百分比2025年度開源安全和風險分析報告|6研究結果概覽許可的代碼庫（所有代碼庫中）存在許可證沖突33%的代碼庫（所有代碼庫中）包含無許可證或定制許可證語言的OSS組件，通常是開發人員就如何使用該軟件的注釋行業56%33%存

15、在許可證沖突問題的代碼庫百分比圖2：存在許可證沖突問題的代碼庫（按行業劃分）教育科技大數據、AI、BI和機器學習金融服務和金融科技互聯網和移動應用 計算機硬件和半導體 航空航天、汽車、運輸和物流網絡安全零售和電子商務營銷科技 企業軟件/SaaS制造業、工業和機器人虛擬現實、游戲、娛樂和媒體互聯網和軟件基礎架構物聯網醫療保健、健康科技和生命科學能源和清潔科技維護和運營風險91%90%的代碼庫中包含過時的OSS組件的代碼庫中包含落后于最新版本至少10個版本的組件 71%71%66%64%63%61%58%57%56%54%53%51%50%48%47%37%2025年度開源安全和風險分析報告|7o

16、f the codebases contained at least one vulnerabilityof the codebases contained high-or critical-risk vulnerabilities 86%81%Maximum number of unique vulnerabilities found in a single codebase3,548Mean number of unique vulnerabilities per codebase 154組件包含該組件的代碼庫的百分比jQuery32%jQuery UI16%Bootstrap(Twitt

17、er)15%Spring Framework12%Lodash12%Netty Project11%jackson-databind9%Apache Tomcat8%Python programming language5%TensorFlow1%開源風險和漏洞概覽所有的Black Duck審計都會檢查開源許可證的合規性?？蛻艨梢宰孕羞x擇哪些組件不參加漏洞審計/運營風險評估。2024年，Black Duck審計團隊對901個客戶代碼庫進行了漏洞/運營風險評估。本節和“影響風險的維護和運營因素”部分的數據基于這些評估。軟件安全始于代碼可視圖3：包含高風險或重大風險漏洞的10大組件2025年度開源

18、安全和風險分析報告|8了解風險管理并獲得代碼可視性有效的開源風險管理并不是要找到并修復每一個漏洞 只要有漏洞存在，這便是一項永無休止的任務。相反，風險管理的目標應該是獲取必要的知識，以便對代碼的風險做出明智決策。例如，一旦確定了漏洞，您就可以評估其嚴重性、被利用的可能性以及對系統的潛在影響。同樣，并非每個組織都將所有的許可證沖突或代碼質量問題視為高優先級。關注最關鍵的問題對于有效的開源風險管理至關重要。但您首先必須知曉這些問題，然后才能解決它們。深入了解代碼是確定補救工作優先級的關鍵。為了獲得這種洞察，組織越來越多地采用SBOM，即所有軟件組件及其依賴項的全面清單。使用SCA和SBOM提高軟件

19、安全性和透明度SBOM是一種正式的記錄，包含了在構建軟件中使用的所有組件的細節和供應鏈關系。它還可以作為軟件應用中所有組件的清單，包括開源庫、第三方模塊、框架及相關元數據，如許可證和版本。SBOM提供了軟件組成的透明度，使您能夠了解它在您的環境中運行什么，并最終使安全團隊能夠了解風險、跟蹤依賴項和審計軟件。Linux基金會的一項研究發現，生成SBOM的組織機構能夠更好地了解應用中組件之間的依賴關系，監控組件的漏洞，并管理OSS許可證合規性。Gartner的一份報告著重指出，SBOM能夠提高軟件供應鏈中專有和開源代碼的可視性、透明度、安全性和完整性。許多處于軟件交付管道末端的客戶現在都將SBOM

20、寫在供應商合同中。簡言之，SBOM對于組織機構確保軟件應用的安全性、合規性和整體健康狀況至關重要，好處如下：風險管理：識別并管理軟件供應鏈中的風險。漏洞管理：快速識別和緩解已知漏洞。許可證合規：確保遵循開源和第三方許可證的要求。軟件質量：識別過時或不支持的組件。并購：評估并購過程中與軟件組件相關的法律和知識產權(IP)風險?！霸讲淮_定，越需探究?！盓rik Seidel2025年度開源安全和風險分析報告|9 安全的軟件開發：根據美國網絡安全和基礎設施安全局(CISA)、軟件工件供應鏈級(SLSA)框架和NIST SSDF的建議，加強安全軟件開發實踐。有效的軟件開發、部署和維護：促進有效的軟件開

21、發流程和生命周期管理。一致且可讀的依賴項配置文件：通過標準化且易于理解的方法來表示應用依賴項。標準化的依賴項列表和自動化：確保依賴項列出方式的一致性，使自動化更容易實施。SBOM提高了軟件供應鏈中專有和開源代碼的可視性、透明度、安全性和完整性。SCA工具如何生成SBOMSCA工具通過以下方式生成SBOM：代碼掃描：SCA工具掃描軟件項目的源代碼或二進制文件，以識別所有組件和依賴項。這些掃描工具使用各種掃描方法，包括：清單掃描：檢查清單文件（例如package.json或Cargo.toml）中列出的依賴項。二進制掃描：檢查編譯好的二進制文件中是否包含可以追溯到特定庫的任何第三方代碼?；旌蠏呙瑁?/p>

22、結合使用清單和二進制掃描來確保沒有漏掉的依賴項。片段掃描：分析文件或代碼行的較小部分（“片段”），并將其與已知完全開源組件的數據庫進行匹配。依賴關系分析：SCA工具可以分析組件之間的關系，包括直接依賴關系和傳遞性依賴關系。漏洞和許可證識別：這些工具可將已識別的組件與漏洞數據庫和許可證存儲庫進行比較，以發現潛在的安全風險及許可證合規問題。SBOM生成：基于從分析中收集的信息，SCA工具可以標準化格式（如SPDX或CycloneDX）創建全面的SBOM。持續監控：SCA工具通常提供持續監控功能，以保持SBOM的最新狀態。隨著開源組件中新漏洞的發現或更新包的推出，該工具可以相應地更新SBOM，確保其

23、始終準確。例如，Black Duck SCA可以集成到軟件開發生命周期中，以便在開發軟件時生成SBOM。Black Duck SCA還允許用戶導入第三方SBOM，以便將這些組件添加到相關項目中，持續分析風險，并添加到作為應用生命周期一部分而生成的任何報告或SBOM中。在軟件交付管道的末端，已經分析過的軟件SBOM可以導出至業界標準文件格式中。2025年度開源安全和風險分析報告|10跟蹤傳遞性依賴當一個軟件組件依賴另一個組件，進而依賴其他組件時，就會發生傳遞性依賴。這些依賴可能會帶來難以手動跟蹤的復雜關系。SCA工具生成的SBOM可以幫助相關團隊識別并跟蹤所有的傳遞性依賴，為組織提供軟件供應鏈的

24、完整視圖。解決漏洞、許可證、知識產權和代碼質量問題SBOM使組織機構能夠在安全漏洞發生之前主動識別和處理漏洞。通過分析SBOM，安全團隊可以識別第三方組件中的漏洞，并確定它們是不是最新而且正確配置的。這種主動方法有助于降低安全漏洞的風險，并確保軟件構建在堅實的基礎上。SBOM可用于確保所有組件都滿足合規要求，并幫助組織機構跟蹤與其軟件組件相關的許可證，為管理許可證合規風險和履行必要義務創建更開放、擴展性更強的方法。SBOM還可以幫助組織機構識別過時或不受支持的組件，避免帶來安全風險或性能問題。這些信息使組織機構能夠確定更新的優先級。通過及早識別和解決代碼質量問題，組織機構可以降低安全漏洞的風險

25、，提高軟件性能，并增強可維護性。SBOM的采用SBOM的好處使其成為安全軟件開發實踐中日益重要的組成部分。雖然SBOM的采用量仍在不斷增多，并且采用量因行業和公司而異，但人們越來越認識到，SBOM是管理軟件供應鏈風險和確保軟件安全的寶貴工具。Linux基金會2022年的一項研究發現，78%的組織機構預計將在當年生成SBOM。Censuswide在2023年開展的一項研究發現，60%的大型企業（年收入超過5,000萬美元）需要供應商提供SBOM。圖4：通過Black Duck SCA分析漏洞的影響2025年度開源安全和風險分析報告|11例如，在我們掃描中發現的1號漏洞CVE-2020-11023

26、是影響jQuery易受攻擊版本的XSS漏洞。該漏洞的最大威脅是數據機密性和完整性。該漏洞還被列入CISA的“已知可利用漏洞目錄”，表明它曾經被真正利用過。這些因素可能推動組織機構為處理該漏洞分配更高的優先級（相對代碼庫中的其他漏洞而言），而實際的優先級分配因具體情況而異。分析漏洞的影響當SCA工具識別出應用中的漏洞時，您如何決定首先關注哪個漏洞呢？雖然漏洞的存在表明軟件存在薄弱點，但并不一定意味著這些薄弱點很容易被利用 也就是說，被惡意行為者用來破壞系統、應用或網絡。想象一下連接各個城市的復雜路網。一些道路可能交通繁忙，而另一些道路則很少使用。同樣，軟件應用不同代碼段的訪問頻率也不相同?？蛇_性

27、和影響分析有助于確定應用代碼的“繁忙路段”上是否存在漏洞 這些路段上的漏洞相對來說更有可能被利用?？衫眯匀Q于多個因素，包括被利用代碼的可用性、漏洞利用的復雜性（即攻擊者面臨的難度），以及攻擊者可能從漏洞利用中獲得的潛在回報等。例如，2014年發現的Heartbleed漏洞是OpenSSL加密庫中的一個重大安全漏洞，因為它很容易被利用并允許攻擊者竊取敏感信息，因此影響了數百萬個網站和服務器，其中比較有名的受害者是加拿大稅務局(CRA)。該機構稱，黑客利用這一漏洞竊取了加拿大公民的社會保險號碼。CRA被迫暫時關閉在線服務以處理這一問題，并延長了報稅截止日期。網絡安全公司CloudFlare估計

28、，為客戶撤銷和重新頒發SSL證書給某個證書頒發機構帶來了每月約40萬美元的損失。SCA工具如何提供幫助SCA工具可以根據多個因素（包括嚴重性、可利用性和潛在影響）對漏洞進行優先級排序。這有助于組織機構專注于處理最關鍵的漏洞，優化其補救工作，并過濾不相關的問題而減少警報疲勞。僅僅識別漏洞是不夠的；其龐大的規模使您有必要通過明智的方式來了解哪些漏洞需要首先修復。Black Duck SCA根據可利用性、補救指導、嚴重性評分和調用路徑分析等因素對漏洞進行優先級排序。Black Duck可以確定更容易被調用的易受攻擊代碼，并將這些漏洞標記為可利用，表明這些漏洞具有更高的修復優先級。2025年度開源安全

29、和風險分析報告|12Log4j和Equifax：關于代碼可視性的兩點經驗教訓雖然當代媒體的報道有點夸張，但2021年的Log4Shell漏洞和2017年的Equifax漏洞都提醒著我們了解開源組件的重要性。在這兩種情況下，缺乏對開源組件的認識是加重事件嚴重性的主要因素。就Log4j而言，許多開發團隊都不知道他們的應用在何處、如何使用，甚至不知道這些應用是否使用了開源日志工具，這通常是因為應用中深埋了幾個不被基本代碼審查所覆蓋的依賴項。當CISA向聯邦機構發出指令，要求他們在10天內找到軟件中Log4j庫的所有實例、檢查系統是否容易受到Log4Shell漏洞攻擊并修補受影響的服務器時，許多安全團

30、隊都發現自己被迫犧牲了12月份的假期，加班加點尋找Log4j易受攻擊的版本并提前修補潛在的災難性安全漏洞。事件易受攻擊的組件促成因素主要應對措施Log4jEquifaxLog4j2 libraryApache Struts 框架缺乏對軟件供應鏈的可視性，缺乏對應用中Log4j使用的認知缺乏全面的IT資產清單組織機構需要了解其應用中的所有開源組件，即便是看似微不足道的組件，如日志庫。組織機構需要維護所有軟件資產的準確清單。盡管對2017年Equifax Apache Struts漏洞利用的解釋多年來已簡化為：負責傳達打補丁需求的人員沒有將信息傳遞給合適級別的人員，但正如國會在該事件報告中詳述的那

31、樣，完整的原因要復雜得多。幾年來，Equifax一直在大舉收購，每次收購都會增加公司技術基礎架構的復雜性和不透明性。這個拼湊的IT基礎設施的一部分是一個基于Web的糾紛和披露應用，它成為了這次入侵的主要目標。正如Equifax時任CIO在證詞中解釋的那樣，Equifax對該申請使用的軟件沒有清晰的了解。缺乏對軟件清單的可視性是一個已知問題，兩年前的Equifax內部審計中便記錄了這一問題。正如審計報告所述，“缺乏全面的IT資產清單，也沒有準確的網絡文檔。缺乏準確的資產清單使公司很難確保所有資產都得到充分的修補和配置。如果不能明確了解所有IT資產的狀態，確保Equifax系統的安全性和穩定性將極

32、其困難?！?025年度開源安全和風險分析報告|13更糟糕的是，該應用與Equifax的許多老舊系統一樣，在IT領域是一個“遺留問題”。到2017年，Equifax熟悉這個特殊Web應用內部工作原理的人員已經所剩無幾，以至于名義上的監管人員甚至不知道它包含Apache Struts軟件。Equifax案例從另一方面說明了缺乏開源代碼可視性的危害，任何依賴其他公司代碼的企業都應該記?。弘m然您可能對自己的代碼有很好的處理能力，但您知道外部代碼中包含什么嗎？最危險和最嚴重風險的漏洞在深入研究我們在審計中發現的特定高風險漏洞之前，我們先解釋一下CVE、CWE和BDSA這三個術語的含義。CVE是已知公開網

33、絡安全漏洞的標準化標識符。每當有新漏洞被發現時，它都會被分配一個唯一的CVE ID，以便安全專業人員和開發人員能夠快速輕松地參考和跟蹤這個特定漏洞。國家漏洞數據庫(NVD)使用CVE標準作為識別和描述漏洞的基礎。CWE是社區編制的軟件和硬件弱點類型清單。CWE是描述安全弱點的通用語言，有助于識別、緩解和預防這些弱點。如圖5所示，查看我們在掃描中發現的漏洞與最常見CWE列表的對應關系可能具有指導意義。例如，鑒于我們發現的所有開源漏洞中有超過70%與輸入驗證不當（這可能導致注入和XSS漏洞利用）有關，開發和安全團隊可能希望將精力集中在為自有代碼使用適當的驗證技術上，同時使用SAST和DAST對第三

34、方代碼進行定期測試，以盡早和持續地捕獲漏洞?！皩M織機構來說，了解其IT環境中存在哪些資產對于做出準確和明智的風險決策至關重要，例如何時以及如何修補易受攻擊的系統?！盓quifax數據泄露事件，2018年12月第115屆國會多數黨工作人員報告2025年度開源安全和風險分析報告|14CWE具有可關聯到CWE的漏洞的代碼庫百分比描述CWE-2071%輸入驗證不當：軟件不能驗證或錯誤地驗證輸入，這可能會影響到程序控制流或數據流，從而導致緩沖區溢出、SQL注入和跨站腳本等漏洞。CWE-40070%資源消耗不受控：軟件無法正確控制系統資源的分配和釋放，如內存、CPU時間或磁盤空間。這可能會導致DoS攻擊

35、。CWE-20060%將敏感信息暴露給未經授權的參與者：軟件將敏感信息（如密碼、信用卡號或個人數據）暴露給未經授權的參與者。這可能通過各種方式發生，例如不安全的存儲、未加密的傳輸或不當的訪問控制。CWE-7956%網頁生成時對輸入的轉義處理不當（跨站腳本）：在將用戶提供的輸入納入HTML頁面之前，軟件沒有轉義或錯誤地轉義輸入的內容。這使得攻擊者能夠注入惡意腳本，竊取用戶數據或控制他們的瀏覽器。CWE-18548%正則表達式不正確：軟件指定正則表達式的方式會導致數據匹配或比較錯誤。正則表達式應接受全面的測試，如等效劃分、邊界值分析和健壯性。CWE-77048%資源分配不設上限或不予限制：不對軟件

36、的資源分配設置上限或給予限制，這可能會使攻擊者消耗過多的資源，從而導致DoS攻擊。CWE-8044%網頁中與腳本相關的HTML標記轉義不當（基本XSS）：與CWE-79類似，這個弱點特別針對無法轉義可用于注入腳本的HTML標記。.CWE-132139%對象原型屬性的修改控制不當：軟件允許攻擊者修改對象的原型，這可能會影響該對象的所有實例，并導致意外行為或提權。CWE-133336%低效正則表達式復雜度：軟件使用的正則表達式過于復雜，可能導致CPU消耗過多，容易受到DoS攻擊。CWE-50231%不可信任數據的反序列化：軟件對不可信任的數據實施反序列化，這可能允許攻擊者執行任意代碼或操縱應用邏輯

37、。圖5：代碼庫掃描中主要的CWE2025年度開源安全和風險分析報告|15本報告中提到的Black Duck安全建議(BDSA)是由我們CyRC提供和管理的Black Duck專屬漏洞數據源。BDSA針對大量漏洞提供比國家漏洞數據庫(NVD)更深入的覆蓋。BDSA不僅提供更及時、更詳細的漏洞洞察（包括嚴重性、影響和可利用性指標），而且還提供可操作的補救指導。通過提供有關修復版本、補丁信息、漏洞利用和規避方法等詳細信息，BDSA可以為您節省時間。CyRC團隊提供詳細的漏洞指導，超出了NVD通常在CVE記錄中提供的內容。BDSA還針對可能受影響的組件版本進行交叉檢查和驗證，從而給受特定漏洞影響的組件

38、和版本提供額外且更準確的映射。我們接下來仔細看看掃描中發現的主要的高風險和重大風險開源漏洞。圖6：主要的高風險和重大風險漏洞 1.CVE-2020-11023CVE-2020-11023在三分之一（確切地說是32.6%）的掃描代碼庫中被發現。這是一個XSS漏洞，影響從1.0.3（包括1.0.3）到3.5.0之間的jQuery版本（在本報告發布時，jQuery的當前穩定版本是2023年8月發布的3.7.1）。請注意，CVE-2020-1023已被列在CISA的“已知被利用漏洞目錄”中，表明它已被有效利用。該漏洞允許攻擊者操縱jQuery對HTML的處理方式 這些HTML中包含來自不受信來源的元素

39、 以此來執行不受信任的代碼。該漏洞具有廣泛影響，可以影響到使用jQuery的各種系統，包括Debian Linux、Fedora、Drupal和Oracle產品。33%33%30%29%29%27%21%18%18%13%1.2.3.4.5.6.7.8.9.10.CVE/BDSA具有CVE/BDSA的代碼庫百分比CVE-2020-11023(BDSA-2020-0964)CVE-2020-11022(BDSA-2020-0686)CVE-2019-11358(BDSA-2019-1138)BDSA-2014-0063CVE-2015-9251(BDSA-2017-2930)BDSA-2015-

40、0567CVE-2020-23064(BDSA-2020-4841)CVE-2023-45133(BDSA-2023-2769)CVE-2020-7656(BDSA-2020-1173)CVE-2022-25883(BDSA-2023-2207)2025年度開源安全和風險分析報告|16與CVE-2020-11023關聯的CWE是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”。與這個列表中的許多其他CVE一樣，該CWE突出了一個常見的安全問題，即用戶提供的輸入在納入網頁之前沒有得到適當的凈化。由于未能消除潛在的惡意輸入，攻擊者可以在用戶的瀏覽器中注入并執行惡意腳本。2.CVE-20

41、20-11022 CVE-2020-11022是jQuery中的另一個XSS漏洞，影響到從1.2（包括1.2）到3.5.0之間的版本。該漏洞允許攻擊者利用jQuery的DOM操作方法來處理輸入，從而將JavaScript代碼注入網頁。與CVE-2020-11023不同，該漏洞未列在CISA的“已知被利用漏洞目錄”中，這表明它造成的直接風險可能較低。與CVE-2020-11022關聯的CWE也是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”。3.CVE-2019-11358 CVE-2019-11358涉及3.4.0之前的jQuery版本的原型污染。當攻擊者可以操縱對象的原型時，就

42、會發生原型污染，可能影響到從該原型繼承的所有對象，從而導致意外行為、拒絕服務、甚至任意代碼執行。與CVE-2019-11358關聯的CWE是“CWE-1321：對象原型屬性修改控制不當（原型污染）”。這個CWE是“CWE-913：動態管理的代碼資源控制不當”的子版本，后者對程序執行期間管理代碼資源相關的弱點進行了廣泛的分類。4.BDSA-2014-0063這是一個較早的漏洞，于2014年1月首次作為問題提出，與jQuery中因缺乏用戶輸入驗證而導致的潛在XSS漏洞有關。該漏洞沒有關聯的CVE。該漏洞允許攻擊者注入任意Web腳本并竊取受害者的會話cookie。該漏洞在jQuery 3.0.0-r

43、c1中得到了緩解。但是，此類緩解并不能清除惡意輸入，仍然允許腳本執行。由于解析器的默認行為發生了變化，因此，如果上下文未指定為“空/未定義”(null/undefined)，則創建一個新文檔。這將延遲解析后的HTML執行，直到將其注入文檔，從而讓工具才有機會在函數調用后遍歷已創建的DOM、并刪除不安全的內容。與我們10大漏洞中的其他幾個漏洞一樣，與BDSA-2014-0063關聯的CWE也是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”。5.CVE-2015-9251 CVE-2015-9251是jQuery中的XSS漏洞，影響3.0.0之前的版本。（在本報告發布時，jQuery

44、的當前穩定版本是2023年8月發布的3.7.1。）當在沒有指定dataType選項的情況下發出跨域AJAX請求時，就會出現此漏洞，從而允許執行惡意JavaScript響應。雖然與CVE-2015-9251關聯的主要CWE是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”，但請注意，它也與“CWE-94：代碼生成控制不當（代碼注入）”和“CWE-74：下游組件使用的輸出中特殊元素轉義不當（注入）”有關。2025年度開源安全和風險分析報告|176.BDSA-2015-0567這是另一個沒有對應CVE的較早期漏洞，該漏洞會導致jQuery容易受到任意代碼執行的攻擊。當jQuery版本使用

45、未打補丁的UglifyJS解析器時，很容易受到通過精心編制的JavaScript文件發起的任意代碼執行攻擊。最終，攻擊者將可以運行流氓代碼。該漏洞已在1.12.0和2.2.0中修復。與這個BDSA關聯的CWE是“CWE-1395：依賴易受攻擊的第三方組件”。7.CVE-2020-23064CVE-2020-23064是一個XSS漏洞，存在于2.2.0到3.5.0版本的jQuery中。該漏洞允許攻擊者利用元素處理之便執行任意代碼。它的CVSS v3基本得分為6.1，嚴重程度為中等。與CVE-2020-23064關聯的CWE是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”。8.CVE

46、-2023-45133CVE-2020-7656是jQuery中的另一個XSS漏洞，影響1.9.0之前的版本。出現此漏洞是因為加載方法無法正確處理和刪除包含空白字符的 HTML標記，從而可能允許執行惡意腳本。與CVE-2020-7656關聯的CWE是“CWE-79：網頁生成時對輸入的轉義處理不當（跨站腳本）”。9.CVE-2020-7656CVE-2023-45133是常見的JavaScript編譯器Babel中的漏洞。它會影響babel/traverse包和所有版本的babel-traverse。在編譯過程中，當處理為了利用該漏洞而精心編制的惡意代碼時，可能會導致任意代碼執行攻擊。CVE-2

47、023-45133與兩個CWE相關聯：“CWE-697：比較不當”和“CWE-184：不允許的輸入列表不完整”。這些CWE表明，該漏洞源于編譯過程中對特定輸入的不當驗證和處理。10.CVE-2022-25883CVE-2022-25883是某些Node.js系統中使用的semver包中的正則表達式拒絕服務(ReDoS)漏洞。該漏洞影響semver包的特定版本，當不受信任的用戶數據作為一個范圍處理時，可能會觸發該漏洞。ReDoS攻擊利用正則表達式中的漏洞，導致處理時間過長，并可能通過消耗系統資源導致拒絕服務。與CVE-2022-25883關聯的CWE是“CWE-1333：低效正則表達式復雜度”。

48、該漏洞會嚴重影響系統性能和穩定性，可能會中斷服務和應用。2025年度開源安全和風險分析報告|18數據能告訴我們什么了解CWE對開發人員和安全專業人員都至關重要。CWE提供了一種標準化的方法來分類和描述軟件弱點，從而在應對安全風險方面實現了更好的溝通和協作。通過了解常見弱點，開發人員可以實施安全編碼實踐來防止漏洞，安全團隊可以有效地識別和減輕潛在威脅。我們的研究顯示，CWE-79以及所有與jQuery跨站腳本攻擊相關的CVE都很常見，突出了輸入驗證在web開發中的重要性。不能正確處理用戶輸入可能會產生嚴重的后果。jQuery并非天生不安全。事實上，它是一個維護良好的開源庫，擁有巨大的用戶、開發人

49、員和維護人員社區。但根據我們的審計，jQuery是最有可能存在漏洞的組件 事實上，在我們掃描的所有代碼庫中，我們在近三分之一的代碼庫中發現了易受攻擊的jQuery組件 盡管這些漏洞影響的都是過時的jQuery版本，并且都有可用的補丁。對jQuery用戶（實際上是所有的開源用戶）來說，了解與過時軟件版本相關的潛在安全風險并采取措施應對它們非常重要。對于開發人員，我們的數據強調了需要優先考慮輸入驗證和凈化技術，以防止跨站腳本和其他注入攻擊。利用安全分析工具（例如Coverity Static Analysis和生產安全DAST工具Black Duck Continuous Dynamic）來識別由

50、于對用戶提交的數據（如表單輸入或API參數）檢查不足而產生的潛在漏洞，可以幫助確保只接受符合預期的數據格式和值，從而降低SQL注入、跨站腳本和其他注入攻擊的風險。及時了解安全建議并及時修補易受攻擊的軟件，對于最大限度地降低漏洞利用風險至關重要。定期更新庫和框架，如jQuery和Babel，對于確保系統免受已知漏洞的攻擊至關重要。行業特定的洞察如第5頁圖1所示，從漏洞的角度看，高風險的垂直領域包括“互聯網和移動應用”（該領域掃描的代碼庫100%包含高風險漏洞）、“營銷科技”（88%的代碼庫包含高風險漏洞）、“計算機硬件和半導體”（87%的代碼庫包含高風險漏洞）、“教育科技”和“企業軟件/SaaS

51、”（86%的代碼庫含有高風險漏洞）。值得注意的是，在所有16個垂直領域中，包含高風險漏洞的代碼庫占比最低的是“能源/清潔科技”，為60%?？偟膩碚f，每個垂直領域都有超過50%的代碼庫包含高風險漏洞，使得它們成為極具吸引力的攻擊目標。2025年度開源安全和風險分析報告|19開源許可所有的Black Duck審計都會檢查開源許可證合規性。2024年，Black Duck審計團隊進行了965次審計。本節的數據就是基于這些評估得出的。存在許可證沖突的代碼庫百分比：56%包含開源代碼但沒有許可證或自定義許可證的代碼庫百分比：33%有效的開源管理需要許可和安全合規。您知道正在使用的開源組件和庫是受許可證管

52、理的，但您知道這些許可證的詳細信息嗎？也許更重要的是，您的高管和法律顧問是否了解這些許可證詳情與專有軟件的關系？即使您的軟件中只有一個不符合規定的許可證，也可能導致法律問題、失去利潤豐厚的知識產權、耗時的補救工作，甚至延遲產品上市。就我們的審計結果而言，56%的客戶代碼庫存在許可證沖突，這為上述潛在情況埋下了隱患。沖突、變體和缺乏許可證如何產生風險在美國和其他地區，創意作品（包括軟件）默認受獨家版權保護。未經創建者/作者以許可證形式提供的明確授權，任何人對該等軟件的使用、復制、分發或修改都是違法的。對于開源軟件，當開源組件的許可證與為整個項目或代碼庫聲明的整體許可證沖突時，就會出現聲明的許可證

53、沖突。當商業項目中包含具有限制性許可證 GNU通用公共許可證(GPL)的組件時，通常會發生這種情況，可能需要發布整個項目的源代碼。聲明沖突的嚴重程度可能各不相同；可能適用于整個項目，也可能僅適用于特定文件，具體取決于許可證的范圍。當項目中的兩個開源許可證彼此不兼容時，就會發生組件許可證沖突?？紤]到大多數開源許可證的編寫方式，即使較大的作品中只包含一小段許可代碼（片段），也可能出現沖突。從歷史上看，當開發人員從包含問題許可證的開源項目剪切和粘貼內容時，就會發生這種情況。如今，隨著使用開源代碼訓練的生成式AI模型的興起，AI工具可能會在不考慮許可的情況下使用片段。標準開源許可證的變體或定制版本也可

54、能對被許可方提出他們不希望看到的要求，并且需要對可能的知識產權問題或其他影響進行法律評估。JSON許可證經常作為示例來說明何為自定義許可證。JSON許可證基于寬松的MIT許可證，在此基礎上增加了“軟件應當用于善意，而非惡意”的限制。雖然這種說法值得稱贊，但其含義的模糊性有待解釋，許多顧問都不建“要想成為一名程序員，了解法律和了解技術同樣重要?！盓ric Allman2025年度開源安全和風險分析報告|20議公司使用具有此類許可證的軟件，特別是在并購的背景下。自2016年以來，Apache基金會一直禁止在其任何項目中使用具有此類許可證的軟件。在我們2024年審計的代碼庫中，33%的代碼庫使用的代

55、碼要么沒有可識別的許可證，要么使用了定制許可證。對開發人員來說，開發人員公開發布代碼但其中沒有明確的服務條款或軟件條款的情況并不罕見。開發人員通過修改或增加標準許可條款（例如“是善意而非惡意”）或在代碼注釋中添加使用、義務和限制條款來授予代碼使用權限的情況也不罕見。這些類型的修改通常都需要法律審查。傳遞性依賴對許可證沖突的影響我們的審計發現，近30%的組件許可證沖突是由傳遞性依賴（即直接依賴項和整個軟件運行所需的組件）引起的。如果傳遞性依賴項使用諸如GPL這樣的強限制性許可證，那么，即使直接依賴項具有更寬松的許可證，也可能影響整個應用的許可。許多限制性許可證通常要求衍生作品也按照相同條款獲得許

56、可。2024年的十大開源許可證許可證包含許可證的掃描數據庫百分比風險*是否經OSI批準MIT License92%低是Apache License 2.090%低是BSD 3-Clause“New”or“Revised”License85%低是BSD 2-Clause“Simplified”License74%低是ISC License61%低是Generic Public Domain57%因使用而異是GNU Lesser General Public License v2.1 或更高版本48%高是The Unlicense47%低是Creative Commons Zero v1.0 Un

57、iversal46%因使用而異否Mozilla Public License 2.045%中是*風險分類是指導方針，不應用于決定是否使用開源軟件。有關許可證合規性的指導，請咨詢貴公司的政策和/或法律團隊。圖7：十大開源許可證2025年度開源安全和風險分析報告|21何為寬松式(Permissive)、弱著佐權(Weak Copyleft)和互惠開源許可證？低風險：寬松式許可證寬松式許可證通常沒有很多限制條件，而是要求您在發布自己的軟件時保留版權聲明。這意味著您可以使用和更改開源軟件，只要保持版權聲明不變即可。MIT和Apache許可證便是目前使用最廣的這一類許可證。我們將寬松式許可證評定為低風險

58、許可證。中風險：弱著佐權許可證著佐權許可證通常包括互惠義務，規定修改和擴展版本需要在與原始版本相同的條款和條件下發布。弱著佐權許可證通常要求您在給定許可證的相同條款下修改源代碼。其中一些許可證明確定義了何為修改。例如，許可證可能規定，將未修改的開源代碼復制到專有代碼中即為修改。為了遵守許可證義務，您必須發布源代碼（原始的、修改過的和新添加的）。例如，Mozilla公共許可證便是常用的此類開源許可證。我們將半寬松式許可證評定為中風險許可證。高風險：互惠/著佐權許可證一些常用的開源許可證，如GNU General Public License v2.0或更高版本以及GNU Lesser Gener

59、al Public License v3.0或更高版，限制性都很強。根據您將開源軟件與專有軟件集成的方式，您可能面臨重大風險。在最糟糕的情況下，您可能需要在相同的許可證下發布您的專有軟件-免版稅。我們將限制性許可證評定為高風險許可證。如何通過SCA管理開源許可證風險如果您構建打包的、嵌入式的或商用的SaaS軟件，那么，開源許可證合規性應該是貴組織重點關注的問題。您需要確定您使用的開源組件的許可證類型和條款，并確保它們與軟件的打包和分發方式一致。即使公司的軟件不是商業產品，只在內部使用，也仍然受軟件中開源組件的許可條款約束。管理風險的第一步是使用自動化SCA工具，對軟件中的所有開源組件、版本及其

60、相關許可證創建最新的、準確的SBOM。您應編譯與這些組件相關的許可證文本，以標記與軟件分發和許可證要求相沖突的任何組件，或者與軟件中其他組件使用的許可證相沖突的組件。您應確保履行所有的許可義務，這一點非常重要，因為即使是最寬松式開源許可證也仍然涉及歸屬權義務。Black Duck SCA使開發、安全和合規團隊能夠管理使用開源代碼帶來的風險。Black Duck的多因素開源檢測和包含超過870萬個組件的知識庫可以為任何應用或容器提供準確的SBOM，包括許可信息。盡管大多數開源組件都使用最常用的許可證，但Black Duck提供了額外的信息層，包含2,750多個其他開源許可證的數據，這些許可證可能

61、會對貴團隊編寫的軟件施加限制。使用Black Duck跟蹤和管理開源組件，可以幫助您避免導致代價高昂的訴訟或損害寶貴知識產權的許可證問題。2025年度開源安全和風險分析報告|22按行業劃分的許可證沖突情況如本報告第6頁所述，圖2突出顯示了不同行業的代碼庫中普遍存在的許可證沖突，表明了企業主動識別許可證的重要性，以避免因軟件中的許可證沖突而帶來代價高昂的法律和運營挑戰。行業存在許可證沖突的代碼庫百分比圖2：存在許可證沖突的代碼庫（按行業劃分）教育科技大數據、AI、BI和機器學習金融服務和金融科技互聯網和移動應用計算機硬件和半導體航空航天、汽車、運輸和物流網絡安全零售和電子商務營銷科技企業軟件/S

62、aaS制造業、工業和機器人虛擬現實、游戲、娛樂和媒體互聯網和軟件基礎架構物聯網醫療保健、健康科技和生命科學能源和清潔科技71%71%66%64%63%61%58%57%56%54%53%51%50%48%47%37%2025年度開源安全和風險分析報告|23高風險領域 在大數據和AI、金融服務和金融科技以及計算機硬件等技術密集型行業，代碼庫中存在許可證沖突的比例遠高于其他行業。這可能是因為這些行業嚴重依賴軟件和服務，而這些應用本身依賴于開源組件。許多行業也傾向于以內部產品的形式許可和分發其軟件。大多數限制性許可證專門適用于以這種方式分發的軟件。其他許可證沖突較少的行業可能更趨向于基于訂閱的部署或

63、SaaS類型的部署，這些部署傳統上不被視為“分發”，也不受相同許可條款的約束。教育科技行業也顯示出驚人的高比例，這表明教育軟件和平臺存在潛在的許可問題。得益于在線學習和數字教育工具，教育科技行業在過去幾年中經歷了快速增長。許多教育科技公司，尤其是初創公司和小公司，在軟件許可方面的資源和專業知識很有限。中風險 航空航天、網絡安全、制造業和企業軟件等行業表現出中等程度的風險。雖然這一比例低于高風險群體，但他們仍有相當大的幾率遇到許可問題。低風險（但不是沒有風險）醫療保健和能源等行業的許可證沖突比例較低。然而，這并不意味著他們對這些問題有免疫。例如，醫療保健組織依賴于各種各樣的軟件，包括電子健康記錄

64、和醫療成像系統，以及遠程醫療平臺和AI驅動的診斷工具。這種復雜的生態系統通常涉及集成大量的第三方組件和庫，從而增加了許可問題發生的幾率。并購注意事項如果貴公司計劃在某個時候參與并購交易，無論是作為賣方還是買方，您都希望讓貴組織的知識產權顧問參與進來，或尋求外部法律建議，因為理解許可條款和條件以及識別各種許可證之間的沖突可能具有挑戰性。第一步就走對至關重要，尤其是您構建的是打包或嵌入式軟件的情況下，因為對于已發貨的軟件，許可證條款通常更明確，事后更難補救。了解開源代碼在公司代碼庫中的位置對于正確管理其使用和復用、確保軟件許可證合規以及及時修補漏洞至關重要 這些都是降低業務風險的必要步驟。如果您是

65、科技并購交易的買方，開源審計應該是軟件盡職調查過程的一部分。代碼審計使買方能夠了解軟件中可能影響知識產權價值的風險，以及應對這些風險所需的補救措施。對于希望更好地了解代碼組成的公司來說，開源審計也是非常重要的。例如，使用Black Duck SCA等一系列工具，專業審計人員可以全面識別代碼庫中的開源組件，并標記與這些組件相關的法律合規問題，根據問題的嚴重程度對其進行優先級排序。審計可以發現影響開源組件的已知安全漏洞，以及版本、副本和組件開發活動狀態等信息。審計還能提供有關目標軟件開發過程復雜程度的線索。如今，開源無處不在，如果公司不能很好地管理軟件開發的這一部分，就會引發其他組成部分的管理問題

66、。2025年度開源安全和風險分析報告|24在交易條款確定之前，買方需要識別目標代碼中有問題的開源代碼，而可信的第三方審計是獲得深入、全面視圖的最佳方式。即使是識別獲得許可的開源代碼也是有價值的，因為買方希望確保他們能夠遵守這些許可證的歸屬權要求。賣方應該準備好回答有關其代碼組成及其如何管理開源安全性和許可證風險的問題。積極主動的賣方可能會提前進行審計，以避免在盡職調查中出現意外，尤其是在考慮到典型公司代碼中未知開源代碼數量很大的情況下。通過識別開源代碼以及第三方組件和許可證，開源審計可以提醒貴公司并購交易中可能出現的法律和安全問題。請切記，巨大的貨幣和品牌風險可能隱藏在買方所獲得代碼的開源組件

67、中。作為買方盡職調查的一部分，必須將評估該等風險納入到并購交易決策流程中。避免意外減輕法律風險了解可能影響軟件資產價值的風險在潛在問題影響到交易之前解決它們在交易條款中包含適當的保護措施規劃賣方/買方代碼的集成和修復2025年度開源安全和風險分析報告|25影響風險的維護和運營因素理想情況下，我們所有人都只會使用由強大社區支持的開源組件。畢竟，當開源軟件首次推出時，大型且充滿活力的開發者社區的支持是開源軟件的主要優勢之一。專門的開發人員社區可以提供更好的代碼質量和安全性，同時促進他們所監督的項目定期改進。遺憾的是，對許多開源項目來說，這種情況從未發生過。正如Linux基金會的 免費和開源軟件第三

68、次普查報告（該報告使用了來自Black Duck和其他供應商的SCA數據）指出，當今使用最廣泛的開源軟件大多是由少數貢獻者開發和維護的，而不是大家普遍認為的成千上萬甚至數百萬的幕后開發人員。實際上，在幾乎所有開源軟件項目中，致力于確保更新 包括功能改進以及安全性和穩定性更新 的少數貢獻者都會隨時間的推移而減少。當維護人員停止維護項目時，后果之一便是安全風險增加，正如我們掃描數據所顯示的那樣。過時的組件 相當高比例的代碼庫(90%)包含過時4年以上的開源組件。這表明過時的依賴關系問題普遍存在，并可能導致安全漏洞和兼容性問題不活躍的組件 同樣高比例的代碼庫(91%)包含在過去兩年中沒有任何維護或更

69、新的組件。這表明許多應用和Web服務依賴于不再更新的開源軟件，這可能會使它們容易受到未被發現或未修補的安全漏洞攻擊。79%的代碼庫包含在過去24個月內沒有進行任何維護或更新、但卻是最新版本的組件。這表明即使是最新的組件也可能沒有得到積極的維護。88%的代碼庫包含在過去24個月內沒有進行任何維護或更新、同時也不是最新版本的組件。使用這些組件的組織機構將面臨更大的風險。90%91%79%88%90%的代碼庫包含過時4年以上的開源組件91%的代碼庫包含在過去兩年中沒有任何維護或更新的組件79%的代碼庫包含在過去24個月內沒有進行任何維護或更新、但卻是最新版本的組件88%的代碼庫包含在過去24個月內沒

70、有進行任何維護或更新、同時也不是最新版本的組件2025年度開源安全和風險分析報告|26版本滯后 大多數代碼庫(91%)包含的OSS都不是此類特定組件的最新可用版本 更糟糕的是，90%的代碼庫包含比最新版本落后10個以上版本的開源組件未能使用最新版本（通常包括重要的錯誤修復和安全補?。黾语L險和技術債務。不維持開源組件的最新狀態是有正當理由的。主要版本更新可能會引入現有代碼的重大更改，特別是在您已經落后了幾個版本的情況下。有時，調整代碼因過于繁瑣是不可行的。更新也可能因為涉及開發、測試和部署活動而非常耗時。資源有限的小型團隊或項目可能需要優先處理更關鍵的任務。但是，正如我們在發布OSSRA報告

71、的十年中所指出的那樣，開源軟件不同于商業軟件 不是更差，也不是更好，而是不同 在維護方面需要不同的技術。例如，所有商業軟件的補丁和更新都是主動“推送”給用戶的，或者他們至少會收到供應商的通知，告知有新的更新可供下載使用。但這種情況在開源領域很少出現，用戶基本需要自己去主動了解組件的狀態。鑒于這一現實，您如何才能及時了解軟件的最新狀況呢？關注項目網站和存儲庫：大多數的開源項目都有網站、博客或存儲庫（如GitHub），在那里發布新版本并提供變更日志。訂閱它們的郵件列表或RSS提要可以獲取最新信息。然而，鑒于當今典型應用中開源組件的數量，手動跟蹤是不切實際的，因此，自動化方法變得更加關鍵。使用包管理

72、器：包管理器（如npm、pip或Bundler）通常會提供有關可用更新的通知，并可以自動執行更新流程。我們掃描中發現的絕大多數開源代碼都來自npm，它提供各種各樣的工具來升級軟件包。例如，運行npm outdated會生成一個包含可用更新包的列表。利用版本跟蹤工具：諸如Dependabot或Renovate 這樣的工具可以監控項目的依賴關系，并自動創建帶有更新的拉取請求。使用識別和監控工具：諸如Black Duck SCA這樣的安全工具可以掃描您的代碼庫，查找開源組件中的漏洞，并在安全補丁的更新可用時提醒您。只有一種可行的解決方案可以讓您了解所使用的開源代碼。您需要一份準確且全面的開源代碼清單

73、以及自動化流程，以監控軟件中開源代碼的漏洞、升級和整體健康狀況。2025年度開源安全和風險分析報告|27結語：發生變化的事物越來越多過去10年中，“您知道您的代碼中有什么嗎？”一直都是Black Duck 開源安全和風險分析報告 的主題。自2015年以來，雖然開源組件的使用發生了變化 大多數情況下都是顯著增加 但這個問題始終未變。無論您位于軟件供應鏈的哪一端 無論是在漏斗的頂部還是底部，無論是自己開發軟件還是使用來自不同供應商的軟件，也無論該軟件是運行在本地、云、嵌入式還是移動設備上 您的軟件中包含開源代碼是幾乎可以肯定的事情。您是否確切地知道這些OSS組件是什么？它們是否會帶來安全性、代碼質

74、量或許可證風險？當97%的代碼包含開源組件時，需要將代碼可視性視為優先事項。當91%的代碼庫使用遠遠落后于當前版本的開源組件時，每個人都需要更加努力地保持代碼最新，尤其是對常用的開源組件。OSS在現代軟件中壓倒性的存在：我們評估的97%的商業代碼庫中包含開源代碼，其中一些行業更是高達100%。貴公司是否屬于這些高風險行業？您無法手動管理開源：過去四年中，平均每個應用中的開源文件數量增加了兩倍。傳遞性依賴是代碼復雜性的主要因素之一。我們的掃描發現，64%的開源組件是傳遞性依賴項。安全漏洞是普遍存在的風險：大多數(81%)被掃描的代碼庫中存在高風險或重大風險漏洞。其中許多漏洞源于過時的開源組件。許

75、多漏洞還源于特定的編碼弱點：我們發現的所有開源漏洞中有71%與輸入驗證不當有關。軟件物料清單(SBOM)對于代碼可視性至關重要：SBOM對于管理風險、漏洞、許可證合規、軟件質量和并購盡職調查至關重要。許可風險是一個常見問題：超過一半被審計的代碼庫(56%)存在許可證沖突問題，這通常是由于不兼容的可傳遞性依賴關系造成的。33%的代碼庫中包含沒有許可證或定制許可證的OSS組件。過時的組件是一個主要挑戰：大多數被審計的代碼庫(91%)包含過時的組件，90%的代碼庫包含比最新版本落后10個版本以上的組件?！帮L險源于您不知道自己在做什么”Warren Buffet and Charles Munger圖

76、8：2015年度OSSRA報告詳情2025年度開源安全和風險分析報告|28主要建議實施SCA：使用SCA工具生成SBOM、識別漏洞并管理許可證合規。為風險管理分配優先級：關注可能影響最重要業務領域的高風險漏洞和許可證問題。定期更新OSS：及時了解安全建議，及時修補易受攻擊的軟件，特別是jQuery和其他常用的庫。建立安全編碼實踐：專注于第三方代碼的輸入驗證、凈化和定期安全測試。監控OSS維護工作：通過跟蹤項目網站、使用包管理器和利用自動化安全服務來了解開源組件的更新。創建SBOM：制作一個詳細的SBOM，列出代碼中的所有開源組件，包括許可證、版本和來源。將OSS管理集成到SDLC中：遵循CIS

77、A和NIST闡述的最佳實踐，將開源管理納入您的安全軟件開發框架。如果您有并購計劃，請利用Black Duck審計服務來審查您的收購事宜：您需要借助可信賴的第三方來訪問被收購方的源代碼，并且需要工具和專業知識為這些高風險場景提供必要的洞察。正如我們在本報告開頭所寫的那樣，雖然開源軟件提供了許多好處，但它也帶來了必須積極管理的重大風險。您需要全面了解其軟件供應鏈、穩健的安全實踐以及主動的許可和維護方法，以避免潛在問題。在當今的軟件環境中，實施SCA工具、SBOM和適當的衛生實踐并非可有可無，而是必須做到。通過采納我們的建議，您可以降低風險，并繼續安全有效地利用開源軟件的優勢。您需要明確地知道代碼中

78、有什么。2025年度開源安全和風險分析報告|29貢獻者2025年度 開源安全和風險分析報告 是Black Duck在審計、CyRC、專業服務和營銷團隊的幫助下制作的。特別感謝Nancy Bernstein、Conor Brolly、Kevin Collins、Scott Handy、Clement Pang、Merin McDonnell、Mike McGuire、Phil Odence、Liz Samet、Mark Van Elderen和Jack Taylor。作者：Fred Bals 關于Black DuckBlack Duck提供業界最全面、最強大、最值得信賴的應用安全解決方案組合。我們在幫助世界各地的公司快速保護其軟件、在其開發環境中有效集成安全性以及安全地使用新技術進行創新方面有著無與倫比的記錄。作為軟件安全領域公認的領導者、專家和創新者，Black Duck能夠滿足您在建立軟件信任方面的所有需求。如想了解更多信息，請訪問。2025 Black Duck Software,Inc.版權所有，保留所有權利。Black Duck是Black Duck Software,Inc.在美國和其他國家的商標。本文提及的所有其他名稱均為其各自所有者的商標或注冊商標。2025年1月。2025年度開源安全和風險分析報告|30