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

1、II目錄一、概述.1一、概述.11、軟件供應鏈安全攻擊手段依然花樣百出.12、國內企業軟件供應鏈安全狀況有所改善.4二、國內企業自主開發源代碼安全狀況.6二、國內企業自主開發源代碼安全狀況.61、編程語言分布情況.62、典型安全缺陷檢出情況.7三、開源軟件生態發展與安全狀況.8三、開源軟件生態發展與安全狀況.81、開源軟件生態發展狀況分析.92、開源軟件源代碼安全狀況分析.11（1）編程語言分布情況.11（2）典型安全缺陷檢出情況.123、開源軟件公開報告漏洞狀況分析.13（1）大型開源項目漏洞總數及年度增長 TOP20.13（2）主流開源軟件包生態系統漏洞總數及年度增長 TOP20.164、

2、開源軟件活躍度狀況分析.19（1）68.7%的開源軟件項目處于不活躍狀態，比例下降.19II（2）版本頻繁更新的項目較去年增長 21.6%.205、關鍵基礎開源軟件分析.21（1）主流開源生態關鍵基礎開源軟件 TOP50.21（2）關鍵基礎開源軟件的漏洞披露情況未見改善.24（3）關鍵基礎開源軟件的整體運維風險有所改觀.256、NPM 生態中惡意開源軟件分析.26（1）超 95%的惡意開源組件以竊取敏感信息為目標.26（2）典型惡意開源組件及惡意行為剖析.27四、國內企業軟件開發中開源軟件應用狀況.29四、國內企業軟件開發中開源軟件應用狀況.291、開源軟件總體使用情況分析.30（1）平均每個

3、軟件項目使用 166 個開源軟件，再創新高.30（2）最流行的開源軟件被 37.2%的軟件項目使用.312、開源軟件漏洞風險分析.32（1）存在容易利用的開源軟件漏洞的項目占比大幅下降.32（2）平均每個項目包含的已知開源軟件漏洞數明顯回落.33（3）影響最廣的開源軟件漏洞的影響范圍有所減小.35（4）20 多年前的開源軟件漏洞仍然存在于多個軟件項目中.363、開源軟件許可協議風險分析.37（1）最流行的開源許可協議在 46.9%的項目中使用.37III（2）超 1/5 的項目使用了含有超、高危許可協議的開源軟件.384、開源軟件運維風險分析.40（1）多個二三十年前的老舊開源軟件版本仍在使用

4、.40（2）開源軟件各版本使用依然混亂.41五、典型軟件供應鏈安全風險實例分析.42五、典型軟件供應鏈安全風險實例分析.421、多款主流操作系統供應鏈攻擊實例分析.422、PHP 軟件供應鏈攻擊實例分析.433、某國產數據庫供應鏈攻擊實例分析.45六、總結及建議.47附錄：奇安信代碼安全實驗室簡介.51六、總結及建議.47附錄：奇安信代碼安全實驗室簡介.511一、概述一、概述當前，軟件供應鏈安全依然是網絡安全中備受關注的方向，基于自研產品的技術能力和第一手實測數據，奇安信代碼安全實驗室繼續推出2024 中國軟件供應鏈安全分析報告，即本系列年度分析報告的第四期。軟件由自主開發的代碼與開源代碼等第

5、三方代碼集成后，形成混源代碼，然后通過編譯、連接等構建過程形成軟件產品，交付給用戶使用。在這一軟件供應鏈模型中，每個階段中的代碼或工件都可能引入安全問題，從而導致最終軟件供應鏈安全事件的爆發。本期報告仍以此模型為基礎，分析各階段的代碼安全問題對軟件供應鏈安全性的潛在威脅，分析內容分別在后續的國內企業自主開發的源代碼安全狀況、開源軟件生態發展與安全狀況、國內企業軟件開發中開源軟件應用狀況、典型軟件供應鏈安全風險實例分析等章節中呈現。在此基礎上，本報告還總結了趨勢和變化。與往年報告相比，本期報告在開源軟件生態發展與安全部分新增了對 NPM 生態中惡意開源軟件分析的內容；在典型軟件供應鏈安全風險實例

6、部分，通過實例再次驗證了因軟件供應鏈的復雜性，“外來”組件的“老漏洞”發揮“0day 漏洞”攻擊作用的狀況。感興趣的讀者可重點關注。1、軟件供應鏈安全攻擊手段依然花樣百出1、軟件供應鏈安全攻擊手段依然花樣百出過去的一年中，軟件供應鏈安全攻擊事件沒有絲毫減少的趨勢，2攻擊手段依然花樣百出。2023 年 10 月，安全人員分析發現了一種新型供應鏈攻擊。整個9 月，某黑客組織都在使用域名仿冒（Typosquatting）和星標劫持（Starjacking）技術向開源包管理器 PyPi 植入一系列惡意包，并引誘開發人員使用，而這些惡意包與 Telegram、AWS 和阿里云等熱門通信和電子商務平臺所使

7、用的流行軟件包高度對應，被認為是故意攻擊這些平臺的特定用戶。攻擊者可以攻陷平臺用戶設備，竊取金融和個人信息、登錄憑據等敏感數據，可能影響數百萬人。2023 年 12 月，AI 安全公司 Lasso Security 的研究人員，在 GitHub和 Hugging Face 平臺上發現了 1500 多個不安全的 API 訪問令牌，可用來訪問 772 個組織機構的倉庫，包括谷歌、微軟、VMware 等公司。其中部分令牌可幫助攻擊者獲得 Meta 公司 Bloom、Meta-Liama、Pythia 等大語言模型（LLM）倉庫的完全讀寫權限，攻擊者可利用該漏洞實施 LLM 訓練數據投毒、模型和數據集

8、竊取等惡意行為，從而將使用這些倉庫把 LLM 能力集成到應用和運營中的組織置于供應鏈風險中，危及數百萬下游用戶的安全。2024 年 2 月，Cycode 研究團隊披露了谷歌重要的開源構建和測試工具 Bazel 的一個供應鏈安全漏洞的詳細信息。Bazel 所依賴的CICD 平臺 GitHub Actions 的工作流程中存在命令注入漏洞，可導致攻擊者將惡意代碼植入 Bazel 代碼庫、創建后門并影響 Bazel 用戶的生產環境。該漏洞可能影響數百萬個依賴于 Bazel 的項目和平臺，包括 Kubernetes、Angular、Uber、LinkedIn、Dababricks、Dropbox、Nv

9、idia3和谷歌自身等。2024 年 3 月初，安全研究人員發現，機器人平臺 Top.gg Discord托管在 GitHub 上的源代碼遭受到大規模嚴重供應鏈投毒攻擊，該平臺擁有超 17 萬成員。分析發現，攻擊者劫持了 Top.gg 的 GitHub 賬戶，上傳了至少 14 個偽造的惡意 Python 流行軟件包，并通過這些惡意軟件竊取用戶 Chrome、Edge 等瀏覽器中的敏感數據，包括瀏覽歷史記錄、信用卡詳細信息等，并通過出售信息實現盈利。攻擊者還試圖竊取 Telegram 會話數據以侵犯用戶隱私。這些攻擊同時也影響到了大量與平臺相關的開發人員。2024 年 3 月底，某開發人員在調查

10、 SSH 性能問題時發現了涉及XZ Util工具庫的供應鏈攻擊，溯源發現 SSH 使用的上游 liblzma 庫被植入了惡意后門漏洞（CVE-2024-3094），滿足一定條件時會解密流量里的 C2 命令并執行，從而使攻擊者能夠破壞 SSHD 身份驗證并遠程獲得對整個系統的未經授權訪問。XZ 是一種由 Tukaani 項目開發的高壓縮比數據壓縮格式，幾乎應用于每個 Linux 發行版中，包括社區項目和商業產品發行版，liblzma 是一個用于處理 XZ 壓縮格式的開源軟件庫。慶幸的是，該漏洞主要影響的 XZ 5.6.0 和 5.6.1 版本尚未被Linux 發行版廣泛集成，而且大部分是在預發行

11、版本中。2024 年 5 月，攻擊者通過與英國國防部核心網絡鏈接的一個外部系統，即由英國國防部的一家提供薪資處理服務的外部承包商維護的薪資處理系統，訪問了部分軍隊支付網絡，造成嚴重的信息泄露。據統計，攻擊者訪問了超過 22.5 萬名英國陸軍、海軍和皇家空軍現4役軍人、退役軍人和預備役軍人的姓名、銀行賬號詳情等個人信息。第三方承包商未能充分的保護系統是這次事件的主要誘因，而這一事件是在不到一年的時間內發生的第二起因外部承包商而導致的英國軍隊數據遭泄露事件。OpenSSH 可以在 CS 架構中提供網絡安全信道，被眾多企業用于遠程服務器管理和數據安全通信。2024 年 7 月初，網絡安全公司Qual

12、ys 發 現，OpenSSH 服 務 器 進 程 存 在“regreSSHion”漏 洞（CVE-2024-6387），攻擊者可利用其以 root 權限在基于 glibc 的Linux 系統上實現未認證的遠程代碼執行，從而實施系統完全接管、惡意程序安裝和后門創建等攻擊行為，嚴重程度堪比 Log4Shell。具不完全統計，互聯網上有 1400 多萬臺易受攻擊的 OpenSSH 實例，僅Qualys 公司自身的客戶中就有約 70 萬個暴露在互聯網上的系統可能易受攻擊。2、國內企業軟件供應鏈安全狀況有所改善2、國內企業軟件供應鏈安全狀況有所改善奇安信代碼安全實驗室通過數據分析發現，與以往歷年相比，2

13、023 年，國內企業自主開發軟件的源代碼高危缺陷密度明顯下降，并且因使用開源軟件而引入安全風險的狀況有所改善。盡管如此，軟件供應鏈安全風險的管控依然值得持續關注，需要更多的投入。1）國內企業自主開發軟件的源代碼高危缺陷密度明顯下降1）國內企業自主開發軟件的源代碼高危缺陷密度明顯下降通過對 2023 年國內企業自主開發源代碼的分析發現，雖然整體缺陷密度達到 12.76 個/千行，高于以往各年，但高危缺陷的密度為50.52 個/千行，比之前三年有明顯的下降；此外，NULL 引用類缺陷的檢出率為 25.7%，較往年也有較大降低。上述趨勢的出現，應該在很大程度上得益于以下措施的采?。很浖_發過程中，研

14、發企業對重點缺陷逐漸重視，針對重點問題的安全編碼規范進一步普及，并且代碼審計工具的使用持續推廣。2）國內企業因使用開源軟件而引入安全風險的狀況有所改善2）國內企業因使用開源軟件而引入安全風險的狀況有所改善2023 年，奇安信代碼安全實驗室對 1763 個國內企業軟件項目中使用開源軟件的情況進行分析發現，平均每個項目使用了 166 個開源軟件，數量再創新高。但另一方面，平均每個項目存在 83 個已知開源軟件漏洞，含有容易利用的開源軟件漏洞的項目占比為 68.1%，以上兩項指標與去年相比降幅較大；此外，存在已知開源軟件漏洞、高危漏洞、超危漏洞的項目占比分別為 88.0%、81.0%和 71.9%，

15、與去年相比均有所下降。其他方面，如項目中存在古老開源軟件漏洞、老舊開源軟件版本使用、同一開源軟件各版本使用混亂等方面的狀況基本與之前歷年持平?？傮w而言，國內企業使用開源軟件的安全狀況有所好轉。雖然從趨勢來看，上述的軟件供應鏈安全問題有一定程度的緩解，但另一方面，這些指標數據仍處于高位，軟件供應鏈的安全問題并沒有得到根本性的改變。值得高興的是，越來越多的機構和企業開始關注并實施軟件供應鏈的安全，一些機構和企業基于規范的流程和實踐，落地了相應的解決方案和檢測平臺。但就目前的形勢而言，這些經驗、方法和工具還需要進一步的持續完善、推廣和應用。6二、國內企業自主開發源代碼安全狀況二、國內企業自主開發源代

16、碼安全狀況源代碼的安全是軟件供應鏈安全的基礎。2023 年全年，奇安信代碼安全實驗室對 1858 個國內企業自主開發的軟件項目的源代碼進行了安全缺陷檢測，檢測的代碼總量為 408909802 行，共發現安全缺陷 5216473 個，其中高危缺陷 211355 個，整體缺陷密度為 12.76 個/千行，高危缺陷密度為 0.52 個/千行。與以往歷年相比，整體缺陷密度升高較快，但高危缺陷密度有較大幅度的降低。這應該與開發者對高危缺陷類型的重點防范及相應安全編碼規范的使用有關。1、編程語言分布情況1、編程語言分布情況在 1858 個國內企業自主開發的軟件項目中，共使用了 17 種編程語言，使用項目數

17、排名前 3 的分別為 Java、C/C+和 Python，對應的軟件項目數量分別為 1258 個、246 個和 118 個，Python 取代 NodeJS7再次回到第三的位置。Java 語言項目占比達 67.7%，但低于去年的76.1%。國內企業在進行軟件開發時，Java 語言仍然最受歡迎。編程語言的分布情況如下圖所示。2、典型安全缺陷檢出情況2、典型安全缺陷檢出情況對 1858 個軟件項目的源代碼缺陷檢測結果進行分析和統計發現，注入、密碼管理、日志偽造、跨站腳本、NULL 引用、配置管理、輸入驗證、資源管理、路徑遍歷、API 誤用等十類典型安全缺陷的總體檢出率（即含有某類缺陷的軟件項目數占

18、項目總數的比例）為 71.1%，與去年的 74.1%基本持平。每類典型缺陷歷年的檢出率及對比情況如下圖所示。8可以看出，輸入驗證類和跨站腳本類缺陷的檢出率較高，依然排在前兩位，特別是輸入驗證類缺陷，檢出率依舊高達 49%；同時，配置管理類和日志偽造類缺陷的檢出率依然排在最后兩位；與過去歷年相比，NULL 引用類缺陷的檢出率有較大下降，這可能與研發人員對此類問題的特別關注有關；其他類型缺陷的檢出率在正常的波動范圍內。國內企業在自主開發軟件時，應繼續關注針對這些缺陷類型的代碼修復問題。三、開源軟件生態發展與安全狀況三、開源軟件生態發展與安全狀況開源軟件在現代軟件開發中持續發揮著基礎支持的作用。本期

19、報告除了延續開源軟件生態發展狀況、開源軟件源代碼安全狀況、開源軟件公開報告漏洞狀況、開源軟件活躍度狀況、關鍵基礎開源軟件分析五部分內容外，在對 2023 年開源軟件生態發展與安全狀況進行綜合分析時，還增加了針對 NPM 生態中惡意開源軟件的分析。91、開源軟件生態發展狀況分析1、開源軟件生態發展狀況分析根據奇安信代碼安全實驗室的監測和統計，2022 年底和 2023 年底，主流開源軟件包生態系統中開源項目總量分別為 5499977 和7959049，一年間增長了 44.7%，增速迅猛；截至 2023 年底，主流開源軟件包生態系統中平均每個開源項目有 11.3 個版本，與前幾年基本持平。2023

20、 年開源軟件生態持續繁榮。對 Maven、NPM、Packagist、Pypi、Godoc、Nuget、Rubygems、Swift 等八個典型開源軟件包生態系統的具體分析如下：NPM 包生態開源項目數量和增速均位列第一。NPM 包生態開源項目數量和增速均位列第一。與前三年相比，NPM超越 Godoc，成為開源項目數增速最快的包生態系統。八個典型的開源軟件包生態系統中開源項目數量和增長率情況如下圖所示，其中開源項目數量最多的是 NPM 包生態系統，截至 2023 年底，其開源項目數量達到了 4170641，依然遠高于其他生態；開源項目數量增速最快的也是 NPM，2023 年一年間的項目總量增速

21、高達 79.1%，Godoc 的項目數增長也很快，達 58.1%。10Maven 包生態系統的開源項目開發者依然“最勤奮”，開源項目的平均版本數超過 23 個。Maven 包生態系統的開源項目開發者依然“最勤奮”，開源項目的平均版本數超過 23 個。截至 2023 年底，八個典型的開源軟件包生態系統的開源項目數量和版本數量如下表所示。其中，Maven 包生態系統平均每個開源項目有高達 23.6 個版本，比去年的 21.9 又有增加；NPM 和 Godoc 的開源項目平均版本數有所降低，分別從 13.4 和 9.4 降至 10.2 和 8.8。序號包生態系統2023 年項目數2023 年版本數平

22、均版本數1Maven7272281719158223.62NPM41706414269280610.23Packagist421935538080912.84Pypi536523554033010.35Godoc80906171078328.86Nuget640966809115112.67Rubygems17869314236318.08Swift948866665247.0112、開源軟件源代碼安全狀況分析2、開源軟件源代碼安全狀況分析2023 年全年,“奇安信開源項目檢測計劃”對 2248 個開源軟件項目的源代碼進行了安全檢測，代碼總量為 309522947 行，共發現安全缺陷 5108

23、161 個，其中高危缺陷 355721 個，整體缺陷密度為 16.50個/千行，高危缺陷密度為 1.15 個/千行。兩項缺陷密度指標較去年均有所下降。（1）編程語言分布情況（1）編程語言分布情況2023 年檢測的 2248 個開源項目中，共涉及 10 種編程語言，分別是 Java、C/C+、JavaScript、Python、Groovy、C#、Lua、Kotlin、Ruby 和 Go，編程語言的分布情況如下圖所示。被測項目中，使用 Java、C/C+、JavaScript 和 Python 四種語言開發的開源軟件約占 3/4。12（2）典型安全缺陷檢出情況（2）典型安全缺陷檢出情況對 224

24、8 個開源軟件項目的缺陷檢測結果分析發現，注入、密碼管理、日志偽造、跨站腳本、NULL 引用、配置管理、輸入驗證、資源管理、路徑遍歷、API 誤用等十類典型安全缺陷的總體檢出率為76.7%，與前兩年相比，有小幅升高。每類典型缺陷歷年的檢出率及對比情況如下圖所示。13可以看出，除了密碼管理類缺陷的檢出率較往年，特別是去年有較大幅度的提升外，其他均在正常的波動范圍內。從歷年數據來看，輸入驗證、路徑遍歷和資源管理三類缺陷的檢出率較高，均在 30%左右或以上；日志偽造、跨站腳本和配置管理三類缺陷檢出率較低，均在 20%左右或以下。3、開源軟件公開報告漏洞狀況分析3、開源軟件公開報告漏洞狀況分析根據奇安

25、信代碼安全實驗室監測與統計，截至 2023 年底，CVE/NVD、CNNVD、CNVD 等公開漏洞庫中共收錄開源軟件相關漏洞 64938 個，其中有 7107 個漏洞為 2023 年新增。（1）大型開源項目漏洞總數及年度增長 TOP20（1）大型開源項目漏洞總數及年度增長 TOP20截至 2023 年底，歷史漏洞總數排名前 20 的大型開源項目信息如下表所示。Linux Kernel、Chromium(Google Chrome)和 Mozilla Firefox14一如既往，依然排名前 3。序號大型開源項目主頁地址歷史漏洞總數1Linux Kernelhttps:/www.kernel.or

26、g/59832Chromium(Google Chrome)http:/www.chromium.org/33693Mozilla Firefoxhttps:/www.mozilla.org/en-US/firefox/26374Thunderbirdhttps:/ ESRhttps:/www.mozilla.org/en-US/firefox/enterprise/109710Adobe Flash Playerpluginhttps:/ 年一年間，公開報告漏洞數量增長排名前 20 的大型開源項目信息如下表所示，Linux Kernel 依然是一年來增加漏洞最多的項目，達到 607 個。序號

27、大型開源項目主頁地址2023年漏洞增量1Linux Kernelhttps:/www.kernel.org/6072Chromium(GoogleChrome)http:/www.chromium.org/2753Mozilla Firefoxhttps:/www.mozilla.org/en-US/firefox/1864GitLabhttps:/ ESRhttps:/www.mozilla.org/en-US/firefox/enterprise/1209Thunderbirdhttps:/ shell5819pimcorehttp:/ TOP20（2）主流開源軟件包生態系統漏洞總數及年度

28、增長 TOP20截至 2023 年底，主流開源軟件包生態系統中歷史漏洞總數排名前 20 的開源軟件信息如下表所示。排名前兩位的依然是 TensorFlow和 Chakra Core。序號開源軟件所屬包生態系統歷史漏洞總數1TensorFlowPypi4302Chakra CoreNuget347173Electron-Cross-platformdesktop application shellNPM3144Electron-Cross-platformdesktop application shellMaven2525JenkinsMaven2466Apache TomcatMaven200

29、7XWikiMaven1698TYPO3 CMSPackagist1639OpenSSLConan15910Ruby on RailsRuby12811Magento CorePackagist12212FFmpeg-iOSSwift12113phpMyAdminPackagist12014OpenSSLSwift11315DjangoPypi10716Dolibarr ERP&CRMPackagist10617keycloakMaven10218Drupal(core)Packagist9819phpMyFAQPackagist9420PlonePypi932023 年一年間，主流開源軟件包

30、生態系統中公開報告漏洞數量增長排名前 20 的開源軟件信息如下表所示。18序號開源軟件所屬包生態系統2023 年漏洞增量1XWikiMaven1112MattermostGodoc693phpMyFAQPackagist624Electron-Cross-platformdesktop application shellNPM585pimcorePackagist576jfinalMaven297incubator-airflowPypi288Go programming languageGodoc289.NET RuntimeNuget2710libTIFFConan2311mlflowCo

31、nda2212Electron-Cross-platformdesktop application shellMaven2213mlflowPypi2214XWiki PlatformMaven2215TensorFlowPypi2116keycloakMaven1817JenkinsMaven1718PrestaShopPackagist161919cryptographyConda1520aheinze/cockpitPackagist154、開源軟件活躍度狀況分析4、開源軟件活躍度狀況分析本年度報告依然把活躍度作為衡量開源軟件安全性的一個維度。太過活躍的開源軟件，其版本更新發布頻率過高，

32、會增加使用者運維的成本和安全風險；不活躍的開源軟件，一旦出現安全漏洞，難以得到及時的修復。因此，兩者都會給運維帶來一些風險。（1）68.7%的開源軟件項目處于不活躍狀態，比例下降（1）68.7%的開源軟件項目處于不活躍狀態，比例下降報告中依然將超過一年未更新發布版本的開源軟件項目定義為不活躍項目。2023 年全年，主流開源軟件包生態系統中不活躍的開源軟件項目數量為 5469685 個，占比為 68.7%，低于去年的 72.1%，與前年的 69.9%基本持平。對八個典型的開源軟件包生態系統進行分析和比較發現，NPM 從去年的 72.7%大幅度下降為 60.4%，Nuget 從去年的 54.3%迅

33、速上升至79.0%。除此之外，其他包生態系統中不活躍項目的占比均與去年持平。NPM 的不活躍項目數量依然最多，達 2520717 個，Rubygems 的不活躍項目占比依然最高，達 90.7%。具體數據見下表。序號包生態系統項目總數不活躍項目數不活躍項目比例1Maven72722850436269.4%2NPM4170641252071760.4%203Packagist42193532291576.5%4Pypi53652335848866.8%5Godoc80906160926475.3%6Nuget64096650621379.0%7Rubygems17869316214490.7%8S

34、wift948868375588.3%（2）版本頻繁更新的項目較去年增長 21.6%（2）版本頻繁更新的項目較去年增長 21.6%2023 年全年，主流開源軟件包生態系統中，更新發布 100 個以上版本的開源項目有 27234 個，較去年增長 21.6%。八個典型的開源軟件包生態系統中，一年內更新發布超過 100 個版本的項目數量見下表。排名包生態系統對應的開發語言一年內發布超過 100 個版本的項目數量1NPMJavascript162292MavenJava31923Nuget.NET27464GodocGo21565PypiPython14956PackagistPHP9527Rubyg

35、emsRuby2758SwiftSwift18215、關鍵基礎開源軟件分析5、關鍵基礎開源軟件分析一般而言，如果開源軟件出現漏洞后，造成的放大效應越大，影響范圍越廣，那么這個軟件就應當越重要。因此，本期報告繼續分析“關鍵基礎開源軟件”（被多于 1000 個其他開源軟件直接依賴的一類開源軟件）的安全狀況。這類開源軟件一旦出現漏洞，影響范圍巨大且消除困難，其安全性應得到更多關注。Apache Log4j2 就是一款關鍵基礎開源軟件，截止 2023 年底，其直接依賴數為 7919。（1）主流開源生態關鍵基礎開源軟件 TOP50（1）主流開源生態關鍵基礎開源軟件 TOP50分析發現，截止 2023 年

36、底，Maven、NPM、Nuget、Pypi、Packagist、Rubygems 等主流開源生態中的關鍵基礎開源軟件共有 1709 款，較2022 年底上漲 36.3%，直接依賴數排名 TOP50 的軟件如下表所示。開源軟件junit:junit的直接依賴數已連續三年位居榜首。ApacheLog4j2 僅排在第 139 名，未進入 TOP50，也就是說，如果 TOP50 表中的任何一款開源軟件曝出嚴重漏洞，其影響都可能會大過“Log4Shell”漏洞。排名開源軟件所屬包生態系統直接依賴數1junit:junitMaven997642rakeRubygems812123org.scala-la

37、ng:scala-libraryMaven758934bundlerRubygems70327225tiktokapi-srcNPM640216tiktok-srcNPM634567Newtonsoft.JsonNuget629808tslibNPM614269rspecRubygems6058910numpyPypi5948011requestsPypi5664012org.slf4j:slf4j-apiMaven5549613chalkNPM4472014commanderNPM4233715lodashNPM4147116pandasPypi3989417org.jetbrains.ko

38、tlin:kotlin-stdlibMaven3883818illuminate/supportPackagist3776919pytestPypi3671720guzzlehttp/guzzlePackagist3538221org.jetbrains.kotlin:kotlin-stdlib-commonMaven3450722axiosNPM3413823expressNPM3349424reactNPM304752325inquirerNPM2890126com.google.guava:guavaMaven2729327ch.qos.logback:logback-classicMa

39、ven2709628matplotlibPypi2650129requestNPM2583130org.jetbrains.kotlin:kotlin-stdlib-jdk8Maven2582631org.mockito:mockito-coreMaven2439732fs-extraNPM2413333scipyPypi2399434com.fasterxml.jackson.core:jackson-databindMmons:commons-lang3Maven2181736typescriptNPM2093937commons-io:commons-ioMaven2084938reac

40、t-domNPM2031439org.projectlombok:lombokMaven2030640laravel/frameworkPackagist1867041org.clojure:clojureMaven1806442clickPypi1798743tqdmPypi172022444pytest-covPypi1654345momentNPM1579646com.google.code.gson:gsonMaven1539147Microsoft.Extensions.DependencyInjection.AbstractionsNuget1501548pryRubygems14

41、97849odooPypi1458850org.assertj:assertj-coreMaven14556（2）關鍵基礎開源軟件的漏洞披露情況未見改善（2）關鍵基礎開源軟件的漏洞披露情況未見改善分析發現，歷年來，有較大比例的關鍵基礎開源軟件從未公開披露過漏洞，造成這種現象的原因主要有兩個，一方面，有的關鍵基礎開源軟件，特別是有的開源社區中的軟件，漏洞雖然已被修復了，但沒有記錄和公開；另一方面，維護和安全研究等相關人員對一些關鍵基礎開源軟件安全性的關注程度不夠，對它們漏洞挖掘的研究還不多。2023 年，對 1709 款關鍵基礎開源軟件分析發現，有 1313 款從未公開披露過漏洞，占比達 76.

42、8%，呈現出逐年升高的趨勢，如下圖所示。但另一方面，關鍵基礎開源軟件中也不乏漏洞披露流程非常正規的優秀開源項目。25（3）關鍵基礎開源軟件的整體運維風險有所改觀（3）關鍵基礎開源軟件的整體運維風險有所改觀本期報告依然從“版本更新時間”和“周提交頻率”兩個維度來分析判斷關鍵基礎開源軟件的運維狀況。首先，關鍵基礎開源軟件新版本發布的活躍度有較大提升。截止2023 年底，半年內沒有發布過新版本的關鍵基礎開源軟件有 453 款，占比為 26.5%，較去年的 41.5%有較大的下降。其次，關鍵基礎開源軟件提交的積極性有所降低。去年一年內，周平均提交次數小于5和小于1的關鍵基礎開源軟件數量分別為1245和

43、 916，占比分別為 72.8%、53.6%，兩項指標較前兩年持續升高。此外，在 TOP50 的關鍵基礎開源軟件中，有 34 款軟件明確已獲得大廠或者基金會支持，比前兩年的 23 和 24 款有明顯增加；Github貢獻者數量小于 100 的有 8 款,比去年和前年減少 1 款。266、NPM 生態中惡意開源軟件分析6、NPM 生態中惡意開源軟件分析分析發現，NPM 包生態系統較容易受到惡意代碼投毒攻擊。2023年，奇安信代碼安全實驗室通過開源倉庫監控平臺，共檢測出該包生態系統中的 381 個惡意開源組件。（1）超 95%的惡意開源組件以竊取敏感信息為目標（1）超 95%的惡意開源組件以竊取敏

44、感信息為目標其中，大部分惡意組件的攻擊集中在下載安裝階段，惡意行為包括用戶敏感信息竊取、主機敏感信息竊取、Git 賬戶信息竊取、主機失陷攻擊、惡意域名訪問，各類惡意開源組件的數量和占比如下圖所示?？梢钥闯?，95.3%的惡意組件以竊取敏感信息為最終目標，這些敏感信息包括用戶名、密碼、DNS、服務器 IP、Github 配置等。27（2）典型惡意開源組件及惡意行為剖析（2）典型惡意開源組件及惡意行為剖析針對各種惡意行為的典型惡意開源組件如下表所示。惡意行為組件版本主機敏感信息竊取slotbooking-ui2.18.0sber-ufs-sbert/icons4.45.0banca-movil-io

45、nic-v41.1.2dlw.scbase.staticsite9999.10.9fio-registrations2.0.0用戶敏感信息竊取npm_package_devdependencies_sass2.69.5update-material-outline-gap3.7.14lifi-contracts1.0.0testvijaysimha/gd-util1.0.0unit-testing-controllers1.0.3主機失陷攻擊qr-emvco1.1.2vader-pack1.0.3doneida1.0.7deuna-lib-tl-react-native-biocatch1.1

46、.2capacitor-selphi-plugin1.5.5惡意域名訪問zscaler/ec-domain5.0.0backbone.picky1.0.0testepocdep1.1.1Git 賬戶信息竊取gusmano/reext0.0.249本節以惡意開源組件 slotbooking-ui 2.18.0 為例，介紹其進行主機敏感信息竊取的過程。使用者在安裝該組件時，它會運行腳本來竊取服務器信息，具體步驟如下：281）安裝過程中，該惡意組件通過 package.json 里定義的命令，執行預先編寫好的 index.js 腳本；2）腳 本 獲 取 服 務 器 內 環 境 變 量，以 及/etc

47、/hosts 和/etc/resolv.conf 的文件內容，如下圖所示；3）文件內容通過 get_file()函數進行 base64 編碼，以便于進行傳輸；4）該惡意組件將收集到的信息通過 post 請求發送給攻擊者，如下圖所示。29四、國內企業軟件開發中開源軟件應用狀況四、國內企業軟件開發中開源軟件應用狀況2023 年，奇安信代碼安全實驗室對 1763 個國內企業軟件項目中使用開源軟件的情況進行了分析，包括其中開源軟件的使用，以及由此所帶來的漏洞和許可證風險等安全問題的情況。301、開源軟件總體使用情況分析（1）平均每個軟件項目使用 166 個開源軟件，再創新高1、開源軟件總體使用情況分析

48、（1）平均每個軟件項目使用 166 個開源軟件，再創新高與往年一樣，在被分析的 1763 個國內企業軟件項目中，全部使用了開源軟件，使用率為 100%。平均每個項目使用了 166 個開源軟件，此項數據再創新高。本次分析的軟件項目中使用開源軟件最多的數量為 6168 個，使用開源軟件排名前 10 的項目的情況如下圖所示。31（2）最流行的開源軟件被 37.2%的軟件項目使用（2）最流行的開源軟件被 37.2%的軟件項目使用在被分析的 1763 個國內企業軟件項目中，使用最多的開源軟件為 SLF4J API Module，被 656 個項目所使用，占比為 37.2%，低于去年 43.6%的水平。被

49、使用最多的前 10 名開源軟件如下表所示。開源軟件名稱使用的項目數被使用率SLF4J API Module65637.2%Commons Io:Commons Io62735.6%Apache Commons Codec62535.5%Fasterxml Jackson Core:Jackson Databind59133.5%Fasterxml Jackson Core:Jackson Core57932.8%Fasterxml Jackson Core:Jackson Annotations57132.4%Google Guava:Guava55331.4%Apache Commons:C

50、ommons Lang354530.9%32fastjson1-compatible53230.2%Apache Commons Logging51829.4%2、開源軟件漏洞風險分析（1）存在容易利用的開源軟件漏洞的項目占比大幅下降2、開源軟件漏洞風險分析（1）存在容易利用的開源軟件漏洞的項目占比大幅下降統計發現，在被分析的 1763 個國內企業軟件項目中，存在已知開源軟件漏洞的項目有 1551 個，占比為 88.0%；存在已知高危開源軟件漏洞的項目有 1428 個，占比為 81.0%；存在已知超危開源軟件漏洞的項目有 1268 個，占比為 71.9%。這三個比例均略低于去年水平，與2021

51、 和 2020 年基本持平。綜合漏洞的 POC/EXP 情況以及 CVSS 可利用性指標等因素，我們將漏洞的利用難度分為容易、一般、困難，容易利用的漏洞風險極高。在被分析的 1763 個項目中，存在容易利用的漏洞的項目有 1200 個，占比為 68.1%，較前兩年降幅較大。歷年存在各類開源軟件漏洞的軟件項目的占比情況如下圖所示。33（2）平均每個項目包含的已知開源軟件漏洞數明顯回落（2）平均每個項目包含的已知開源軟件漏洞數明顯回落在 1763 個國內企業軟件項目中，共檢出 146568 個已知開源軟件漏洞（涉及到 13135 個唯一 CVE 漏洞編號），平均每個軟件項目存在83 個已知開源軟件

52、漏洞，與去年的 110 個相比，降幅明顯，但仍高于之前兩年的水平。34本次分析的軟件項目中，引入已知開源軟件漏洞最多的數量為1929 個。存在已知開源軟件漏洞數量排名前 10 的項目的情況如下圖所示。35（3）影響最廣的開源軟件漏洞的影響范圍有所減?。?）影響最廣的開源軟件漏洞的影響范圍有所減小從漏洞的影響度來分析，影響范圍最大的開源軟件漏洞為CVE-2023-35116，存在于 33.4%的軟件項目中，比去年最高的 41.9%有較大減小，說明本年度檢測出的開源軟件漏洞的影響范圍較為分散。2023 年影響度排名前 10 的開源軟件漏洞如下表所示。漏洞名稱CVE 編號影響項目數量影響度Faste

53、rXML jackson-databind 代碼問題漏洞CVE-2023-3511658833.4%Google Guava 安全漏洞CVE-2023-297650528.6%Spring Framework 安全漏洞CVE-2024-2224347026.7%Spring Framework 安全漏洞CVE-2024-2226247026.7%Spring Framework 安全漏洞CVE-2024-2225947026.7%FasterXML jackson-databind 代碼問題漏洞CVE-2022-4200346026.1%Apache HTTP/2 資源管理錯誤漏洞CVE-20

54、23-4448746026.1%Vmware Spring Framework 代碼問題漏洞CVE-2016-100002746026.1%Spring Framework 安全漏洞CVE-2023-2086145826.0%FasterXML jackson-databind 代碼問題漏洞CVE-2022-4200445625.9%容易利用的漏洞更易被用來發起攻擊，風險極高。影響度排名前10 的容易利用的開源軟件漏洞情況如下表所示。36容易利用的漏洞名稱CVE 編號影響項目數量影響度Vmware Spring Framework 代碼問題漏洞CVE-2016-100002746026.1%j

55、Query 跨站腳本漏洞CVE-2020-1102241223.4%jQuery 跨站腳本漏洞CVE-2020-1102341223.4%jQuery 跨站腳本漏洞CVE-2019-1135840122.7%Spring Framework 代碼注入漏洞CVE-2022-2296538421.8%jQuery 跨站腳本漏洞CVE-2015-925137821.4%Vmware Spring Framework 安全漏洞CVE-2021-2209634519.6%Vmware Spring Framework 安全漏洞CVE-2021-2206034419.5%OpenSSL 緩沖區錯誤漏洞CV

56、E-2021-371132918.7%Apache HttpClient 安全漏洞CVE-2020-1395630217.1%（4）20 多年前的開源軟件漏洞仍然存在于多個軟件項目中（4）20 多年前的開源軟件漏洞仍然存在于多個軟件項目中分析發現，與往年報告結果一樣，部分軟件項目中仍然存在很久之前公開的古老開源軟件漏洞，其中，最古老的漏洞是 2001 年 7 月12 日公開的 CVE-2001-1267，距今已 23 年，這一時間比去年報告中的最古老開源軟件漏洞的發布時間還早一年。部分古老開源軟件漏洞的影響情況如下表所示，它們的發布時間距今都已超過 20 年。漏洞名稱CVE 編號發布日期影響項

57、目數量GNU Tar 敵對目標路徑漏洞CVE-2001-12672001-07-121GZip 超長文件名緩沖區溢出漏洞CVE-2001-12282001-11-11378zlib 安全漏洞CVE-2002-00592002-03-158GNU tar 任意文件覆蓋漏洞CVE-2002-12162002-10-281Portable Network Graphics 任意腳本遠程執行漏洞CVE-2002-13632002-12-262zlib 安全漏洞CVE-2003-01072003-02-235GNU Gzip 輸入驗證錯誤漏洞CVE-2003-03672003-07-021LibPNG

58、不合法 PNG 越界訪問拒絕服務漏洞CVE-2004-04212004-04-302GNU gzexe 臨時文件命令執行漏洞CVE-2004-06032004-06-241Microsoft MSN Messenger PNG 圖片解析遠程代碼執行漏洞CVE-2004-05972004-07-1223、開源軟件許可協議風險分析（1）最流行的開源許可協議在 46.9%的項目中使用3、開源軟件許可協議風險分析（1）最流行的開源許可協議在 46.9%的項目中使用在 1763 個被分析的國內企業軟件項目中，共發現 545 個開源許38可協議。涉及項目數最多的協議與前兩年一樣，依然是 Apache Li

59、cense2.0，在 827 個項目中使用，占比為 46.9%。涉及軟件項目數排名前 10的許可協議如下表所示。開源許可協議涉及項目數所占比例Apache License 2.082746.9%MIT License68839.0%BSD 3-Clause New or Revised License23313.2%BSD 2-Clause Simplified License1327.5%GNU General Public License v2.0 only1317.4%GNU General Public License v1.0 or later1066.0%Public Domain

60、985.6%GNU General Public License v3.0 only915.2%ISC License844.8%GNU General Public License v2.0 or later814.6%（2）超 1/5 的項目使用了含有超、高危許可協議的開源軟件（2）超 1/5 的項目使用了含有超、高危許可協議的開源軟件有些類型的開源許可協議中包含了一些限制性條款，在使用過程中一旦違反這些條款，可能對企業的商業利益和聲譽造成嚴重的損害。這些限制性條款包括如：“禁止本軟件及其衍生品用于商業目的”、“禁止在未支付費用和版稅的情況下將該軟件用于非公開、非商業用途”、“軟件發布時必

61、須公開軟件的源代碼”等。奇安信代碼安全實驗室將限制性較為苛刻的一類協議定義為超39危許可協議，將限制性較大而未達到超危水平的一類協議定義為高危許可協議。在 2023 年分析的 1763 個國內企業軟件項目中，存在超危許可協議的項目 124 個，占比 7.0%；存在高危許可協議的項目 256 個，占比 14.5%。含超危和高危許可協議的項目合計占比約為 21.5%，超過1/5,高于去年約 1/6 的占比。本次分析的軟件項目中使用到的超危許可協議如下表所示。超危開源許可協議簡稱涉及項目數GNU General Public License v3.0 onlyGPL-3.0-only91GNU Ge

62、neral Public License v3.0 or laterGPL-3.0-or-later44GNU Affero General Public License v3.0 onlyAGPL-3.0-only37GNU Lesser General Public License v3.0 onlyLGPL-3.0-only20GNU Lesser General Public License v3.0 or laterLGPL-3.0-or-later11Creative Commons Attribution Non CommercialShare Alike 2.5 Generic

63、CC-BY-NC-SA-2.58GNU Free Documentation License v1.2 onlyGFDL-1.2-only7涉及軟件項目數排名前 10 的高危許可協議如下表所示。高危開源許可協議簡稱涉及項目數GNU General Public License v2.0 onlyGPL-2.0-only131GNU General Public License v2.0 or laterGPL-2.0-or-later81GNU Lesser General Public License v2.1 onlyLGPL-2.1-only76GNU Library General P

64、ublic License v2 or laterLGPL-2.0-or-later6540GNU Lesser General Public License v2.1 or laterLGPL-2.1-or-later59Mozilla Public License 1.1MPL-1.158Eclipse Public License 1.0EPL-1.056GNU Library General Public License v2 onlyLGPL-2.0-only31Creative Commons Attribution Share Alike 3.0UnportedCC-BY-SA-

65、3.023Creative Commons Attribution Non CommercialShare Alike 3.0 UnportedCC-BY-NC-SA-3.0104、開源軟件運維風險分析4、開源軟件運維風險分析開源軟件運維風險復雜多樣，本期報告依然從老舊開源軟件的使用和開源軟件多個版本混亂使用的角度進行分析。（1）多個二三十年前的老舊開源軟件版本仍在使用（1）多個二三十年前的老舊開源軟件版本仍在使用分析發現，與前幾年報告數據一致，許多軟件項目中仍然在使用老舊的開源軟件版本，有的版本已經超過 30 年，存在極大的運維風險。被使用的老舊開源軟件版本中，最早的一款是 1993 年 3

66、 月 3 日發布的 byacc 1.9，已經發布 31 年。按老舊程度排名前 10 的開源軟件如下表所示。開源軟件名稱版本號版本發布日期涉及項目的數量byacc1.91993-03-031checker0.8-211999-03-09141journal1-41999-03-091GNU tar1.131999-09-051sdc1.0.8beta-82000-08-182Getopt-Long2.242000-08-281GNU bc1.062000-11-154URI1.102001-01-111zlib1.1.32001-02-053libpng1.0.92001-03-261（2）開源

67、軟件各版本使用依然混亂（2）開源軟件各版本使用依然混亂分析發現，與往年一樣，開源軟件版本使用混亂的狀況依然非常嚴重，并非使用的都是最新版本。Spring Framework:Spring Core 是被使用版本最多的開源軟件，有 169 個版本在被使用。按照被使用版本的數量排序，排名前 10 的開源軟件情況如下表所示。開源軟件名稱被使用的版本數量Springframework:Spring Core169Springframework:Spring Beans165Springframework:Spring Context163Spring AOP161Springframework:Spr

68、ing Web159Spring Expression Language(SpEL)154Spring Web MVC14942Spring Transaction147Spring JDBC146Springframework:Spring Context Support136五、典型軟件供應鏈安全風險實例分析五、典型軟件供應鏈安全風險實例分析1、多款主流操作系統供應鏈攻擊實例分析1、多款主流操作系統供應鏈攻擊實例分析Ubuntu 是一款被廣泛使用的 Linux 操作系統發行版，具有多種用途，可用作個人計算機的操作系統，提供辦公、媒體播放、游戲等的圖形用戶界面；同時它也是開發人員的首選操作系

69、統之一，因為它支持 Python、Java、C+等多種編程語言，還提供了 GCC 編譯器和版本控制系統等開發庫和工具。使用者通常使用 apt install 命令在Ubuntu 上安裝 MiniDLNA，以獲得媒體播放服務。MiniDLNA 是一款兼容 DLNA/UPnP-AV 客戶端的開源媒體服務軟件，支持音樂、圖片、視頻等媒體文件的播放，可幫助用戶通過 DLNA 兼容的智能電視、音響等設備，訪問和播放存儲在計算機上的多媒體文件。MiniDLNA 被廣泛部署在 Linux 服務器上，同時也廣泛應用于路由器、NAS 等嵌入式設備上。CVE-2023-33476 是 MiniDLNA 的一個越界

70、寫類型的超危歷史漏洞,由于MiniDLNA在處理采用分塊傳輸編碼的HTTP請求時存在邏輯缺陷，攻擊者可通過偽造較大的分塊長度，觸發后續拷貝時出現越界寫問題。利用該漏洞，遠程未授權的攻擊者可實現任意代碼執行攻擊。該漏洞43影響 MiniDLNA 的 1.1.15-1.3.2 版本。以 Ubuntu 20.04 為例，可通過 apt install 命令安裝 MiniDLNA1.2.1。運行該軟件后，會監聽 8200 端口。利用上述歷史漏洞，未認證的攻擊者可通過發送偽造的數據包，實現任意代碼執行，如下圖所示，可以看到成功獲取反彈 shell，表示攻擊成功。除此之外，Debian11、多個型號的路由

71、器等也有類似問題。本實例中，軟件供應鏈風險傳播鏈條為：多款主流操作系統的某些版本，在通過常規方式安裝開源媒體服務軟件 MiniDLNA 后，遠程未授權的攻擊者可能會利用MiniDLNA的歷史漏洞CVE-2023-33476對這些操作系統版本發起任意代碼執行的軟件供應鏈攻擊。2、PHP 軟件供應鏈攻擊實例分析2、PHP 軟件供應鏈攻擊實例分析PHP 是一種被廣泛使用的開源腳本語言，可以嵌入到 HTML 中，特別適用于 Web 開發。PHP 在運行時會依賴于底層的系統庫 Linux44glibc（GNU C 庫）來進行文件讀寫、網絡通信等操作，可以認為 PHP利用 Linux glibc 來支持其

72、程序的運行及與操作系統的交互。Linux glibc 是 GNU 按照 LGPL 許可協議發布的開源 libc 庫，即 C運行庫，是 Linux 系統中最底層的 API，幾乎其他任何運行庫都會依賴于 glibc。glibc 被廣泛應用于各種應用和設備中，包括大部分 Linux發行版以及路由器等。glibc 除了封裝 Linux 操作系統所提供的系統服務外，它自身也提供了許多必要功能服務的實現，為各種應用程序提供了基礎的接口和功能。CVE-2024-2961 是 Linux glibc 庫的一個中危歷史漏洞，該漏洞源于 iconv()函數存在緩沖區溢出問題，可導致應用程序崩潰或覆蓋相鄰變量。如果

73、某 PHP 應用程序中存在任意文件讀取漏洞，攻擊者便可以利用其實施文件讀取操作，在讀取過程中，會調用到glibc的iconv()函數，攻擊者可進一步利用 CVE-2024-2961 對 PHP 開發的應用實施遠程命令執行攻擊，從而提升了漏洞的危害程度。該漏洞影響 Linuxglibc 2.39 及更早版本。下圖展示了該漏洞對 PHP 8.1 的影響驗證結果。PHP 8.1 中使用了 glibc 2.35，利用上述歷史漏洞后，可以看到執行了給定的命令“whoami/tmp/16666.txt”，對應權限為“www”，成功實現了遠程命令執行攻擊。45本實例中，軟件供應鏈風險傳播鏈條為：PHP 程序

74、運行時使用Linux glibc 庫，如果某 PHP 應用程序存在任意文件讀取問題，攻擊者便可以基于 glibc 的歷史漏洞 CVE-2024-2961 對該 PHP 程序發起遠程命令執行的軟件供應鏈攻擊。3、某國產數據庫供應鏈攻擊實例分析3、某國產數據庫供應鏈攻擊實例分析某國產數據庫是一款自主研發的數據庫，可用作數據倉庫系統、BI 系統和決策支持系統的承載數據庫，具有高性能、高可用性、跨平臺支持、兼容性和可擴展性等特點，被規?；瘧糜诮鹑?、電信、能源、政企等行業。分析發現，為方便用戶進行數據遷移，實現與開源數據庫 MySQL 的適配，該國產數據庫的最新版本基于 MySQL JDBC5.1.1

75、1 實現了建立到數據庫服務端連接的功能。JDBC（Java Database Connectivity）是 Java 提供的一套用于連接數據庫的標準 API，它定義了一套標準的接口，使得開發者可以使用相同的代碼來連接不同類型的數據庫。而 MySQL JDBC（或 MySQLConnector/J 組件）是一種用于連接 MySQL 數據庫的 JDBC 驅動，允許Java 程序通過 JDBC API 訪問 MySQL 數據庫中的數據。46CVE-2021-2471 是 MySQL JDBC 的一個 XML 外部實體注入類型的中危歷史漏洞。由于 MySQL JDBC 中的 getSource()方法

76、對傳入的 XML數據校驗不足，導致攻擊者可以通過構造惡意的 XML 數據，實現遠程特權用戶讀取敏感數據或使應用程序崩潰等攻擊。該漏洞影響 MySQLJDBC 8.0.27 以下版本。MySQL JDBC 的另一個代表性的高危歷史漏洞是 2019 年爆出的某反序列化漏洞。攻擊者向 MySQL 服務器發送惡意數據，然后通過控制JDBC 連接設置項，將其配置指向該服務器。MySQL 客戶端處理結果集時會調用 ObjectInputStream.readObject()方法，從而執行惡意的反序列化操作，從而引發遠程命令執行等攻擊。該漏洞影響 MySQL JDBC8.0.21 以下版本。分析發現，上述兩

77、個歷史漏洞依然能夠影響本例中的國產數據庫的最新版本。以下展示了在其上利用兩個漏洞的效果，可以實現遠程命令執行等攻擊，具體效果如下所示：成功利用 CVE-2021-2471 漏洞的效果HTTP 服務收到 PoC 中 XML 外部實體解析發起的 HTTP 請求，成功實現服務端請求偽造攻擊，如下圖所示。成功利用 2019 年某 MySQL JDBC 反序列化漏洞的效果客戶端觸發了該反序列化漏洞，成功實現遠程命令執行攻擊，如47下圖所示。本實例中，軟件供應鏈風險傳播鏈條為：某國產數據庫的最新版本基于 MySQL JDBC 5.1.11 實現連接數據庫服務端的特定功能，MySQLJDBC 的 XML 外

78、部實體注入、反序列化等歷史漏洞依然可以影響該國產數據庫，實現遠程命令執行等軟件供應鏈攻擊。六、總結及建議六、總結及建議過去的一年，軟件供應鏈安全依然是網絡安全領域的熱點，但各方的態度更加趨于理性和謹慎，各項工作也正處于循序漸進向深水區探索的階段。歐美國家在前兩年密集完成了一系列政策、框架、指南、最佳實踐等的制定和修訂后，轉入了基于這些文件的監管執行階段，例如根48據美國 OMB 備忘錄 M-22-18、M-23-16 的要求和 SSDF 1.1 框架，CISA于 2024 年 3 月發布了安全軟件開發證明表格，美聯邦政府的軟件生產供應商需基于該表格證明自己實施特定安全實踐的情況；同時，CISA

79、 還建立了軟件證明和工件存儲庫，以促使美聯邦政府的軟件生產供應商上傳軟件證明表格和相關工件，其中也包括“關鍵軟件”。國內在軟件供應鏈安全保護方面的工作也在扎實推進中，一是頂層規范不斷完善，國家標準中軟件供應鏈安全要求和軟件產品開源代碼安全評價方法已發布，軟件物料清單數據格式也已完成公開征求意見；二是行業建設如火如荼，多個行業的機構開展了面向軟件供應鏈安全、開源軟件治理、軟件物料清單（SBOM）生成和應用等方面的能力建設、能力評估、工具評價等工作；三是解決方案持續落地，國內一些頭部網絡安全公司和大型企業組織陸續推出或落地了較為全面的軟件供應鏈安全解決方案，并在持續的完善。但另一方面我們也看到，目

80、前國內缺少軟件供應鏈安全管理領域權威的實施指南；此外，對于數量巨大的中小型軟件研發企業來說，制定和實施系統的軟件供應鏈安全解決方案面臨著成本、精力、人員等諸多難題，當前能夠采取的防護措施相對有限。因此，應加強軟件供應鏈安全保障的頂層設計，建立健全軟件供應鏈安全的指導監督機制和基礎服務設施，并盡量覆蓋所有類型的軟件生產和供應商。具體建議如下：1）建立國家層面統一的軟件供應鏈安全保護基礎設施1）建立國家層面統一的軟件供應鏈安全保護基礎設施一是組織編制基于國標的實施指南，明確達到保護要求所需的機49制方法、具體措施和推薦工具等內容，為軟件供應商，特別是中小型研發企業提供專業指導和操作手冊；二是建立軟

81、件供應鏈安全檢測服務平臺，滿足軟件供應商對代碼安全審計、漏洞掃描、開源軟件成分及風險分析等方面的在線檢測需求，降低中小型研發企業的檢測成本；三是完善開源軟件的安全處置機制，包括開展針對關鍵基礎開源軟件的安全漏洞分析、惡意代碼檢測、安全加固、集中維護、漏洞信息定向通報和補丁定向分發等工作。2）完善國家和行業級的軟件供應鏈安全測評認證體系2）完善國家和行業級的軟件供應鏈安全測評認證體系二十屆三中全會通過的中共中央關于進一步全面深化改革、推進中國式現代化的決定強調，要建立產業鏈供應鏈安全風險評估和應對機制。第三方權威測評機構，依據全面的指標、規范的流程和專業的工具，可以更加系統的發現軟件供應鏈的安全

82、問題，彌補供應商自測的不足。監管部門應鼓勵相關測評機構基于現行標準和實踐，積極開展軟件供應鏈安全測評指標的研究，建立并完善相應的測評能力和平臺，形成針對各類重要系統、各個行業的軟件供應鏈安全測評體系，并在此基礎上，開展軟件供應商及其產品的安全認證工作。3）健全關基軟件供應商安全實踐證明材料的備案機制3）健全關基軟件供應商安全實踐證明材料的備案機制鑒于關鍵基礎設施的重要性，應要求向關鍵基礎設施和重要信息系統用戶銷售軟件產品、提供軟件定制開發的廠商和供應商，在交付軟件系統前，除了進行安全性自測和第三方測試外，還應向特定機構和關基運營者備案研發過程中所采取的安全措施的情況，包括安全開發流程的執行、安

83、全編碼的制定和采用、引入的第三方組件的安全性50分析和修補措施等情況。同時，應提供軟件物料清單（SBOM）。這些內容可作為供應商管理和安全責任追溯的重要依據。51附錄：奇安信代碼安全實驗室簡介附錄：奇安信代碼安全實驗室簡介奇安信代碼安全實驗室是奇安信集團旗下，專注于軟件源代碼安全分析技術、二進制漏洞挖掘技術研究與開發的團隊。實驗室支撐國家級漏洞平臺的技術工作，多次向國家信息安全漏洞庫（CNNVD）和國家信息安全漏洞共享平臺（CNVD）報送原創通用型漏洞信息并獲得表彰；幫助微軟、谷歌、蘋果、Cisco、Juniper、Red Hat、Ubuntu、Oracle、Adobe、VMware、阿里云、

84、飛塔、華為、施耐德、Mikrotik、Netgear、D-Link、Netis、ThinkPHP、以太坊、Facebook、亞馬遜、IBM、SAP、NetFlix、Kubernetes、Apache 基金會、騰訊、滴滴等大型廠商和機構的商用產品或開源項目發現了數百個安全缺陷和漏洞，并獲得公開致謝。目前，實驗室擁有國家信息安全漏洞庫（CNNVD）特聘專家一名，多名成員入選微軟全球 TOP 安全研究者、Oracle 安全縱深防御計劃貢獻者等精英榜單。在 Pwn2Own 2017 世界黑客大賽上，實驗室成員還曾獲得 Master of Pwn 破解大師冠軍稱號?；谄姘残糯a安全實驗室多年的技術積累

85、，奇安信集團在國內率先推出了自主可控的軟件代碼安全分析系統奇安信代碼衛士和奇安信開源衛士。奇安信代碼衛士是一款高度可擴展的靜態應用程序安全測試系統，該系統提供了一套企業級源代碼缺陷分析、源代碼合規分析、IaC安全分析的解決方案，在不改變企業現有開發測試流程的前提下，與軟件版本管理、持續集成、缺陷跟蹤等系統進行集成，將源代碼安全52分析融入企業開發測試流程中，實現軟件源代碼安全目標的統一管理、自動化檢測、差距分析、缺陷修復追蹤等功能，幫助企業以最小代價建立代碼安全保障體系并落地實施，構筑信息系統的“內建安全”。奇安信代碼衛士目前支持 C、C+、C#、Objective-C、Swift、Java、

86、PHP、Python、Cobol、Go 等 32 種編程語言，可檢測 3500 多種源代碼安全缺陷，支持多個國際、國內主流標準和規范的檢測。奇安信開源衛士是一款集開源軟件識別與安全管控于一體的軟件成分分析系統，該系統通過智能化數據收集引擎在全球范圍內獲取開源軟件基礎信息、協議信息及其相關漏洞信息，利用自主研發的開源軟件分析引擎為企業提供開源軟件資產識別、開源軟件漏洞風險分析、開源軟件協議風險分析、開源軟件運維風險分析、開源軟件漏洞情報預警及開源軟件安全管理等功能，幫助企業掌握開源軟件資產信息及相關風險，及時獲取最新開源軟件漏洞情報，降低由開源軟件給企業帶來的風險，保障企業交付更安全的軟件。奇安信開源衛士目前可識別超過 1.8 億開源軟件版本的識別，支持源代碼、二進制、容器鏡像、操作系統的開源軟件成分分析，兼容 NVD、CNNVD、CNVD 等多種漏洞情報來源。奇安信代碼衛士和奇安信開源衛士已經在近千家大型機構和企業中應用，入選國家發改委數字化轉型伙伴行動、工信部中小企業數字化賦能專項行動，為中小企業提供軟件代碼安全檢測平臺和服務。