懸鏡&中國電信：軟件供應鏈安全治理與運營白皮書（2022）（128頁）.pdf

《懸鏡&中國電信：軟件供應鏈安全治理與運營白皮書（2022）（128頁）.pdf》由會員分享，可在線閱讀，更多相關《懸鏡&中國電信：軟件供應鏈安全治理與運營白皮書（2022）（128頁）.pdf（128頁珍藏版）》請在三個皮匠報告上搜索。

1、關于懸鏡安全關于 ISC關于中國電信研究院參編機構懸鏡安全，DevSecOps 敏捷安全領導者。起源于北京大學網絡安全技術研究團隊“XMIRROR”，創始人子芽。專注于以代碼疫苗技術為內核，通過原創專利級 全流程軟件供應鏈安全賦能平臺+敏捷安全工具鏈”的第三代 DevSecOps 智適應威脅管理體系，持續幫助金融、車聯網、泛互聯網、能源等行業用戶構筑起適應自身業務彈性發展、面向敏捷業務交付并引領未來架構演進的內生積極防御體系。懸鏡安全官網：https:/ 是亞太地區乃至當今世界規格高、輻射廣、影響力深遠的全球性安全峰會。自 2013 年舉辦首屆以來，九年間已圍繞網絡空間治理、數據安全、威脅情報

2、等前沿領域安全問題，舉辦超 20場國際峰會，設立超300場分論壇，輸出超2000個行業前沿議題。吸引來自中國、美國、俄羅斯、以色列、德國等全球 30 多個國家的 2000 余位政要、行業領袖、網絡安全專家深度參與，共話全球網絡安全生態。已經成為專業性、權威性、全球性的中國網絡安全產業名片。ISC 官網：https:/ 5G、云計算、人工智能、大數據、物聯網、安全等多個領域。懸鏡安全、ISC、中國電信研究院導語INTRODUCTION 數字化時代，軟件定義萬物，已逐漸成為支撐社會正常運轉的最基本元素之一。隨著軟件開發過程中開源應用的使用越來越多，開源應用事實上逐漸成為了軟件開發的核心基礎設施，混

3、源軟件開發也已成為現代應用主要軟件開發交付方式，開源應用的安全問題也已被上升到基礎設施安全和國家安全的高度來對待。軟件供應鏈開源化，導致影響軟件全供應鏈的各個環節都不可避免受到開源應用的影響。尤其是開源應用的安全性問題，將直接影響采用開源應用的相應軟件供應鏈的安全。除了開源應用開發者因疏忽導致的開源應用安全缺陷，還可能存在具有非法目的開發者故意預留的開源應用安全缺陷，甚至還有惡意攻擊者偽造的含有隱藏性惡意功能的異常行為代碼被故意上傳到上游開源代碼托管平臺，實施定向軟件供應鏈攻擊。上述開源應用中存在的眾多安全問題，導致軟件供應鏈的安全隱患大大增加，安全形式更加嚴峻。而現代軟件應用的供應鏈非常復雜

4、，軟件供應鏈安全管理是一個系統工程，亟需從國家、行業、機構、企業各個層面建立軟件供應鏈安全風險的發現能力、分析能力、處置能力、防護能力，整體提升軟件供應鏈安全管理的水平。為此，需要開展全方位的軟件供應鏈安全檢測防御方法和技術研究。第一，開展軟件成分動態分析及開源應用缺陷智能檢測技術研究，突破高效高準確性的開源應用安全缺陷動態檢測技術的瓶頸，解決基于全代碼遍歷和代碼片段級克隆技術比對的應用安全檢測難題，進一步實現對全球開源應用的全面安全檢測，從源頭堵住軟件供應鏈安全隱患的源頭。第二，建立全球開源應用的傳播態勢感知和預警機制，攻克軟件供應鏈中軟件來源多態追蹤技術，實現對供應鏈各環節中軟件來源的溯源

5、機制。通過軟件來源多態追蹤技術監控開源應用的使用傳播和分布部署態勢，全面把握有缺陷的開源應用傳播和使用渠道，實現對全球開源應用及其安全缺陷的預測預警。第三，建立國家級/行業級軟件供應鏈安全監測與管控平臺，具備系統化、規?；能浖创a缺陷和異常行為代碼分析、軟件漏洞分析、開源軟件成分及風險分析等關鍵能力，為關鍵基礎設施、重要信息系統用戶提供日常的自查服務，及時發現和處置軟件供應鏈安全風險。第四，嚴格管控軟件供應鏈上游，尤其重點管控開源應用的使用，積極推動代碼疫苗、SCA、區塊鏈和 SBOM 等新技術和標準在軟件供應鏈安全領域的推廣和應用，從根本上提供軟件供應鏈安全的可靠保障。隨著 AI 和自動

6、化惡意攻擊技術不斷升級，專門針對軟件供應鏈的攻擊趨勢明顯加強，軟件供應鏈已經成為網絡空間攻防對抗的焦點，直接影響關鍵基礎設施和數字經濟安全，這也是為何中國第一屆“DevSecOps 敏捷安全大會”（DSO2021）的主題被定為“安全從供應鏈開始”的主要原因，也是我們本次發布軟件供應鏈安全治理與運營白皮書（2022）的主要驅動力。此外，作為國內 DevSecOps 軟件供應鏈安全的主要推動力量之一，從 2016 年初開始，我和懸鏡創始團隊就一直希望能有機會結合自身在這幾年的前沿技術創新研究和行業應用實踐沉淀，可以對軟件供應鏈安全的治理與運營及 DevSecOps 敏捷安全體系的演進做一個系統性的

7、梳理，并分享我們這些年在不同典型用戶場景探索的落地實踐經驗。因此，沉淀了我們近 5 年創新技術研究與全球敏捷安全應用實踐經驗的DevSecOps 敏捷安全書籍應運而生。希望在這個新涌現新變化的前沿技術領域，我們懸鏡團隊和業界同行一起，憑借長期的技術積累和突破來推動中國自己的安全產業向新的未知空間做更深層次地探索，為產業搭建一個匯集“國家、行業、機構、企業“等綜合力量且“同向、同心”的軟件供應鏈安全保障生態體系變得愈發重要。2022 年 7 月 7網絡安全關乎著國家安全、企業安全，近年來一直備受重視。尤其是云原生、AI、物聯網等技術的不斷更新發展與應用，既推進了信息安全產業的快速發展，也衍生了更

8、多的安全威脅。軟件供應鏈安全作為網絡安全的重要部分，近年來爆發的安全問題也越來越凸顯。了解軟件供應鏈安全的相關內容、探究安全治理與運營解決方案，是企業組織防患于未然的重要舉措。2021 年懸鏡安全聯合中國信通院發布了軟件供應鏈安全白皮書（2021），詳細介紹了軟件供應鏈安全現狀、安全風險分析、安全治理辦法及安全實踐等內容，對軟件供應鏈安全做了框架性的梳理。鑒于近年來軟件攻擊鏈安全事件高發，如何治理是眾多企業亟需填補的理論洼地，對本模塊加深認知才能占領實現軟件供應鏈安全的制高點?；诖?，懸鏡安全與ISC及中國電信研究院聯合發布了 軟件供應鏈安全治理與運營白皮書（2022），重點講述軟件供應鏈安全

9、治理體系和開源威脅治理，不斷豐富軟件供應鏈安全鏈條，實現整體安全。本文的撰寫依托于眾多參考文獻，融合懸鏡安全、ISC 與中國電信研究院的專家經驗。編撰過程難免有所疏漏，歡迎廣大讀者批評、指正，共同推進軟件供應鏈安全的發展。前言目錄CONTENTS1 軟件供應鏈安全發展背景1.1 政策驅動下的軟件供應鏈安全 1.1.1 國內外政策法規 1.1.2 國內外標準 1.2 軟件供應鏈安全的重要性1428323437373840414343464749505151562281211336422 軟件供應鏈安全現狀2.1 軟件供應鏈安全事件高發2.2 軟件供應鏈風險典型特征2.3 開源軟件供應鏈攻擊不斷增

10、多2.4 軟件供應鏈安全常見風險3 軟件供應鏈安全面臨的挑戰3.1 開源技術的使用，安全風險加劇 3.1.1 安全漏洞風險 3.1.2 許可證合規及兼容風險3.2 云原生技術的興起，復雜度增加3.3 軟件供應鏈安全治理痛點4 軟件供應鏈安全治理體系4.1 軟件供應鏈安全治理框架 4.1.1 Google SLSA 框架 4.1.2 CNCF in-toto 框架 4.1.3 Microsoft SCITT 框架 4.1.4 軟件供應鏈安全框架對比分析4.2 治理體系構建4.3 軟件供應過程風險治理 4.3.1 軟件來源管理 4.3.2 軟件安全合規性評審73835657575859596169

11、697071747579818486878787889091919397100101108 4.3.3 軟件資產管理 4.3.4 服務支持 4.3.5 安全應急響應4.4 人員管理4.5 軟件開發生命周期安全風險治理 4.5.1 建設全流程安全開發管控 4.5.2 構建完善的開發運營安全工具鏈4.6 軟件安全成熟度模型 4.6.1 可信研發運營安全能力成熟度模型 4.6.2 研發運營一體化（DevOps）能力成熟度模型 4.6.3 BSIMM5.軟件物料清單 SBOM5.1 SBOM 的重要性5.2 建立通用的 SBOM5.3 SBOM 的生成5.4 SBOM 的優勢6.開源威脅治理6.1 開

12、源軟件安全風險6.2 開源威脅治理技術6.3 開源威脅治理的前提 6.3.1 樹立開源風險意識 6.3.2 明確開源治理規范 6.3.3 建立開源治理制度體系6.4 開源威脅治理階段6.5 開源的 SCA 工具 6.5.1 Snyk Open Source 6.5.2 OpenSCA 6.5.3 Veracode SCA 6.5.4 Dependency-Check 6.5.5 不同工具對比6.6 商業化的 SCA 工具8 總結7 軟件供應鏈安全治理發展趨勢7.1.軟件物料清單（SBOM）將得到更多實踐7.2 供應鏈和開源安全將成為容器安全中的新熱點7.3 開源許可證風險將獲得高度關注7.4

13、RASP 會成為軟件供應鏈安全運營的核心工具113114115116112117軟件供應鏈安全發展背景01如今，敏捷開發模式下軟件的開發以最快的速度將代碼從 IDE 或 Git 存儲庫帶到生產環境中，加快了部署速度，提升了業務系統上線的效率。但軟件供應鏈的安全性對組織來說同樣重要，因為任何一個安全漏洞都可能造成巨大的損失。然而，近年來攻擊者利用軟件供應鏈進行攻擊的事件頻發，攻擊者通過一個安全漏洞就可以輕松訪問上下游業務系統，這也是眾多攻擊者選擇此類型攻擊的原因。Gartner 分析指出，“到 2025 年，全球 45%組織的軟件供應鏈將遭受攻擊，比 2021 年增加了三倍?！笨梢?，軟件供應鏈的

14、安全威脅將越來越嚴重。網絡安全關乎著企業是否正常運轉，是國民經濟能否正常運行的重要前提，而軟件供應鏈安全作為網絡安全的重要組成部分，是實現網絡安全的重要前提。21.1 政策驅動下的軟件供應鏈安全信息技術時代，軟件是企業應用程序的重要組成基礎，軟件無處不在且扮演著越來越重要的角色。一旦軟件出現安全問題，將會影響到整個業務系統的正常運行。然而隨著軟件產業的不斷發展，軟件供應鏈的復雜度不斷增加，對于信息系統的安全帶來了眾多安全威脅。不過軟件供應鏈安全意識也在不斷完善，國內外政府相繼出臺了一系列法令法規，也制定了一系列的相關標準，對軟件供應鏈安全做了明示，以指導企業機構等能更好的實現軟件供應鏈安全，規

15、避網絡風險的發生。1.1.1 國內外政策法規1.美國美歐等發達國家和地區在信息技術供應鏈安全管理領域起步較早，出臺了大量政策法規和標準規范，用于加強軟件供應鏈安全管理。我國近年來也在不斷出臺相關法律規范，逐步完善軟件供應鏈安全管理工作。序號時間主體措施內容12022 年 2 月美國國土安全部（DHS）成 立 網 絡 安 全審 查 委 員 會（CSRB）成 立 一 個 新 機 構-網絡 安 全 審 查 委 員 會（CSRB），以調查重大網絡安全事件。這個由15 人組成的委員會將由來自國安局、FBI 和CISA 等機構及包括國防部和司法部在內的政府部門的高級官員一以及來 自 Google、微 軟

16、和Verizon 等公司的私營部門高管混合組成。其成立后的第一項任務，就是針對 Log4j2 供應鏈漏洞進行調查表 1-1 美國針對軟件供應鏈安全的規范及措施 322022 年 1 月 11日美國網絡安全和基礎設施安全局（CISA）主導成立的 ICT供應鏈風險管理工 作 組 制 定 了2022 年 的 工 作規劃工作組計劃將軟硬件物料清單以及加大對中小企業的影響力作為其供應鏈風險治理的重點32021 年 5 月 12日拜登政府簽署了“關于改善國家網絡安全（EO14028）”的行政命令其中第 4 節“加強軟件供應鏈安全”的（e）條款要求：初步指南發布 90天內（不遲于 2022 年 2月 6 日

17、），NIST 應發布加強軟件供應鏈安全實踐的指南，并明確了指南需包含的 10 余項具體內容。NIST 修訂了其 2020 年 4月發布的安全軟件開發框架（SSDF）V1.0，形 成 V1.1 草 案，并 于2021 年 9 月 30 日 至 11月 5 日完成公開征求意見42021 年 2 月拜登政府簽署了第 14017 號美國供應鏈行政令要求聯邦機構對關鍵領域和行業的全球供應鏈進行審查，包括在行政令發布后的 100 天內針對包括半導體芯片的四個關鍵領域的供應鏈進行審查；在行政令發布后的一年之內對國防、醫療衛生、通信技術、能源、交通和食品生產六個行業進行供應鏈審查 452019 年 5 月特朗

18、普政府簽署第 13873 號確保信息通信技術與服務供應鏈安全行政令要求商務部長、國務卿、國土安全部、國家情報總監分別根據自身職責開展持續性評估工作，每年均需發布相關評估報告62018 年 12 月美國國土安全部正式組建 ICT 供應鏈風險管理特別任務組該任務組主要職責時識別全球 ICT 供應鏈安全風險挑戰，并提供可操作的解決方案72008-2009 年美國政府將供應鏈安全上升至國家戰略早在 2008 年就開始制定相關政策法規，國家網絡安全綜合計劃（CNCI）要求在產品、系統和服務的整個生命周期內綜合應對國內和全球供應鏈風險；2009 年發布的網絡空間安全評估報告，將信息通 信 技 術（以 下

19、簡 稱“ICT”）供應鏈安全納入國家安全范疇。至此，美國率先完成了 ICT 供應鏈安全的框架結構設計，明確了其在國家安全中的重要地位 52.歐盟表 1-2 歐盟針對軟件供應鏈安全的措施及規范序號時間主體措施內容12021 年 7 月歐洲網絡及信息安全局（ENISA）發 布 了ENISA 的供應鏈攻擊威脅情景對供應鏈攻擊進行了分類，并對從 2020 年 1 月到 7 月初的 24 起供應鏈攻擊事件進行了研究，對供應鏈攻擊者來源、攻擊手段、攻擊目標以及應對措施進行了分析22015 年 8 月歐洲網絡與信息安全局（ENISA）發布供應鏈完整 性：ICT 供 應鏈風險和挑戰概述，以及發展方向愿景報告指

20、出 ICT 供應鏈完整性是國家經濟發展的關鍵因素，提高供應鏈完整度對公共和私營部門意義重大，并建議供應鏈安全管理應遵循同一套實踐，為評估和管理提供共同的基礎，政府應與企業合作建立 ICT 供應鏈安全風險評估框架 63.我國相關政策法規序號時間主體措施內容12021 年 11 月國家互聯網信息辦公室2021 年 第 20次室務會議審議通過網絡安 全 審 查 辦法為了確保關鍵信息基礎設施供應鏈安全，維護國家安全，對關鍵信息基礎設施運營者采購網絡產品和服務，影響或可能影響國家安全的，應進行網絡安全審查22021 年 10 月人 民 銀 行 辦 公廳、中央網信辦秘書局、工業和信 息 化 部 辦 公廳、

21、銀保監會辦公廳、證監會辦公廳聯合發布關于規范金融業開源技術應用與 發 展 的 意見（以下簡稱意見）意見要求金融機構在使用開源技術時，應遵循“安全可控、合規使用、問題導向、開放創新”等原則。意見鼓勵金融機構將開源技術應用納入自身信息化發展規劃，加強對開源技術應用的組織管理和統籌協調，建立健全開源技術應用管理制度體系，制定合理的開源技術應用策略；鼓勵金融機構提升自身對開源技術的評估能力、合規審查能力、應急處置能力、供應鏈管理能力等；鼓勵金融機構積極參與開源生態建設，加強與產學研交流合作力度，加入開源社會組織等32021 年 7 月 30日國務院正式公布關鍵信息基礎設施安全保護條例第十九條明確指出：

22、“運營者應當優先采購安全可信的網絡產品和服務；采購網絡產品和服務可能影響國家安全的，應當按照國家網絡安全規定通過安全審查”表 1-3 我國針對軟件供應鏈安全的規范及措施 742021 年國家標準化管理委員會擬通過研究制定信息安全技術 軟件供應鏈安全要求提升國內軟件供應鏈各個環節的規范性和安全保障能力52020 年中國電子技術標準化研究院發 布 國 家 標 準信息技術產品供 應 鏈 安 全 要求征求意見稿規定了信息技術產品供應方和需求方應滿足的供應鏈基本安全要求62020 年電信終端產業協會發布了網絡產品供應鏈安全要求行業標準對網絡產品在管理制度、組織機構和人員、信息系統等以及供應鏈環節提出了不

23、同等級的安全要求72019 年 7 月國家互聯網信息辦公室等四部門發布云計算服務 安 全 評 估 辦法要求云計算服務安全評估工作中，應重點評估“云平臺技術、產品和服務供應鏈安全情況”。申請安全評估的云服務商應提交“業務連續性和供應鏈安全報告”82019 年中國信通院推動制定軟件供 應 鏈 安 全 管理能力成熟度模型、軟件物料清單建設總體框架從軟件供應鏈入口、自身、出口三個階段多維度保障軟件供應鏈安全，并落地評估測試92016 年 11 月第十二屆全國人民代表大會常務委員會第二十四次會議通過中華人民共和國網絡安全法第三十五條“關鍵信息基礎設施的運營者采購網絡產品和服務，可能影響國家安全的，應當通

24、過國家網信部門會同國務院有關部門組織的國家安全審查”和第三 8十六條“關鍵信息基礎設施的運營者采購網絡產品和服務，應當按照規定與提供者簽訂安全保密協議，明確安全和保密義務與責任”，分別從網絡安全審查、網絡產品和服務安全角度對供應鏈安全提出要求1.1.2 國內外標準1.1.2.1 國外標準情況除了法令法規之外，國內外也制定了一系列的安全標準，對軟件供應鏈安全提出了更細化的安全要求。序號標準措施內容1 ISO/IEC JTC1/SC27信息技術 安全技術供應商關系的信息安全系列標準該系列標準包括四個部分，分別是:ISO/IEC27036-1：2021第 1 部分：概述和相關概念，提供了 27036

25、 系列標準的總體介紹，對供應商關系的類型、相關安全風險以及風險管理相關概念進行了描述；ISO/IEC 27036-2：2014第 2 部分：通用要求，對供應關系中的信息安全進行定義，并對實施、操作、評估、應對措施等提出了通用要求；ISO/IEC 27036-3：2013第 3 部分：供應鏈安全指南，對 ICT 供應鏈中產品和服務的安全風險進行描述和分析，給出了應對相應風險的措施；ISO/IEC 27036-4：2016第 4 部分：云服務安全指南，提出了云計算服務在 ICT 供應鏈方面存在的安全風險及相關應對措施表 1-4 國外標準情況 92ISO/IEC 20243信息技術 開放可信技術提供

26、商標準 減少惡意和仿冒組件系列標準該系列標準包括 ISO/IEC 20243-1：2018要求和建議、ISO/IEC 20243-2：2018 O-TTPS 和 ISO/IEC 20243-1：2018 的評估流程兩個部分，針對信息通信技術硬件和軟件在產品生命周期內面臨的完整性威脅，特別是惡意和仿冒組件帶來的安全風險，提供了一套應對準則、方針和建議3ISO 28000供應鏈安全管理體系規范說明了組織建立、實施供應鏈安全管理體系的要求，保障供應鏈安全的重要內容，為各類組織開展供應鏈安全管理提供了一個較為系統的管理模式4 NIST SP 800-161聯邦信息系統和組織的供應鏈風險管理實踐針對為聯

27、邦信息系統和機構供應鏈方面面臨的安全風險，提出的 ICT 供應鏈安全風險控制流程和措施。該標準通過提出將供應鏈安全風險納入組織整體的風險管理過程，并給出 19 類 ICT 供應鏈安全控制措施，以減少聯邦信息系統和組織面臨的供應鏈安全風險1.1.2.2 我國相關標準序號標準措施內容1GB/T 366372018信息安全技術 ICT 供應鏈安全風險管理指南該系列標準包括四個部分，分別是:ISO/IEC27036-1：2021第 1 部分：概述和相關概念，提供了 27036 系列標準的總體介紹，對供應商關系的類型、相關安全風險以及風險管理相關概念進行了描述；ISO/IEC 27036-2：2014第

28、 2 部分：通用要求，對供應關系中的信息安全進行定義，并對實施、操作、評估、應對措施等提出了通用要求；表 1-5 國內標準情況 10ISO/IEC 27036-3：2013第 3 部分：供應鏈安全指南，對 ICT 供應鏈中產品和服務的安全風險進行描述和分析，給出了應對相應風險的措施；ISO/IEC 27036-4：2016第 4 部分：云服務安全指南，提出了云計算服務在 ICT 供應鏈方面存在的安全風險及相關應對措施2 GB/T 329212016信息安全技術信息技術產品供應方行為安全準則該標準規定了信息技術產品供應方在提供信息技術產品過程中，為保護用戶相關信息，維護用戶信息安全應遵守的基本準

29、則，分別從用戶相關信息收集和處理的安全、遠程控制用戶產品的安全和其他行為安全等方面提出相關安全要求，適用于信息技術產品供應、運行或維護過程中的供應方行為管理3GB/T 329262016信息安全技術政府部門信息技術服務外包信息安全管理規范該標準針對政府部門在使用信息技術服務外包時面臨的外包服務機構背景復雜、服務人員流動性大、內部管理不規范等問題帶來的信息安全風險，建立了政府部門信息技術服務外包信息安全管理模型，明確了服務外包信息安全管理角色和責任，將管理活動劃分為規劃準備、機構和人員選擇、運行監督、改進完成四個階段，提出具體信息安全管理要求，為政府部門信息技術服務外包的安全管理提供參考4GB/

30、T 311682014信息安全技術云計算服務安全能力要求該標準提出了云服務商應具備的技術能力，適用于對政府部門使用的云計算服務進行安全管理。標準從重要設備安全檢測情況，重要信息系統、組件獲服務的供應鏈保護措施情況，供應商情況等方面對云服務商的供應鏈安全提出要求5GB/T 244202009供應鏈風險管理指南該標準在參考國際航天質量標準、美國機動車工程師協會標準和歐洲航空航天工業協會 11標準供應鏈風險管理指南等標準的基礎上制定。標準給出了供應鏈風險管理的通用指南，包括供應鏈風險管理的步驟，以及識別、分析、評價和應對供應鏈風險的方法和工具，適用于各類組織保護其在供應鏈上進行的產品的采購活動6-信

31、息安全技術 關鍵信息基礎設施信息技術產品供應鏈安全要求（報批稿）該標準提出了關鍵信息基礎設施、政務信息系統信息技術產品供應鏈在設計、開發、采購、生產、交付和運維等環節的安全要求，主要從安全漏洞缺陷的防范、安全運營維護、供應商管理、供應來源多樣性等方面提出安全要求，適用于關鍵信息基礎設施、政務信息系統加強信息技術產品供應鏈安全7-信息安全技術 軟件供應鏈安全（草案）該標準規定了軟件產品和服務供應鏈所涉及相關要素的安全要求，包括軟件供應鏈組織管理要求，以及開發、交付、使用等環節的安全要求 121.2 軟件供應鏈安全的重要性近年來，世界各地出現了越來越多的針對不同國家公共和私人機構的供應鏈攻擊。在某

32、些情況下，攻擊是由國家支持的 APT 組織實施的，這些攻擊具有區域和全球影響，諸如SolarWinds就是此類攻擊。除此之外，利用漏洞、后門等不同形式的攻擊針對企業的攻擊也越來越多，在近年的軟件供應鏈攻擊事件中可見一斑。關于不同類型的攻擊手段，在軟件供應鏈安全白皮書（2021）中也有細數，可再次翻閱。1.針對國家層面的軟件供應鏈攻擊軟件供應鏈攻擊是復雜的，當軟件開發或者第三方代碼/組件的引入缺乏透明度時，便缺乏了對惡意攻擊的抵抗能力。此時，若攻擊者通過惡意篡改對供應鏈展開攻擊，一旦攻擊成功便容易對“關鍵基礎設施、政府機構”等造成安全威脅，如進行間諜行動竊取國家機密等，對一個國家的危害是巨大的。

33、如 2017 年的 NotPetya 攻擊，該攻擊使銀行、商業、公用事業和物流癱瘓，在全球造成數十億美元的損失。2020 年全球著名的管理軟件供應商 SolarWinds 遭遇國家級 APT 團伙高度復雜的供應鏈攻擊，導致包括美國關鍵基礎設施、軍隊、政府等在內的超過 18000 家客戶全部受到影響，可任由攻擊者操控。此類的攻擊仍有很多，不一一詳述。2.針對企業層面的軟件供應鏈攻擊開源軟件（Open Source Software,簡稱 OSS）讓軟件開發模式發生轉變，為節省開發時間，眾多企業在應用系統開發中引入了開源軟件，使得開源軟件被廣泛使用。然而，OSS 項目的指數增長增加了潛在的攻擊面，

34、并使審計代碼成為更大的挑戰。例如，軟件開發和源代碼管理平臺 GitHub 托管的公共存儲庫的數量從 2009 年 2月的 4.6 萬個激增到 2020 年 1 月的 2800 萬個。而且，軟件供應鏈攻擊是潛伏的，在軟件生命周期的開發和分發階段使用惡意軟件是難以發現的。在某些情況下，攻擊者在軟件代碼編譯和簽名之前就插入了惡意軟件，將其嵌入到標準的安全簽名之后，從而降低了被反病毒工具檢測到的可能性。在其他情況下，攻擊者通過軟件發布和升級更新補丁注入惡意代碼。從而對企業進行惡意攻擊，造成嚴重危害。不管是針對國家層面還是企業層面，軟件供應鏈攻擊都會帶來不可彌補的危害，而且危害一旦發生都是不可逆的。因此

35、，實現軟件供應鏈安全至關重要。軟件供應鏈安全現狀02DevOps 軟件開發模式的出現，使得現代軟件開發框架和方法更側重于軟件交付速度和可靠性的實現。但是，現代開發框架缺乏相關指導，無法幫助企業組織了解其軟件的威脅、評估檢測和應對威脅以及實施緩解措施。而且，企業組織在 DevOps 軟件開發中更關注組織內的代碼和進程，經常會忽略可能影響其應用完整性的外部因素，例如，開源軟件包的攻擊會影響直接或間接依賴于該軟件包的任何代碼。自 2020 年以來，此類軟件供應鏈攻擊急劇增加。除此之外，不同周期階段發生的軟件供應鏈攻擊事件眾多，如下重點簡述自“棱鏡計劃”事件以來的典型事件，讓大家對供應鏈攻擊有更多了解

36、。142.1 軟件供應鏈安全事件高發網絡攻防日趨常態化以來，安全威脅的種類也日漸增多。針對軟件供應鏈攻擊的事件越來越多，呈頻發狀態。近年來，出現了一系列典型的軟件供應鏈攻擊事件。其中如 SolarWinds Orion、Wind River VxWorks Urgent/11 安全漏洞、Equifax 信息泄露是其中較為典型的幾個事件案例，以下本白皮書針對這幾個事件做詳細描述。1.SolarWinds Orion 攻擊2020 年 12 月，全球多家網絡安全公司發布報告，聲稱 SolarWinds 公司旗下 Orion 平臺遭到黑客入侵。SolarWinds 遭遇的黑客攻擊事件被命名為“Sun

37、burst”，這是一次高度復雜的供應鏈攻擊。也是一場全球性的黑客攻擊，因為威脅攻擊者將 Orion 軟件變成了一種武器，可以訪問全球多個政府系統和數千個私人系統。由于軟件的性質以及擴展的 Sunburst 惡意軟件可以訪問整個網絡，許多政府及企業網絡和系統都面臨著重大漏洞的風險。雖然此攻擊事件在 2020 年 12 月份被披露，而攻擊者的整個攻擊過程從 2019 年就已經開始了。攻擊過程2019.9.4事件披露攻擊者嘗試訪問SolarWinds2019.9.12 攻擊者注入測試代碼2020.2.20 Solorigate后門被編譯及發布2019.11.4攻擊者停止注入測試代碼2020.5 Te

38、arDrop攻擊載荷被觸發2020.3Solorigate后門被分發2020.12.14 美國政府發表聲明，確認政府部門遭到入侵2020.6.4攻擊者將惡意組件從SolarWinds構建環境中清除2020.12.8FireEye公司披露此攻擊事件2020.12.18SolarWinds公司股價一周內跌幅超過4成，市值蒸發近二十億美元圖 2-1 SolarWinds 攻擊時間軸攻擊過程根據權威報告數據顯示，此次攻擊可以分為三個階段：15 2020.72020.8Backdoor,TeardropBackdoor,Sunburst第一階段SunspotSunburst第二階段Teardrop第三階

39、段Cobalt StrikeRaindropBackdoor,Raindrop(bproxy.dll)Unknown 7z.dll7-zip extracted DSIUnknown PyInstaller“mc_store.exe”圖 2-2 攻擊階段第一階段第二階段Sunspot：攻擊者使用 Sunspot 將 Sunburst 后門插入到 SolarWinds Orion IT 管理平臺的軟件版本中，用Sunburst 代碼替換源代碼;Sunburst：一旦安裝了 Sunburst 后門，Sunspot 就會持續監視 Orion build 操作并劫持它，以通過 Sunburst后門將其

40、他惡意代碼插入 Orion 庫中。這樣，攻擊者就將惡意代碼插入了 Orion 版本更新程序包中，分發給成千上萬的用戶。Teardrop&Raindrop 的角色主要為 Cobalt Strike 的 loader。下表是對兩個惡意軟件的對比情況：表 2-1 Teardrop 與 Raindrop 對比傳播方式TeardropRaindrop載荷格式載荷嵌入方式加密方式壓縮方式混淆方式導出名稱由Sunburst分類自定義PE二進制blobvisualDecrypt combined with XORNone插入垃圾代碼塊多變，有時與Tel/Tk projects一致-僅shellcode隱寫St

41、eganographyAES、XORLZMA非功能代碼延遲執行與Tcl/Tk projects一致 16第三階段攻擊特點：該次攻擊一個顯著特點是，在第二階段使用的惡意軟件是為了引出第三階段定制的 Cobalt Strike 工具。Cobalt Strike 是一套功能齊全的滲透測試工具，由 Raphael Mudge 于 2012 年創建，是第一批公開的“Red Team”C&C框架之一，于2020年被HelpSystems正式收購，成為許多美國政府，大型企業和咨詢組織的首選“紅隊”平臺。攻擊影響：影響范圍廣，33000 余名 Orion 客戶有一多半都安裝了帶后門的 Orion 軟件，其中不

42、乏美國重要政府部門及各知名企業；隱蔽性持久性好，攻擊者使用 ATT&CK 上的持久術等技術使得攻擊“隱身”，更不易被發現；引入了強大的“紅隊”平臺，此滲透測試平臺在以往的攻擊中也有集成應用，極具代表性。攻擊危害：受 SolarWinds 攻擊影響的重要機構至少 200 家，波及北美、歐洲等全球重要科技發達地區的敏感機構，覆蓋了美國、加拿大、日本、比利時、荷蘭、澳大利亞等，多為發達國家，其中美國占比超過 60%。在行業分布上，包括國防科技、政府、醫療服務、教育、金融、食品等關鍵基礎商業。截止 2021 年 1 月 18 日，賽門鐵克發現了 4 個 Raindrop 樣本。前三個與 Teardro

43、p 類似，Cobalt Strike 被配置為使用 HTTPS 作為通信協議；第四個使用 SMB 作為通信協議。2.Wind River VxWorks Urgent/11 安全漏洞2019 年，VxWorks 官方發布了安全漏洞公告，在所有的漏洞中有 6 個可導致遠程代碼執行（RCE）漏洞，其中CVE-2019-12256、CVE-2019-12255、CVE-2019-12260 CVSS 評分為 9.8 分。其余 5 個漏洞可能導致拒絕服務，信息泄漏或歸類為邏輯缺陷。這些漏洞存在于 VxWorks 的 TCP/IP 堆棧（IPnet）中，影響 VxWorks 7(SR540 and SR

44、610)、VxWorks 6.5-6.9 及使用 Interpeak 獨立網絡堆棧的 VxWorks 版本。攻擊者可以利用其中漏洞實現無需用戶交互及認證的遠程攻擊，最終完全控制相關設備。17VxWorks 首次發布2006URGENT/11被 VxWorks 收購之前，IPnet 已用于其他操作系統2019.7.29 Armis 公開披露了影響風河 VxWorks的 11 個漏洞20181987它被美國宇航局的洞察號火星登陸任務使用202097%的URGENT/11和80%的CDPwn脆弱設備仍未打補丁，使數以千計的組織仍處于攻擊的風險之中圖 2-3 VxWorks 攻擊時間軸圖 2-4 受影

45、響的版本影響版本：VxWorks RTOS（實時操作系統）是全球使用率非常高的嵌入式系統，根據官網的客戶列表，從關鍵基礎設施、網絡設備、醫療設備、工業系統甚至航天器均在其中，據稱被超過20億臺設備使用?？梢哉f從PLC到MRI機器，到防火墻和打印機，再到飛機，火車等等都有廣泛應用。它以其良好的可靠性和卓越的實時性被廣泛地應用在通信、軍事、航空、航天等高精尖技術及實時性要求極高的領域中，如衛星通訊、軍事演習、彈道制導、飛機導航等。具體受影響的版本包括：URGENT/11 的風險：URGENT/11 對當前使用的所有受影響的 VxWorks 連接設備構成了重大風險。根據設備在網絡上的位置和攻擊者的位

46、置，存在三種攻擊場景。18圖 2-5 攻擊網絡防御系統圖 2-6 從網絡外部繞過安全防線進行攻擊場景 1 攻擊網絡防御系統第一種攻擊場景影響位于網絡外圍的 VxWorks 設備，例如防火墻。使用 URGENT/11 漏洞，攻擊者可以對此類設備發起直接攻擊，完全控制它們，然后控制它們所保護的網絡。場景 2 從網絡外部繞過安全防線進行攻擊第二種攻擊場景會影響任何具有外部網絡連接的受影響 VxWorks 設備。URGENT/11 漏洞使攻擊者能夠接管此類設備，無論在網絡外圍實施任何防火墻或 NAT 解決方案以抵御攻擊。作為此場景的示例，請考慮對從安全網絡中連接到云的 IoT 設備（例如 Xerox

47、打印機）的攻擊。打印機不直接暴露在互聯網上，因為它受到防火墻和 NAT 的保護，通過它連接到云應用程序。攻擊者可以攔截打印機與云的 TCP 連接（不考慮 TLS）并觸發打印機上的 URGENT/11 RCE 漏洞之一，從而完全控制它。為了攔截 TCP 連接，攻擊者可以使用諸如 DNSpionage 使用的技術惡意軟件，成為組織 Internet 流量的中間人。一旦攻擊者接管了網絡中的一個設備，他就可以橫向擴散控制其中的其它 VxWorks 設備，如下一個攻擊場景中所述。網絡醫院防火墻筆記本電腦網絡攻擊者臺式電腦打印機VOIP電話病人監護儀核磁共振網絡醫院防火墻路由器+NAT網絡攻擊者DNS服務

48、器（已被網絡攻擊者控制）云打印服務打印機DNS 19場景 3 從網絡內部進行攻擊在這種情況下，由于先前的攻擊（例如上述情況），攻擊者已經位于網絡中，可以發送能夠完全控制設備的目標 VxWorks 設備數據包，而無需用戶交互。此外，攻擊者不需要任何有關目標設備的先驗信息，因為 URGENT/11 允許他通過在整個網絡中廣播他的惡意數據包來一次破壞所有易受攻擊的設備。作為這種攻擊的一個例子，考慮一個只有內部網絡連接的關鍵設備：醫院的病人監護儀。即使它沒有連接到 Internet，但通過滲透網絡，攻擊者仍然可以接管它。雖然人們可能認為將設備隱藏在安全網絡中就足夠了，但攻擊者總有辦法進入，正如上面的攻

49、擊場景所展示的那樣，其中詳細說明了攻擊者如何使用 URGENT/11 滲透網絡。另一個例子可以在可編程邏輯控制器(PLC)中找到，它分布在工廠中。由于它們在受影響的 VxWorks 上運行，使用 URGENT/11 的攻擊者可以在網絡中廣播一次攻擊并有效控制整個工廠，無需任何偵察工作，將其關閉以獲取贖金或任何其他惡意目的。影響范圍：全球 VxWorks 操作系統分布情況如下：圖 2-7 全球 VxWorks 操作系統最新分布情況 20圖 2-8 全國 VxWorks 操作系統最新分布情況圖 2-9 Equifax 信息泄露事件時間軸3.Equifax 信息泄露事件2017 年，黑客利用 Equ

50、ifax 系統中未修復的 Apache Struts 漏洞（CVE-2017-5638）發起攻擊，導致了系統中大規模數據泄露，影響極其惡劣。當時這個漏洞的評分為最高分 10 分，Apache 隨后發布 Struts 2.3.32 和 2.5.10.1 版本，進行修復。但 Equifax 在漏洞出現的兩個月內都沒有修復，導致 5 月份黑客利用這個漏洞進行攻擊，泄露其敏感數據。2017.02.14一名安全研究員發現了Struts漏洞，并通過其安全郵件列表向Apache報告了該漏洞2017.09.07Equifax宣布公司發生了一起“網絡安全事件”，影響到大約1.43億美國消費者，包括姓名、社會安全

51、號碼、出生日期、地址和駕駛執照、209000個信用卡號碼和182000份用戶信用報告申訴文件2017.03.09Equifax的GTVM小組對漏洞進行了通告，并強調將其升級到指定的Struts 2版本2017.08.11Mandiant安全公司首先確認了攻擊者對用戶PII數據的訪問2017.03.07Apache Struts項目管理委員會（PMC）公開披露了Struts漏洞，且該漏洞被評為10分2017.03.08國土安全部的計算機安全應急小組（U.S.-CERT)向Equifax發出了一份關于需要修補Apache Struts漏洞的通知2017.03.10攻擊者利用該漏洞并執行了“whoa

52、mi”命令去發現Equifax其他潛在受影響的服務器2017.03.14Equifax的應急威脅小組發布了一個Snort特征規則，應對此攻擊2017.07.29Equifax的對抗小組將67個新的SSL證書上傳到數據中心的SSL Visibility（SSLV）設備上，恢復了入侵檢測與防御系統對流量的分析和識別2017.08.02Equifax聯系了外部律師，并聘請網絡安全公司Mandiant完成對數據泄露的全面調查分析并確定入侵的范圍，同時向聯邦調查局通報了這一事件2017.08.17Equifax已經確定有大量的用戶數據被侵害，包括首席執行官、首席信息官、首席法務官、首席財務官、被入侵系統

53、ACIS的業務負責人、Mandiant安全公司代表、外部律師一起討論了調查結果2017.09.01Equifax召開了董事會會議，討論調查、受侵害的PII范圍、以及對外通知的計劃全國 VxWorks 操作系統分布情況如下：21攻擊過程：入侵者利用 Struts 漏洞成功進入了 Equifax 的內部網絡，攻擊的入口是 ACIS 系統（Equifax 為消費者提供用來對信用報告中的不準確信息進行申訴的一個門戶網站）。在入侵 ACIS 系統后，攻擊者上傳了第一個 Webshell后門程序，用于遠程控制。（Webshell 是一種后門程序，攻擊者通過它可以隨時重新進入這臺服務器，可以使用文件系統、進

54、行數據庫操作，方便執行系統命令，并提供文件上載/下載功能；在后續的攻擊過程中，攻擊者大約上傳了 30 個不同種類的 Webshell）。隨后，攻擊者通過掛載 NFS（網絡文件系統）共享，由于 Equifax 未對存儲中的文件進行訪問控制，攻擊者獲取到了敏感的配置文件，包括未加密的應用程序使用的連接數據庫的用戶名和密碼。攻擊者成功使用這些憑證訪問了與 ACIS 系統功能無關的 48 個數據庫。攻擊者在這些數據庫上運行了大約 9000 個查詢，這些查詢包括對數據庫元數據的查詢，以發現表中包含的信息類型；以及一旦找到一個帶有PII信息的表，需要執行額外的查詢，用以從表中獲取出想要的敏感數據?？偣?，9

55、000 次查詢里的 256 次查詢，返回了包含 PII 的數據集，并且所有這些 PII 信息都沒有在數據庫中被加密。攻擊者將 265 次成功查詢的 PII 數據輸出存儲在文件中，壓縮并放置在一個可訪問的 Web 目錄中。在遠程通過 Wget 工具下載了這些文件，成功將數據從 Equifax 竊取。整個攻擊過程，攻擊者使用了大約 35 個不同的IP 地址。攻擊持續了 76 天，然后才被 Equifax 的員工發現。原因是 Equifax 有安全設備可以監控到網絡里的異常流量，包括它們之前更新了規則的入侵檢測與防御系統。但是這些安全設備的前面還有一個 SSL 解密設備 SSL Visibility

56、（SSLV），用于將加密的流量解密后發給檢測和防護系統進行分析識別。但是，在事件發生時，SSL解密設備上的證書已經過期了，根據設備的配置，證書過期不會影響流量的正常傳輸，但是卻會影響入侵檢測與防御系統，因為它們無法分析加密的流量。其中 ACIS 的域名 的證書在 2016 年 1 月 31 號就過期了，也就是說在 19 個月之前，入侵檢測與防御系統就已經無法檢查 ACIS 的流量了。外部訪問SSLV設備內部服務器入侵檢測和防御系統網絡圖 2-10 外部訪問、SSLV 設備、IDS 設備、以及內部服務器示意圖 22攻擊影響：Equifax 漏洞攻擊事件影響了大約 1.48 億美國消費者，包括姓名

57、、社會安全號碼、出生日期、地址和駕駛執照、209000 個信用卡號碼和 182000 份用戶信用報告申訴文件。攻擊危害：Equifax 在泄露事件之后增加了 IT 和網絡安全支出，2017 年 11 月，公司臨時首席執行官 Paulino do Rego Barros 表示，Equifax 公司自發現泄露事件以來增加了四倍的安全支出。Equifax 報告稱 2018 年前 9 個月與這起安全事故有關的費用為 2.215 億美元，包括技術和數據安全、法律和調查費用、產品賠償等。攻除上述三個典型軟件供應鏈安全典型事件之外，還有更多的事件，具體如下(見下頁)：23圖 2-11 近年來軟件供應鏈攻擊典

58、型事件時間線2015201620172018201920202021低中高Toxik病毒NotPetya勒索病毒異鬼Bootkit木馬“隱魂”木馬Igexin SDK竊取用戶隱私WireX AndroidBotnet污染事件加密采礦僵尸網絡Lemon DuckSolarWindsPujia8 破解網站攜帶木馬友盟SDK未導出組件暴露漏洞Android平臺爆出“核彈級”Janus漏洞Arris為AT&T家庭用戶定制版調制解調器內置后門事件遠程終端管理工具Xshell后門事件惡性病毒“Kuzzle”“靈隱”木馬“方程式”組織（Equation Group）惡意代碼多媒體框架FFmpeg漏洞廣升被曝

59、向andriod設備預裝后門惠普筆記本音頻驅動內置鍵盤記錄后門事件基于域名軟件升級劫持攻擊某加固服務被曝出夾帶廣告ZipperDown漏洞依賴混淆攻擊AccellioN零日漏洞攻擊Linux漏洞git.php.ne后門植入事件Mimecast供應商被攻擊事件Codecov bash uploa-der腳本被修改Visual Studio Code安全缺陷REvail勒索軟件攻擊事件XCodeGhost木馬感染事件ApacheLog4j遠程代碼執行NPM供應鏈攻擊微軟Azure容器服務器賬戶接管漏洞事件ReaItek WIFIl模塊SDK漏洞事件SonarQube漏洞華碩電腦攻擊事件event-

60、stream攻擊“寄生推”SDK病毒OTA廠商銳嘉科在Android設備中植入rootkitXcode非官方版本惡意代碼污染百度SDKWormHole事件Juniper VPN后門事件2月9月11月12月7月11月1月5月6月7月4月5月6月7月8月12月8月11月12月2月3月6月5月4月7月8月10月12月Wind River VxWorksUngent/11安全漏洞CCleaner惡意代碼植入事件Struts2遠程代碼執行漏洞Equifax信息泄露事件 24下為部分典型事件簡述：2021 年 12 月，Apache Log4j2 遠程代碼執行漏洞（CVE-2021-44832）。在某些特

61、殊場景下（如系統采用動態加載遠程配置文件的場景等），有權修改日志配置文件的攻擊者可以構建惡意配置，通過 JDBCAppender 引用 JNDI URI 數據源觸發 JNDI 注入，成功利用此漏洞可以實現遠程代碼執行。攻擊者僅需一段代碼就可遠程控制受害者服務器，危害巨大。2021 年 9 月，微軟 Azure 容器服務跨賬戶接管漏洞事件。因使用五年前發布的 RunC v1.0.0-rc2，微軟 Azure容器服務爆出跨賬戶接管漏洞，攻擊者可攻陷托管ACI的多租戶Kubernetes集群，接管平臺上其他客戶的容器，在其中執行代碼并訪問部署在平臺上的數據，該漏洞已經被修復。2021年8月，Real

62、tek WIFIi模塊SDK漏洞事件。臺灣芯片設計廠商Realtek稱，其WiFi模塊的三款開發包(SDK)中存在 4 個嚴重漏洞，攻擊者可利用這些漏洞攻陷目標設備并以最高權限執行任意代碼。SDK 用于至少 65 家廠商制造的近 200 款物聯網設備中。2021 年 7 月，REvail 勒索軟件攻擊事件。攻擊者獲得 Kaseya 公司后端設施訪問權限，在運行于客戶現場的安全事件響應工具 VSA 服務器上部署 REvil 勒索軟件。通過 VSA 服務器將勒索軟件安裝到聯網工作站，從而感染其它第三方企業網絡。攻擊發生前，互聯網上處于聯網狀態的 VSA 服務器超過 2200 臺。2021年6月，L

63、inux漏洞事件。研究人員披露了影響Linux平臺基于Pling的免費和開源軟件(FOSS)市場的漏洞，攻擊者可利用該漏洞進行供應鏈攻擊 XSS 蠕蟲并實現遠程代碼執行(RCE)。2021 年 5 月，Visual Studio Code。在流行的 Visual Studio Code 擴展中發現嚴重安全缺陷?？墒构粽呶＜氨镜貦C器，或通過開發人員 IDE 構建和部署系統，這些擴展的下載量超 200 萬。2021 年 4 月，Codecov 的 bash uploader 腳本被攻擊者修改事件。知名代碼測試公司 Codecov 宣布其產品的bash uploader 腳本被攻擊者修改，用戶在使

64、用 Codecov 產品時，會向攻擊者的服務器發送敏感信息，可造成軟件源代碼等機密信息的泄露。2021 年 3 月，git.php.ne 攻擊事件。攻擊者向 服務器上的 php-src 存儲庫推送了兩次惡意提交，在 PHP 代碼中植入了一個后門，攻擊者可通過后門獲得運行 PHP 的網站系統的遠程代碼執行權限。2021 年 2 月，一名安全研究人員使用一種新穎的攻擊技術攻破了微軟、蘋果、優步和特斯拉等公司的系統。Alex Birsan 利用依賴/名稱空間混淆，在不需要社會工程的情況下，成功地向下游數十個引人注目的目標發送了偽造(但無害)包。2021 年 1 月，Mimecast 供應商被攻擊事件

65、。云安全公司 Mimecast 報告稱，攻擊者破壞了供應商用于認證其在 Microsoft 365 Exchange Web 服務上服務的證書。大約 10%的 Mimecast 用戶使用依賴于被泄露證書的應用程序，但 Mimecast 表示只有少數人受到影響。252020 年，SolarWinds。迄今為止影響最深遠的供應鏈攻擊源自一個后門 SUNBURST，該后門被注入到 Orion IT 管理應用程序的更新工具中。在提交給美國證券交易委員會的文件中，SolarWinds 稱已有 18,000 名客戶下載了該后門程序。該攻擊導致包括美國關鍵基礎設施、軍隊、政府等在內的超過 18000 家客戶

66、全部受到影響，可任由攻擊者操控。2018 年，event-stream 攻擊。這是針對 GitHub 庫的一次攻擊，惡意軟件被注入到 flatmap-stream 依賴中，這是 event-stream 的一部分。將受損害的依賴關系引入代碼的應用程序數量仍然未知。2018 年 6 月，華碩電腦攻擊事件。一場名為 shadowwhammer 的攻擊瞄準了華碩電腦的用戶。賽門鐵克(Symantec)的研究人員認為，這次通過華碩自動更新功能發送惡意軟件的攻擊從 6 月持續到 10 月，影響了多達 50 萬個系統,其他供應商可能也受到了影響。2018 年 5 月，ZipperDown 漏洞。攻擊者可以

67、通過這個漏洞來破壞手機數據，也可以獲取任意代碼執行能力。2018 年 4 月，“寄生推”SDK 病毒。通過預留的“后門”云控開啟惡意功能，進行惡意廣告行為和應用推廣，以實現牟取灰色收益。2017 年 12 月，Android 平臺爆出“核彈級”Janus 漏洞。能在不影響應用簽名的情況下，修改應用代碼，導致應用的升級安裝可能被惡意篡改。同樣，隨著越來越多的應用采用熱補丁的方式更新應用代碼，惡意開發者也趁虛而入，在應用更新方式上做手腳，下發惡意代碼，威脅用戶安全。2017 年 12 月，友盟 SDK 未導出組件暴露漏洞。攻擊者利用該漏洞可以實現對使用了友盟 SDK 的 APP 的任意組件的惡意調

68、用、任意虛假消息的通知、遠程代碼執行等攻擊。2017 年 11 月，Pujia8 破解網站攜帶木馬。某游戲破解網站上多款游戲應用被植入了 Root 模塊，在運行時,利用 CVE-2015-1805 等內核漏洞強行 Root 用戶設備，并將無圖標惡意應用植入到設備系統目錄，長期潛伏用戶設備進行惡意廣告和流氓推廣行為。2017 年 8 月，Arris 為 AT&T 家庭用戶定制版調制解調器內置后門事件。安全研究人員發現知名電信設備制造商 Arris 生產的調制解調器存在 5 個安全漏洞，其中有 3 個是硬編碼后門賬號漏洞。攻擊者利用三個后門賬號均可控制設備，提升至 Root 權限、安裝新固件，乃至

69、于架設僵尸網絡等。2017 年 8 月，WireX Android Botnet 污染事件。WireX BotNet 僵尸網絡通過偽裝普通安卓應用的方式大量感染安卓設備并發動了較大規模的 DDoS 攻擊，其引發的 DDoS 事件源自至少 7 萬個獨立 IP 地址，據數據顯示，來自 100 多個國家的設備感染了 WireX BotNet。2017 年 8 月，“隱魂”木馬。感染 MBR（磁盤主引導記錄）的“隱魂”木馬捆綁在大量色情播放器的安裝包中誘導下載安裝，安裝包安裝后調用加載讀取釋放出來的JPG圖片并解密圖片后的shellcode代碼并執行?！半[魂”木馬入侵系統后劫持瀏覽器主頁，并安插后門實

70、現遠程控制。短短兩周內，“隱魂”木馬的攻擊量已達上 26 百萬次。2017 年 8 月，惡性病毒“Kuzzle”。該病毒感染電腦后會劫持瀏覽器首頁牟利，同時接受病毒作者的遠程指令進行其他破壞活動。2017 年 7 月，遠程終端管理工具 Xshell 后門事件。2017 年 7 月 18 日發布的軟件被發現有惡意后門代碼，該惡意的后門代碼存在于有合法簽名的 nssock2.dll 模塊中。2017 年 8 月 7 日，廠商 NetSarang 發布了一個更新通告，聲稱在卡巴斯基的配合下發現并解決了一個在 7 月 18 日的發布版本的安全問題，提醒用戶升級軟件。2017年7月，異鬼Bootkit木

71、馬。該木馬通過高速下載器傳播。隱藏在正規軟件甜椒刷機中，帶有官方數字簽名，導致大量安全廠商直接放行。該木馬通過國內幾大知名下載站的高速下載器推廣，影響百萬臺機器。2017 年 7 月，基于域名 軟件升級劫持攻擊。這次事件其實是基于域名 的一組大規模軟件升級劫持事件。用戶嘗試升級若干知名軟件客戶端時，運營商將 HTTP 請求重定向至惡意軟件并執行。惡意軟件會在表面上正常安裝知名軟件客戶端的同時，另外在后臺偷偷下載安裝推廣其他軟件。2017 年 6 月，“靈隱”木馬。該木馬主要針對游戲外掛使用者，通過打包修改各種外掛，捆綁木馬程序，再通過網盤和各類游戲論壇傳播。執行劫持瀏覽器、刪除安全軟件、進行軟

72、件推廣功能。2017 年 6 月，NotPetya 勒索病毒。病毒攻擊的根源是劫持了烏克蘭專用會計軟件 me-doc 的升級程序，使用戶更新軟件時感染病毒。政府、銀行、電力系統、通訊系統等都不同程度地受到了影響。2017 年 5 月，惠普筆記本音頻驅動內置鍵盤記錄后門事件。來自瑞士安全公司 Modzero 的研究人員在檢查Windows Active Domain 的基礎設施時發現惠普音頻驅動中存在一個內置鍵盤記錄器監控用戶的所有按鍵輸入。研究人員指出，惠普的缺陷代碼（CVE-2017-8360）不但會抓取特殊鍵，而且還會記錄每次按鍵并將其存儲在人類可讀取的文件中。這個記錄文件位于公用文件夾

73、C:UsersPublicMicTray.log 中，包含很多敏感信息如用戶登錄數據和密碼，其他用戶或第三方應用程序都可訪問。2017 年 1 月，某加固服務被爆出夾帶廣告。該加固服務在加固應用時，會在開發者不知情的情況下植入代碼用于拉取廣告、下載拉活其他應用、程序異常上報、獲取應用程序信息等行為。2016 年 11 月，廣升被曝向 andriod 設備預裝后門。通過此后門會將用戶的大量私人信息發送到提供固件的中國公司服務器上，發送的數據包括了手機號碼、位置數據、短信內容、呼叫信息、安裝和使用的應用等等。2016 年 11 月，OTA 廠商銳嘉科在 Android 設備中植入 Rootkit。

74、安裝該惡意軟件的設備可被黑客進行中間人攻擊，并且以 Root 權限執行任意代碼以此來獲得對 Android 設備的絕對控制權，其主要原因是因為設備在OTA 更新的時候沒有采取嚴格的加密措施導致的。272016 年 7 月，Toxik 病毒。該病毒將自身偽裝成流行軟件（游戲修改器、系統周邊工具等）在下載站中進行傳播，在用戶運行后，該病毒會利用國內某知名互聯網公司的軟件升級程序（WPS 升級程序）下載推廣軟件，甚至下載病毒驅動進行惡意推廣。2015 年 12 月，Juniper VPN 后門事件。著名網絡設備廠商 Juniper 公司發出風險聲明，其防火墻、VPN 設備使用的操作系統具有重大安全風

75、險，建議盡快升級相關版本。根據聲明，設備的 SSH 登錄系統在輸入任意用戶名的情況下，使用超級密碼就可以最高權限登錄系統，設備的VPN安全通道上傳遞的數據可以被攻擊人解密、篡改和注入。全球上萬 NetScreen 設備被攻擊。2015 年 11 月，百度 SDK WormHole 事件。百度 moplus SDK 的一個被稱為蟲洞（Wormhole）的漏洞被漏洞報告平臺 wooyun.org 所披露，研究人員發現 Moplus SDK 具有后門功能，攻擊者利用其可以獲取訪問權限控制權。2015 年 9 月，多媒體框架 FFmpeg 漏洞。通過該漏洞可在播放漏洞視頻或在轉碼過程中觸發本地文件，讀

76、取獲得指定文件。2015 年 9 月，Xcode 非官方版本惡意代碼污染事件。攻擊者通過向非官方版本的 Xcode 注入病毒 Xcode Ghost，它的初始傳播途徑主要是通過非官方下載的 Xcode 傳播，通過 CoreService 庫文件進行感染。當應用開發者使用帶毒的 Xcode 工作時，編譯出的 App 都將被注入病毒代碼，從而產生眾多攜帶病毒的 APP。至少692 種 APP 受污染，過億用戶受影響，受影響的包括了微信、滴滴、網易云音樂等著名應用。2015 年 2 月，“方程式”組織（Equation Group）擁有一套用于植入惡意代碼的超級信息武器庫（在卡巴的報告中披露了其中

77、6 個），其中包括兩個可以對數十種常見品牌的硬盤固件重編程的惡意模塊，這可能是該組織掌握的最具特色的攻擊武器，同時也是首個已知的能夠感染硬盤固件的惡意代碼。282.2.軟件供應鏈風險典型特征通過懸鏡安全實驗室對近 5 年的 43 次軟件供應鏈安全事件做的系統性整理、分析和研究，得出以下軟件供應鏈風險的 8 項典型特征，如圖 2-12 所示：影響范圍廣危害損失大發酵周期長攻擊面廣傳播性強隱蔽性強溯源困難攻擊效率高軟件供應鏈風險特征圖 2-12 典型特征影響范圍廣傳播性強軟件供應鏈簡單拆分為軟件設計開發環節、軟件分發和用戶下載的交付環節、以及用戶的使用環節，這三大環節環環相扣構成其鏈狀結構。這種鏈

78、狀結構中每個環節都面臨著安全風險，致使攻擊面多，隨著軟件供應鏈的暴露面越來越多，攻擊者利用其攻擊的情況也就越來越多，對于上下游“感染”的機率也會更大，使得傳播影響的范圍更廣泛。2021 年 12 月 9 日曝出的 Log4j2 安全漏洞事件，是典型的基于開源組件漏洞引入導致的軟件供應鏈安全漏洞事件。該漏洞影響范圍極大，據粗略統計該漏洞影響 6 萬+流行開源軟件，影響 70%以上的企業線上業務系統，IT 通信（互聯網）、高校、工業制造、金融、政府、醫療衛生、運營商等幾乎所有行業都受到波及。上文提到的 VxWorks Urgent11 事件，單一組漏洞便影響了全球 20 億臺類型設備。軟件供應鏈涉

79、及對象眾多，如軟件供應商、下游用戶等比較多，當軟件供應鏈遭受攻擊時，容易對上下游帶來不利影響，攻擊者可以通過軟件供應鏈的上下游關系，對其它鏈條的對象發起裂變式惡意攻擊。比如從上游開 29發環節發生的攻擊，一旦成功就會波及軟件供應鏈的中下游，從過往案例看，此類惡意攻擊的效果比較明顯，且影響深遠。2017 年 NotPetya 攻擊和 Equifax 數據泄露影響了數百萬用戶。同年，勒索軟件變種 Petya 攻擊烏克蘭，使得烏克蘭首都機場、國家儲蓄銀行遭遇重大損失。2020 年爆發的 SolarWinds 事件直接將國家級網絡攻擊的關注推至新高，無論從規模、影響力和潛在威脅性來看，都堪稱過去十年最

80、重大的網絡安全事件。這些攻擊事件都將攻擊行為上升到了國家高度，對被攻擊國家的大型機構、基礎設施以及大型企業等帶來了威脅且規模龐大，這類攻擊對國家戰略布局都有深遠影響，這也是軟件供應鏈攻擊的危害之處，也是近年來備受黑客青睞的攻擊方式。危害損失大隱蔽性強觀察發現，軟件供應鏈攻擊的方式多樣，通常不具有一致性，從近年來發生的多起典型軟件供應鏈事件就可以看出這一特性。這樣也給此類攻擊的防御帶來了一定的難度，略有無跡可尋的態勢。例如，2015 年 9 月的 XcodeGhost 開發工具污染事件，造成至少 692 種 APP 受污染，過億用戶受影響，受影響的包括了微信、滴滴、網易云音樂等著名應用。2017

81、 年 9 月的 CCleaner 惡意代碼植入事件，感染全球2000 萬用戶。WireX Android 僵尸網絡攻擊事件影響了全球 100 多個國家，7 萬多手機受到感染。NotPetya 勒索病毒事件，使得政府、銀行、電力系統、通訊系統等都不同程度地受到了影響。部分事件在 2.1 小節中也有提及。軟件供應鏈的鏈狀結構特點使其每個環節面臨不同的安全風險，自然衍生出不同的攻擊手法，例如，針對開發環節的源代碼和開發工具污染，針對交付環節的下載網站和軟件更新網站攻擊，針對使用環節的升級更新劫持等。攻擊者針對各環節的不同脆弱點實施不同攻擊，再依賴供應鏈上的信任關系以逃避傳統安全產品的檢查，沿著供應鏈

82、向后滲透，從而實施對目標網絡的滲透及非法攻擊。不管是哪種攻擊形式，都對企業造成了嚴重危害。觀漏洞事件軟件供應鏈攻擊往往是通過騙取機構之間的信任，在用戶和開發者毫無感知的情況下實施攻擊行為產生巨大的安全威脅。在軟件開發環節中，對于源代碼、庫的篡改或偽造是很難發現的，這些披著“合法”外衣的惡意軟件能夠輕易規避安全檢測，使其能夠長期潛伏在目標系統中而不被發現，具有極強的隱蔽性。2020 年爆發的 SolarWinds 事件，隱蔽性處于其攻擊思想絕對首位，攻擊者選擇源代碼階段，且選擇代碼倉庫為發起感染的位置，并選擇非常深層次的調用堆棧，以降低代碼重構期被發現的可能性，同時在編碼上，高度仿照了 Sola

83、rWinds 的編碼方式與命名規范和類名等，成功繞過了 SolarWinds 公司復雜的測試、交叉審核、校驗等多個環節，在技術和思維上已大大超過常規行動體。30發酵周期長溯源困難軟件供應鏈風險典型特征中包括發酵周期長這一典型特征，披露出的安全漏洞修復，但發布的漏洞代碼依舊可以被網絡攻擊者所利用，漏洞利用事件持續發酵，影響著軟件供應鏈的安全。2017 年，Apache Struts 2 被曝存在遠程命令執行漏洞，漏洞編號 S2-045，CVE 編號 CVE-2017-5638，在其發布更新包修復的 48 小時之內，該漏洞的利用代碼被發布在 GitHub 上，隨后 Cisco Talos 團隊監測

84、到了大量漏洞利用事件。此后披露出的 Equifax 漏洞事件、2018 年 3 月的 AADHAAR 數字認證信息泄露事件、2020 年 5月“8220 團伙”入侵企業內網挖礦事件等，都是利用未修復的 S2-045 漏洞發起的攻擊。由于大量引入開源組件成為了快速響應客戶需求、提高軟件開發效率、節省開發時間的主流解決方案，安全風險也隨之而來。隨著開源組件的規模越來越大，軟件供應鏈的復雜度增大，當爆發出安全漏洞事件時，難以溯源到并修復存在安全漏洞的組件。并且一旦軟件中一個供應鏈環節使用了含有安全缺陷的開源軟件，并且被編譯為可執行代碼后，由于代碼使用者無法修改這些含有安全缺陷的可執行軟件，導致軟件供

85、應鏈的這個環節永遠存在無法消除的安全威脅和隱患，SolarWinds 攻擊事件就是典型案例。Kevin Mandia（FireEye CEO）：“我們投入了 100 名左右的人員，總共進行了 10000 小時的詳細調查，我們依舊不知道攻擊者的入侵路徑。因此我們只好更進一步，反編譯了 18000 個更新文件，3500 個可執行文件，得到超過一百萬行的反編譯代碼，進行詳細的代碼審計，工作了 1000 個小時以上，才得出結果，這就是為什么我們這么難以發現它?！眻D 2-13 Kevin Mandia（FireEye CEO）31由此針對軟件采用供應鏈溯源技術愈加重要，通過建立全球開源軟件的傳播態勢感知

86、和預警機制，攻克軟件供應鏈中軟件來源電子標簽技術，實現對供應鏈各環節中軟件來源的溯源機制，以解決軟件供應鏈安全風險難溯源的問題。攻擊面廣攻擊效率高相較于傳統的針對軟件漏洞的攻擊，軟件供應鏈攻擊從軟件本身擴展為軟件以及內部的所有代碼、模塊和服務，以及與這些模塊相關的供應鏈上游供應商的編碼過程、開發工具和設備，致使攻擊面增多，大大增加了攻擊途徑，為攻擊者提供了便利。2015 年 9 月 14 日“XcodeGhost”惡意攻擊事件對開發工具的污染。2017 年 8 月 WireX BotNet 攻擊事件在用戶下載環節偽裝成普通的安卓程序發動了較大規模的 DDoS 攻擊。2021 年 4 月 Git

87、Hub Actions 攻擊案例，利用 GitHub 的 CI/CD 基礎設施非法挖掘加密貨幣。隨著軟件供應鏈攻擊面的增大，在軟件供應鏈攻擊中攻擊者僅需對某一薄弱環節進行軟件攻擊或篡改，就可能引起引起軟件供應鏈安全問題，產生巨大的安全危害。而這種投入產出比高的攻擊特點，一直是網絡攻擊者熱衷的滲透打點手段，也是企業、個人及安全保障團隊難以完全杜絕的攻擊場景。2017 年多款 Python/Nodejs 庫包被爆存在惡意代碼，主要利用名稱相似性誤導用戶安裝，數萬主機誤安裝受到影響。2021 年堪稱“核彈級”的安全漏洞事件 Log4j2.x，其危害程度極高，影響范圍巨大，但利用方式十分簡單直接，攻擊

88、者僅需向目標輸入一段代碼，不需要用戶執行任何多余操作即可觸發該漏洞，使攻擊者可以遠程控制用戶受害者服務器。32Linux 操作系統的作者 Linus Torvalds 曾這樣表達開源項目的優勢：眾人的關注使 BUG 變少。這也許是一個事實，但是如果同樣的關注正在尋找的是可以利用的漏洞呢？我們至今無法逃脫另一個人類社會的事實：并非所有人都懷抱善意。任何擁有 GitHub 帳戶的人都可以向關鍵庫貢獻代碼，這吸引了很多偉大的貢獻者，但也摻雜了很多居心叵測的行為。2.3 開源軟件供應鏈攻擊不斷增多軟件供應鏈攻擊往往不是針對性的，更多是機會性的，攻擊者通常不會通過目標逆向，找到軟件的供應商，進而展開一系

89、列攻擊。更多是在不同的階段，尋找合適的機會發起攻擊。比如，在開發過程中，軟件開發人員經常使用開源代碼庫來構建應用程序，當攻擊者將惡意代碼插入到可公開訪問的代碼庫中時，惡意代碼將植入到代碼片段中。當開發人員使用代碼庫中的代碼時，惡意代碼將會被植入，攻擊者便可以通過此類惡意代碼對目標展開攻擊，進而造成嚴重危害。根據 2021 年開源安全與風險分析（OSSRA）報告顯示，84%的代碼庫至少存在一個漏洞，每個代碼庫平均有 158 個漏洞?？梢?，開源軟件供應鏈攻擊產生的機會性是非常高的。圖 2-14 開源安全與風險分析（OSSRA）報告數據 33這些行為通常是隱蔽的。在一些攻擊事件中，我們看到攻擊者會申

90、請為少數管理員進行維護的開源項目或庫貢獻自己的代碼，這些開源項目雖然維護者不多，但在某一些領域相對流行，甚至會被一些大型企業的開發團隊所采用。由于管理人員較少，項目的擁有者通常很愿意接納新的維護申請，并對提交的代碼疏于防范。此時攻擊者悄悄植入惡意代碼和腳本，就成為了自然而然的事情。這些有意植入的開源漏洞助長了攻擊者對開源軟件攻擊的意愿，同時也大大提升了對下游的終端應用進行滲透的收益。342.4 軟件供應鏈安全常見風險在軟件供應鏈安全白皮書（2021）中針對軟件供應鏈安全風險進行了分析，從軟件供應鏈風險現狀、風險因素、軟件供應鏈的漏洞類型、軟件供應鏈的攻擊類型四個維度為大家描述了軟件供應鏈的安全

91、風險。此次基于過往的內容做了更新和補充，以更完整的視角為大家分享軟件供應鏈安全常見的風險問題。1.軟件依賴進口，源頭難以控制 目前，我國在國家信息建設中關鍵軟件技術方面還無法實現完全自主研發可控，諸多核心行業的關鍵基礎軟件長期依賴進口，這為我國的軟件供應鏈安全留下了難以估量的安全隱患。軟件供應鏈上的任一環節出現問題，都有可能帶來嚴重的安全風險，在國家關鍵基礎設施中過度使用從國外引進的技術或軟件產品，將加大我國軟件供應鏈安全出現威脅的可能性，危害國家信息安全，同時也會給國家經濟安全帶來嚴重的隱患。除此之外，西方大國還借助其在部分 IT 領域的技術優勢，在相關軟硬件產品內預置后門，通過我國進口其軟

92、件產品將安全威脅帶入國內，非法獲取我國重要的信息數據。因此，長期依賴軟件進口，將難以從軟件生產的源頭進行安全治理，會加劇我國軟件供應鏈所面臨的安全風險，影響我國推進軟件供應鏈安全的進程，甚至會威脅到國家安全。2.開源存在缺陷，引入安全風險 為了加快業務創新，應用開源技術提高開發效率已經成為企業的主流選擇，但也導致企業對復雜的軟件供應鏈的依賴日益增加。盡管開放源碼組件具有許多優點，但它的廣泛應用也帶來了新的安全挑戰，一方面由于開發者自身安全意識和技術水平不足容易產生軟件安全漏洞，另一方面也無法避免惡意人員向開源軟件注入木馬程序進行軟件供應鏈攻擊等安全風險的存在。據 Sonatype 發布的202

93、1 State of the Software Supply Chain報告數據顯示，供應鏈攻擊呈指數級增長，2021 年全球軟件供應鏈攻擊增加了 650%。開源漏洞在流行項目中最為普遍，29%的流行項目至少包含一個已知的安全漏洞。開源組件的使用增加，其安全性已經成為影響軟件供應鏈安全的重要一環。35圖 2-15 軟件供應鏈攻擊增加了 650%3.重視程度不夠，安全防護不足 由于安全與敏捷開發往往呈對立關系，開發者為了提高效率，往往會忽視掉軟件供應鏈的安全性，安全保障過程被孤立，實行“業務先行”的模式。然而，業務系統從設計、編碼、測試到上線運行各個環節都有可能出現安全漏洞，給業務系統帶來安全風

94、險。業務系統中水平/垂直越權、批量注冊、業務接口亂序調用等業務邏輯漏洞和第三方開源組件漏洞頻發，高危的安全漏洞一旦被利用，可能會造成嚴重的信息泄露或系統中斷問題。而且，企業對軟件供應鏈安全技術研發的投入遠遠不夠，敏捷開發與快速迭代導致企業往往在加快開發進度的同時忽略掉部分安全隱患和響應效率，來彌補開發過程中時間的匱乏。高速運轉的敏捷開發運營模式將傳統的安全工作甩在身后，僅在上線運行階段開展安全風險控制工作，已無法防御由網絡技術發展帶來的各項安全威脅。4.管理制度不完善，安全評估缺失 企業軟件供應鏈管理制度不完善，缺乏針對軟件生產等重要環節的管控措施。而且，企業軟件供應鏈透明度不高，安全評估缺失

95、，難以依據安全風險劃分供應商的安全等級，從而進行針對性的安全管理。包括部分企業開源代碼管理機制尚不完善，在軟件開發過程中，隨意使用開源組件的現象屢見不鮮，管理者和程序員無法列出完整的開源組件的使用列表，對軟件供應鏈安全問題嚴重缺乏重視，給軟件供應鏈管控帶來極大的安全挑戰。5.網安意識薄弱，缺少安全培訓網絡安全歸根結底是“人”的安全。公司的員工是抵御網絡攻擊的第一道防線，當對員工沒有進行定期的網絡安全意識培訓時，員工在缺乏安全意識的情況下缺少對敏感數據潛在攻擊的識別能力，極易通過人而造成攻擊 的產生。攻擊者一旦突破防線，進入業務系統，便可以實現上下游的攻擊，對企業組織造成嚴重后果。軟件供應鏈安全

96、面臨的挑戰03開源技術及云原生技術的應用正逐漸形成主流趨勢，不斷推動著深度信息技術的創新發展，驅動著產業數字化轉型進程的不斷加速，但與此同時，軟件供應鏈也越來越趨于復雜多樣化，安全風險加劇，針對軟件供應鏈薄弱環節的網絡攻擊隨之增加。除了國際層面上軟件供應鏈競爭環境加劇，以及安全管理制度不完善等外部因素外，由云原生和開源帶來的下一代軟件供應鏈安全正面臨著新的安全挑戰。373.1 開源技術的使用，安全風險加劇作為業務應用程序的重要組成部分，開源軟件已成為網絡空間的重要基礎設施。作為創新的基礎，開源軟件需求量正呈爆炸式增長，根據 Sonatype 發布的2021 State of the Softw

97、are Supply Chain報告可以了解到，2021 年世界各地的開發者請求超過 2.2 萬億個的開源包，意味著開源組件的下載量同比增長 73%。為實現企業業務的快速開發和科技的創新，從根本上要求開發人員頻繁而有效地重用代碼，從而又導致了開發人員對第三方開源組件的嚴重依賴。開源軟件的大量使用幫助企業加速了軟件開發的生命周期，降低了開發成本，但同時也帶來了兩大安全風險：嵌入到開發流程中的安全漏洞風險和構成法律或知識產權（IP）風險的許可證問題。3.1.1 安全漏洞風險因其開放、自由、共享等特性，開源技術可以從代碼托管平臺、技術社區、開源機構官方網站等渠道獲取，或通過合作研發、商業采購等方式引

98、入開源代碼、開源組件、開源軟件和基于開源技術的云服務等。開源社區參與者廣泛分布于全球各地，沒有中央權威來收錄漏洞信息，保證開源軟件的質量和維護。開發人員不了解開源軟件信息，缺少漏洞跟蹤能力，漏洞修復時間滯后，增加了軟件供應鏈安全治理難度。本質上來講，開源軟件并不比自定義代碼更安全，與任何軟件一樣，它可能包含導致安全問題的漏洞。而且，大部分軟件開發人員在引入第三方庫的時候，并沒有關注引入組件是否存在安全隱患或者缺陷，并且由于開源軟件之間的關聯依賴關系錯綜復雜，一旦開源軟件存有惡意代碼或病毒，將會產生蝴蝶效應，導致所有與之存在關聯依賴關系的其他軟件系統出現同樣的漏洞，漏洞的攻擊面由點及面呈現出爆炸

99、式的放大效果，給用戶帶來嚴重危害。圖為信通院 2021 年發布的2021 年開源軟件供應鏈安全風險研究報告中組件漏洞依賴層級傳播范圍，相關數據表明一級組件漏洞傳播影響范圍擴大了 125 倍，二級傳播影響范圍擴大了 173 倍。圖 3-1 組件漏洞依賴層級傳播范圍 383.1.2 許可證合規及兼容風險開源軟件對用戶是免費的，但并不意味著可以在不遵守其它義務的情況下使用。隨著開源技術的發展，結合各自需要，開源軟件一般都有對應的開源許可證（Open Source License），用以對軟件的使用、復制、修改和再發布等進行限制。常見的開源軟件許可證根據開放程度可以大致分為兩大類：寬松自由軟件許可協議

100、（“Permissive Free Software Licence”）和著作權許可證（“Copyleft License”）。寬松自由軟件許可協議包括 MIT、Apache、BSD 等，允許用戶自由復制、修改、許可和再許可代碼，開源軟件源代碼變更或衍生軟件可以變為專有軟件；著作權許可證包括 GPL 許可證、MPL 許可證和 LGPL 許可證等，強制要求公開源代碼變更或衍生軟件開源。Contrast Security發布的 2021 State of Open-Source Security Report 報告中相關數據表明，幾乎所有（99%）的組織都至少有一個高風險的 Java 許可證，69

101、%的 Java 應用程序和 33%的 Node 應用程序中至少存在一個高風險許可證，95%的 Java 應用程序和 70%的 Node 應用程序至少存在一個未知或可變風險的許可證。如果不了解開源軟件的知識產權或未按照開源許可證使用開源軟件，很可能侵犯他人知識產權，引起法律糾紛，面臨重大風險。同時開源軟件可能存在層層依賴關系，企業組織在使用開源過程中不斷加入新的開源組件，可能存在許可證不兼容的風險。圖 3-2 JAVA 許可證使用 39圖 3-3 NODE 許可證風險 403.2 云原生技術的興起，復雜度增加以容器、微服務、DevOps、不可變基礎設施為基礎的云原生技術加快了業務響應速度，有效縮

102、短了交付周期，降低了運營成本，然而云原生技術的發展極度加大了軟件供應鏈的復雜性，為軟件供應鏈帶來了新技術風險和新安全組織模式的雙重挑戰。其中 DevOps 和持續交付打破開發與運營之間的壁壘，實現軟件開發的自動化、敏捷性，幫助組織實現了應用程序更快更可靠的大規模交付，同時開發人員出于對速度和效率的追求，經常會利用開源項目的框架進行二次開發或引用開源組件，在云環境中，這些組件常以基礎鏡像的方式在軟件供應鏈里傳遞，并上傳至鏡像倉庫，從而被容器所使用。若開源組件和框架中存在安全漏洞，那么鏡像軟件就有可能存在漏洞，鏡像文件完整性被破壞，鏡像文件遭受惡意配置或者更改（比如上傳或者下載過程被修改，植入后門

103、）導致容器被利用勢必會引入所開發的應用中，導致大面積的風險漏洞的存在。據Gartner預測，隨著越來越多的企業步入云原生化的進程，更多地采用云原生應用程序和基礎設施，到2025年，成熟經濟體中 85%的大型企業將更多地使用容器管理，遠高于 2022 年的 30%。容器化的使用，使得應用部署和運行非常便利，但通過引入容器和 K8s 給軟件供應鏈帶來了更多不可控的第三方依賴，導致漏洞利用、容器逃逸、拒絕服務等風險的存在，從而將安全漏洞大面積引入到云環境中，以致威脅整個云生態。云原生時代下鏡像的使用鏡像構建構建平臺&IDE鏡像傳輸鏡像倉庫鏡像運行/升級K8s運行時圖 3-4 云原生時代下的軟件供應鏈

104、 413.3 軟件供應鏈安全治理痛點近年來，全球范圍內有關軟件供應鏈安全的攻擊事件層出不斷，對個人、企業，甚至國家安全都造成了嚴重威脅。典型的 Apache Log4j2 漏洞被業內稱為“核彈級”的安全漏洞，其嚴重性、廣泛性對各個領域的波及面非常大，讓企業組織意識到做好軟件供應鏈威脅治理迫在眉睫。但在軟件供應鏈治理的過程中，存在一些難點會讓實踐裹足不前。軟件供應鏈安全治理通常具有如下四個痛點：1.“理不清”2.“看不見”3.“找不到”4.“治不了”企業不清楚在系統中使用了多少第三方軟件和組件。目前很多企業的現狀是，在每一次快速迭代和快速發布過程中，都會引入一部分第三方組件，但是由于團隊多、涉及

105、的業務范圍廣，導致無法清楚地知道具體使用了哪些。而且，第三方組件通常又會依賴其它更多組件，多級依賴關系使得整個組件結構更加復雜，這種結構的安全性對于應用的研發和使用來說，很多時候也是未知的，不可控的。企業在使用第三方組件的過程中，不知道它們中有的已產生過安全漏洞和知識產權風險。很多企業會使用非常老的組件和軟件，其中很多爆發過安全漏洞，但沒有及時去更新。對于這些已知漏洞的風險隱患，企業無法獲悉，這種不可見性增加了危險系數。企業在第三方組件出現漏洞的時候，無法快速地定位受影響的組件以及評估影響的范圍。例如在 Log4j2 事件和Spring事件爆發時，安全工程師希望能夠立即找到自身業務系統中受影響

106、的軟件和組件，進而設法進行治理。但是漏洞數據源的回溯需要時間，且隨著軟件成分的日漸復雜，類似的安全問題更加嚴峻。當企業明確漏洞影響的范圍以及受影響的組件并定位到具體項目后，就需要進行相關治理工作，對組件進行相應的評估、緩解和修復。當前很多企業缺乏軟件供應鏈安全治理相關知識、技能和工具，對風險緩解的方法粗獷且效率低下。42軟件供應鏈安全治理體系04由于軟件供應鏈安全面臨著嚴峻的挑戰和治理痛點，很多機構推出了針對軟件供應鏈的安全治理體系，以求系統化地、基于完整的視角解決軟件供應鏈安全威脅問題。434.1 軟件供應鏈安全治理框架4.1.1 Google SLSA 框架針對軟件供應鏈攻擊問題，谷歌提出

107、了 SLSA（Supply Chain Levels for Software Artifacts，軟件制品的供應鏈級別）解決方案，旨在確保軟件開發和部署過程的安全性，專注于緩解由于篡改源代碼、構建平臺或構件倉庫而產生的威脅。在其當前狀態下，SLSA 是一套被逐漸采用的安全準則，由業界一致認可。在最終形式中，SLSA 在可執行性方面與最佳實踐列表有所不同：它將支持自動創建可審核元數據，這些元數據可以輸入到策略引擎中，以便為特定包或構建平臺提供“SLSA 認證”。SLSA 被設計成持續的和可操作的，并且在每一步都提供最優措施。一旦一個組件達到了最高級別，用戶就可以確信它沒有被篡改，并且可以安全地

108、追溯到源代碼。SLSA 側重于以下兩個主要原則：（1）非單方面：任何人都不能修改軟件供應鏈中任何地方的軟件制品，除非經過至少一個其他“受信任的人”的明確審查和批準。目的是預防和盡早發現風險的變化。（2）可審計：軟件制品可以安全透明地追溯到原始的、人類可讀的來源和依賴項。主要目的是自動分析來源和依賴關系，以及臨時調查。盡管并不完美，但這兩個原則為廣泛的篡改、混淆和其他供應鏈攻擊提供了實質性的緩解。為了根據上述兩個原則衡量供應鏈的保護程度，Google 提出了 SLSA 級別，SLSA 由四個級別組成，其中 SLSA 4 表示理想狀態。較低級別表示具有相應完整性保證的增量里程碑。這些要求的定義如下

109、表所示。44表 4-1 SLSA 框架要求 45SLSA 1SLSA 2SLSA 3SLSA 4要求構建過程完全腳本化/自動化，并生成出處。出處是關于如何構建中間件的元數據，包括構建過程、頂級源代碼和依賴關系。了解出處可以讓用戶做出基于風險的安全決策。盡管 SLSA 1 的源代碼不能防止篡改，但它提供了基本級別的源代碼識別，有利于漏洞管理。需要使用版本控制和生成經過身份驗證出處的托管構建服務。這些額外的要求使用戶對軟件的來源有了更大的信心。在這個級別上，源代碼在構建受信任服務過程中可以防止被篡改。SLSA 2 還提供了到 SLSA 3 的簡單升級途徑。進一步要求源代碼和構建平臺分別滿足特定標準

110、，以保證源代碼的可審計性和完整性。設想有這么一個認證過程，通過這個過程，審計人員可以證明平臺符合要求，用戶就可以直接依賴它了。SLSA 3 通過防御特定類型的威脅（如交叉編譯污染），提供了比低級別更強大的防篡改保護。目前是最高級別的，需要雙人對所有變更進行審查，并且需要一個封閉的、可復制的構建流程。雙人評審是一種行業最佳實踐，可以發現錯誤并阻止不法行為。封閉的構建保證了源代碼的依賴列表是完整的?？蓮椭频臉嫿?，雖然不是嚴格要求的，但是提供了許多可審計性和可靠性的優勢?？偟膩碚f，SLSA 4 讓用戶對軟件沒有被篡改有絕對的信心。SLSA 是一個用于端到端軟件供應鏈完整性的實用框架，基于一個在世界上

111、最大的軟件工程組織中被證明可以大規模工作的模型。對于大多數項目來說，實現最高級別的 SLSA 可能很困難，但是較低級別的 SLSA 所認可的持續改進將在很大程度上提高開放源代碼生態系統的安全性。464.1.2 CNCF in-toto 框架2022 年 3 月 11 日，CNCF 發文表示，CNCF 技術監督委員會（TOC）已投票接受 in-toto 作為 CNCF 的孵化項目。in-toto 是一個用于保護軟件供應鏈完整性和可驗證性的系統。它通過使用戶能夠收集到關于軟件供應鏈行為的信息，并允許軟件消費者和項目經理發布關于軟件供應鏈實踐的政策來保護軟件供應鏈的完整性和可驗證性，這些政策可以在部

112、署或安裝軟件之前進行驗證。簡而言之，它有助于捕獲軟件供應鏈中發生的事情，并確保它按照定義的策略發生。in-toto 的實現主要包含三個組件：用于生成和設計供應鏈布局的工具。項目所有者將使用此工具生成所需的供應鏈布局文件。其中供應鏈布局（也稱布局、布局元數據）是指一個簽名文件，規定了在軟件供應鏈中創建最終產品需要執行的一系列步驟。布局包括有序步驟、這些步驟的要求以及負責執行每個步驟的參與者（或工作人員）列表。供應鏈中的步驟由項目所有者布置。一種工具，工作人員可以使用該工具創建有關步驟的鏈接元數據。例如“in-toto-run.py”。其中，鏈接是指執行供應鏈步驟或檢查時收集的元數據信息，由執行該

113、步驟的官員或執行檢查的客戶簽名。此元數據包括材料、產品和副產品等信息?？蛻粲脕韺ψ罱K產品進行驗證的工具。此工具使用上述工具生成的所有鏈接和布局元數據，它還按照布局的指示執行檢查步驟。此工具通常包含在包管理器或系統安裝程序中。例如“in-toto-verify.py”。下面我們將描述一個簡單的場景，對框架系統的工作流進行一個說明：項目所有者 Alice 希望 Diana 寫一個 Python 腳本（foo.py），且希望 Bob 將腳本打包成一個 tarball（foo.tar.gz）。該壓縮包將作為最終產品的一部分發送給客戶 Carl。在向 Carl 提供壓縮包時，Alice 將創建一個布局文

114、件用來說明以下內容：腳本是 Diana 寫的；將腳本打包是由 Bob 完成的；壓縮包中包含的腳本與 Diana 編寫的腳本匹配。因此如果 Bob 是惡意的，或者打包程序有錯誤，Carl 為了能夠檢測到問題，在最終產品中要求四個文件：（1）Alice 的布局文件，描述上面列出的要求；（2）一段能夠對應于 Diana 編寫腳本的鏈接元數據；（3）一段Bob 打包腳本步驟的鏈接元數據；（4）目標文件（foo.tar.gz）也必須包含在最終產品中。當 Carl 驗證最終產品時，他的安裝程序將執行以下檢查：47(1)布局文件存在并使用受信任的密鑰（在本例中為 Alice 的密鑰）進行簽名；(2)布局文件

115、中的每個步驟都有一個或多個由預期函數簽名的相應鏈接元數據文件，如布局文件中所描述的信息（在本例中為 Bob 和 Diana 提供的鏈接元數據）；(3)鏈接元數據中列出的所有材料和產品都能夠一一對應起來，正如布局文件描述的信息一樣，防止包在沒有記錄的情況下被更改，或在傳輸過程中被篡改。（在本例中 Diana 和 Bob 的材料應相匹配）；(4)最后，檢查步驟在客戶端運行，檢查壓縮包，以驗證提取的 foo.py 文件是否與 Diana 編寫的文件相匹配。如果這些所有驗證都通過，則安裝將照常繼續。軟件供應鏈定義（Alice簽名的布局文件）步驟（由工作人員執行）檢查（由用戶執行）證據（步驟鏈接由Din

116、an和Bob簽名）writewrite.linkpackage.linkuntar.linkpackageuntarfoo.py：0 xAfoo.py：0 xAfoo.py：0 xAfoo.tar.gz：0 xBfoo.tar.gz：0 xB圖 4-1 此示例的流程4.1.3 Microsoft SCITT 框架Microsoft 的供應鏈完整性、透明度和信任(SCITT，The Supply Chain Integrity，Transparency and Trust)計劃是一套已提議的行業標準，用于管理端到端供應鏈的產品和服務的合規性。它支持對產品和服務的持續驗證，其中可以確保實體、證據、

117、政策和制品（軟件或硬件）的真實性，并且可以保證實體的行為是經過授權的、不可否認的、不可變的和可審計的。Microsoft 在之前將 SCITT 稱為 SCIM（Supply Chain Integrity Model，供應鏈完整性模型），包括在去年提交給 NIST 的，與 EO 14028 相關的提交中。SCIM 與開發和實施供應鏈完整性要求的迭代方法保持一致，允許根據不斷變化的威脅模型和實踐隨著時間的推移進行增強。分階段推出需求以提高供應商規劃和工程的清晰度，并最大限度地減少中斷。其工作流程如圖所示，描述了供應鏈完整性模型中實體之間的制品、證據和策略流。48供應商認證者用戶供應商認證者存儲制

118、品(a)策略 （c）用戶代理（d）策略管理者存儲證據 （b）圖 4-2 SCIM 的工作流程圖 4-3 SCIM 在軟件開發生命周期（SDLC）中的應用其中，供應商創建制品（a），認證者創建證據（b）并提交到應用商店進行日志記錄、查詢和檢索。供應商和認證者可能是同一實體。策略管理器創建策略（c）并提交到存儲區，在其中記錄策略并可供查詢和檢索。用戶代理（d）接收制品（a），檢索證據（b）和策略（c），并驗證制品。下圖顯示了 SCIM 在軟件開發生命周期（SDLC）中的應用示例。當前 SCITT 行業標準還在制定中，隨著 NIST 對其不斷地完善，相信之后 SCITT 能夠發揮其更大的作用。開發人

119、員源代碼管理（SCM）構建環境包存儲庫運行環境策略存儲庫證據存儲庫 作為已批準開發人 員簽署的提交 來源出處可接受 第三方包與其 BOMs 匹配 部署輸出BOM與部署 負載相匹配 沒有已知的未緩解的 漏洞提交 提交簽名證明 構建觸發記錄 部署批準 部署完成 構建環境BOM 構建輸出 BOM SAST/DAST 掃描 結果 構建可接受的環境 BOM 構建輸出BOM與發 布的包相匹配 掃描結果可接受觸發構建發布部署 494.1.4 軟件供應鏈安全框架對比分析軟件供應鏈安全框架和模型的建立可以幫助企業組織理解軟件供應鏈安全活動的關鍵要素，從而幫助企業組織了解當前自身安全現狀，在企業構建的軟件供應鏈安

120、全治理與運營體系中選擇適合自身企業的安全活動或措施，制定相應的解決方案，進而使組織的軟件供應鏈安全逐漸成熟。上述三種軟件供應鏈安全治理框架對比分析如下：框架類型安全準則安全項目行業標準SLSA框架in-toto框架軟件供應鏈安全治理框架SCITT框架機構GoogleCNCFMicrosoft軟件供應鏈軟件供應鏈供應鏈適用范圍可操作性框架應用情況相同點SLSA框架遵循四個保證級別以確保完整性in-toto框架遵循低、中、高三個保證級別以確保完整性SCITT框架描述了傳達證據的原則和建議的模型，未指定實施要求由業界一致認可且逐漸應用的實用性模型框架落地，但未廣泛應用還在制定提議中應用上述三種軟件供

121、應鏈安全治理框架都可以依靠某種政策或策略從端到端的保障軟件供應鏈的完整性、不可否認性以及可審計等，提高了軟件供應鏈的透明度及可追溯性。表 4-2 軟件供應鏈安全治理框架 50圖 4-4 軟件供應鏈安全治理體系4.2 治理體系構建軟件供應鏈作為一個復雜、龐大的系統，難免存在薄弱環節，這就為攻擊者創造了一個契機，攻擊者無需進行代碼審計或漏洞挖掘，而是以軟件供應鏈中的薄弱環節為攻擊點進行軟件攻擊或篡改，發起軟件供應鏈攻擊，引起軟件供應鏈安全問題，從而產生巨大的安全危害。因此，保障軟件供應鏈安全，若僅僅對某單一環節進行安全防護是遠遠不夠的，需從軟件供應鏈的供應過程及軟件自身安全出發，基于 4.1 節所

122、介紹的軟件供應鏈安全治理框架，本報告構建了一套較為全面系統的軟件供應鏈安全治理體系，借助安全自動化工具，實現對軟件供應鏈全鏈路的安全風險治理，如 4-4 所示。軟件供應過程風險治理主要是指對軟件產品由供應商運輸給最終用戶的這一供應過程的風險治理以及供應過程中人員（包括供應商、管理人員、開發人員、測試人員、運營人員、終端用戶等）的安全管理；軟件開發生命周期安全風險治理主要指軟件開發過程中從需求設計、開發測試、發布運營、下線停用等環節進行全流程的閉環安全風險監控及安全管理，確保從軟件生命周期的源頭保障軟件供應鏈安全，實現開發運營的安全閉環。軟件供應過程風險治理需求設計開發測試發布運營下線停用干系人

123、管理人員管理軟件開發生命周期安全風險治理軟件來源1.供應商資質2.開源社區活躍度1.安全需求分析2.安全設計原則3.確定安全標準4.攻擊面分析5.安全隱私需求設計知識庫等1.安全編碼2.管理開源及第三方組件安全風險3.變更管理4.代碼安全審查5.配置審計6.安全隱私測試7.漏洞掃描8.模糊測試9.滲透測試等1.發布管理2.安全性檢查3.事件響應計劃4.安全監控5.安全運營6.風險評估7.應急響應8.升級與變更管理9.服務與技術支持10.運營反饋等1.制定服務下線方案與計劃2.明確隱私保護合規方案，確保數據留存符合最小化原則軟件供應鏈任一環節的干系人，包括供應商、管理人員、開發人員、測試人員、運

124、營人員、終端用戶等，都應向其傳達“安全可讓每個個體受益”的理念，以提高其安全意識。1.培訓賦能2.安全績效考核3.最小特權原則4.零信任原則5.明確規定安全策略軟件資產管理1.供應鏈清單管理2.版本管理3.漏洞管理服務支持1.產品及用戶文檔2.服務水平協議3.信息安全服務協議1.應急預案2.應急響應團隊安全應急響應軟件安全合規1.軟件物料清單2.軟件安全要求3.軟件合規要求4.安全測試及評審報告5.安全監護防護軟件供應商設計開發運營下線用戶 514.3 軟件供應過程風險治理軟件供應過程風險治理，主要包括軟件來源管理、軟件安全合規性管理、軟件資產管理、服務支持及安全應急響應等，以提升軟件供應鏈可

125、追溯性和透視性，如圖 4-5 所示。軟件供應過程風險治理評估供應商資質評估軟件社區活躍度軟件來源產品及用戶文檔服務水平協議信息安全服務協議服務支持應急預案應急響應團隊安全應急響應軟件物料清單（SBOM）軟件安全要求軟件合規要求安全測試評審報告軟件安全合規性供應鏈清單管理版本管理漏洞管理軟件資產圖 4-5 軟件供應過程風險管理4.3.1 軟件來源管理企業對軟件來源進行管理以確保軟件的來源安全可信，包括評估軟件供應商資質、軟件社區活躍度等。其中軟件供應商作為當前較為重要的軟件來源，對軟件供應商的企業資質、能力資質等進行評估至關重要，接下來主要從軟件供應商風險管理流程、軟件供應商評估模型、供應商風險

126、評估流程這三方面詳細介紹軟件供應商風險治理。1.軟件供應商風險管理流程基于 2021 年懸鏡安全出版的軟件供應鏈安全白皮書（2021）報告中提出的軟件供應商風險管理流程，我們對其進行了流程上的優化，如下圖所示。標準確立：結合企業自身需求的實際情況，規劃供應商管理計劃，構建軟件供應商評估模型，創建供應商庫存并跟蹤業務定義的關鍵屬性，制定軟件供應商考核的評估標準及安全框架；供應商資質評估：根據制定的軟件供應商評估模型和相關標準，對初步符合要求的軟件供應商進行盡職調查，從如企業資質、市場影響力、技術儲備、創新能力、軟件質量、故障修復能力等多角度多維度進行綜合性資格評估，選出匹配度最高的供應商；52圖

127、 4-6 軟件供應商風險管理流程2.軟件供應商風險評估模型供應商風險評估是指企業通過對供應商的產品分析及企業過程的診斷，用于了解和降低與產品或服務的第三方供應商合作所帶來的風險。在購買或與第三方供應商合作時，組織容易受到各種風險的影響，例如安全漏洞，業務中斷，供應商不遵守法規和行業標準而造成的聲譽損害等。為了防止這些情況發生，企業應對其進行評估，對潛在風險進行識別、衡量和確定優先級，以確定潛在風險帶來的影響。供應商風險評估：對通過資格評估的軟件供應商進行安全風險評估，針對軟件供應商面臨的潛在的安全風險、存在的弱點以及有可能造成的影響綜合分析其可能帶來的安全風險進行評估；供應商風險監控：對軟件供

128、應商實施長期性的安全風險監控，持續識別和管理軟件供應商的安全風險，根據監測結果實施更新軟件供應商的風險管理策略；供應商退出：在供應商期限結束時，應再次審查合同，以確保所有義務都已得到履行，隨后進入退出程序，仔細考慮數據保存和處置，最后復盤，對軟件供應商風險管理系統及供應商準入機制進行持續的優化和改進。軟件供應商風險管理流程標準確立供應商資格評估供應商退出供應商風險監控供應商風險評估 53軟件供應鏈安全白皮書（2021）報告中提出了一種較為系統化、結構化的供應商風險評估模型，如下圖所示。技術儲備：評估軟件供應商是否擁有自主研發能力以及自主技術知識產權，對科技知識是否有進行不斷的積累和及時更新，對

129、企業提高技術水平、促進軟件生產發展是否有開展一系列的技術研究；企業資質：評估軟件供應鏈上的第三方供應商是否能夠提供軟件安全開發能力的企業級資質，是否具備國際、國家或行業的安全開發資質，在軟件安全開發的過程管理、質量管理、配置管理、人員能力等方面是否具備一定的經驗，具有把安全融入軟件開發過程的能力；質量承諾：評估軟件供應商的相關軟件產品是否符合國家及行業標準要求，信息安全和數據保護控制流程必須遵守法律、監管或合同義務以及任何行業標準的信息安全要求；財務實力：評估軟件供應商的財務能力以及穩定性，確保供應商具有穩定性和可靠性來提供業務所需要的服務；軟件適用性：評估軟件在開發部署以及動態運行時的適用性

130、，是否可以持續滿足新的需求；軟件成本：評估軟件供應商所提供的軟件成本是否存在虛報等現象，審查產品及相關服務是否可以按照合理的價格交付；內部管理能力：評估軟件供應商是否擁有完善的內部管理制度流程、有效的風險防范機制以及是否對員工定期進行安全培訓等，對供應商內部安全開發標準和規范進行審查，要求其能夠對開發軟件的不同應用場景、不同架構設計、不同開發語言進行規范約束，審查軟件供應商對其自身信息安全保密程度；軟件適用性：評估軟件在開發部署以及動態運行時的適用性，是否可以持續滿足新的需求；軟件供應商評估模型內部管理能力創新能力服務能力應急響應能力軟件交付能力合作能力技術儲備企業資質軟件成本財務實力質量承諾

131、軟件適用性圖 4-7 供應商風險評估模型 54 軟件成本：評估軟件供應商所提供的軟件成本是否存在虛報等現象，審查產品及相關服務是否可以按照合理的價格交付；內部管理能力：評估軟件供應商是否擁有完善的內部管理制度流程、有效的風險防范機制以及是否對員工定期進行安全培訓等，對供應商內部安全開發標準和規范進行審查，要求其能夠對開發軟件的不同應用場景、不同架構設計、不同開發語言進行規范約束，審查軟件供應商對其自身信息安全保密程度；創新能力：評估軟件供應商的綜合創新能力，包括技術創新能力、研究開發能力、產品創新能力以及生產創造力等；服務能力：評估軟件供應商的售前服務能力、培訓服務能力以及售后維護服務能力是否

132、滿足企業的要求，在合作期間內是否可以始終如一的提供高水平的質量和服務；應急響應能力：評估軟件供應商從軟件開發到運營階段是否持續實行實時監控機制，是否有利用適當的網絡和基于端點的控制來收集用戶活動、異常、故障和事件的安全日志，是否具有適當的業務連續性和恢復能力，以防止或減輕業務中斷和相關影響；軟件交付能力：評估軟件供應商在整個軟件及信息服務交付的過程中，是否能滿足軟件持續性交付的要求；合作能力：評估軟件供應商是否擁有高效的溝通渠道以及全面的解決方案，擁有共同的價值觀和工作理念有助于建立長期的合作關系。3.軟件供應商風險評估流程進行軟件供應商風險評估是任何成功的軟件供應商風險管理計劃中最關鍵的方面

133、之一。軟件供應商風險評估流程如下：第一步：進行背景調查，以確保供應商能夠制定并保持高質量的標準，而不會對公司及其客戶造成任何風險。主要工作包括但不限于列出當前所有供應商并對其進行排名，記下每個供應商的主要工作、哪些供應商有權訪問關鍵數據等信息，同時確認出最關鍵的軟件供應商，評估每個供應商的意外風險是否會對公司造成重大中斷，造成多大損失以及這種損失是否會影響客戶，并且考慮修復這些損失可能需要花費的時間。第二步：衡量供應商的可靠性和準確性。充分了解軟件供應商所有可能產生的風險類型，如 IT 中斷或故障風險、數據和隱私風險、合規風險、供應商更換風險等。并結合市場狀況、企業的供應成本以及本報告提出的軟

134、件供應商風險評估模型等實際情況，制定相應的軟件供應商風險評估標準，并量化其潛在風險，公式如下：（風險因素）的可能性 X（風險因素）的影響成本=風險 55如下圖所示，我們使用風險評估矩陣模板來衡量潛在風險的嚴重程度和可能性，分為低、中、高和嚴重，為每個條件選擇選項后，使用矩陣值評估每個風險的嚴重性級別。風險矩陣風險評級可能性嚴重性低0-接受可以正常運行中1-勉強接受在可控合理的范圍內采取緩解措施嚴重3-無法忍受暫?；顒拥?4610中中高可以接受對結果幾乎沒有影響風險不大可能發生不可能低25811中高嚴重可能會發生風險可能性較小中37912高高嚴重發生風險可能性較大勉強接受有影響但不影響最終結果不

135、能接受嚴重影響活動的過程和結果無法忍受可能導致災難性后果高2-不可接受在規定時段內降低風險圖 4-8 風險評估矩陣模板 56第三步：根據風險評估標準，選擇合適的軟件供應商，并對其進行供應商深入評估，包括但不限于評估供應商如何在整個項目周期中管理數據文檔計劃，以及供應商在發生意外安全事件（如數據丟失、攻擊事件、系統癱瘓）時的安全事件應急響應計劃。第四步：審查報告完成后，企業須與供應商管理層一起審查審計報告的結果，并允許供應商代表就審計中包含的績效數據提供反饋，進一步建立供應商績效目標和目的，以實現良好的合作關系?？偠灾?，供應商評估是為了確保良好的合作關系，同時這也是一個適用于當前供應商自身評估

136、的過程，用于衡量和監控其績效，以降低成本，降低風險并持續優化和改進。4.3.2 軟件安全合規性評審4.3.3 軟件資產管理軟件安全合規性評審是指針對軟件自身的安全及合規進行管控，確保軟件自身不存在安全及合規風險，包括提供軟件物料清單（SBOM）、軟件安全要求、軟件合規要求、安全測試及評審報告和安全監控防護等。SBOM 可以通過提高軟件供應鏈透明度，以達到降低網絡安全風險和總體成本的目的，目前已成為國際公認的重要方法論。Gartner 在Innovation Insight for SBOMs報告中提出，預計到 2025 年，60%負責開發關鍵基礎設施相關軟件的組織將在其軟件工程實踐中強制使用標

137、準化的 SBOM，比 2022 年（不到 20%）大幅上升。事實上，對于快速定位分析并解決新出現的漏洞和攻擊來說，生成SBOM并快速地獲取其信息已變得至關重要。政府和行業已經逐漸認識到 SBOM 對于軟件網絡安全的重要性。對于軟件供應商來說，構建 SBOM 提升了軟件供應鏈透明度，可以幫助企業組織全面洞察每個應用軟件的組件情況，從而更高效地定位并響應漏洞問題。此外，SBOM 的標準規范化有助于組織間的友好協作，進而提高客戶信任度；對于采購方來說，可以清晰直觀地看到其感興趣的產品信息，例如基線組件信息或許可信息等。對于運營商來說，SBOM 增加了軟件及其組件的可見性，有助于他們在其生產業務之前驗

138、證軟件的狀態。軟件像其它 IT 硬件設備一樣，作為企業的資產需要加以綜合管理。軟件資產管理旨在幫助企業降低成本并防范風險。軟件資產管理指針對軟件的供應鏈清單、軟件及源代碼版本、風險漏洞等信息進行統一管理。軟件供應鏈清單管理，指建立供應鏈清單信息，包括供應商相關信息、軟件類型、SBOM、采購時間、可使用版本、許可期限等內容。軟件及源代碼版本管理，指針對交付的軟件產品、源代碼及其配置庫信息等各個不同版本進行統一管理，自研代碼與第三方組件也應要進行獨立存放、目錄隔離等操作。漏洞管理，指對軟件供應鏈所涉及的軟件產品及服務及其所包含的第三方開源組件中所有涵蓋的漏洞進行統一的管理。574.3.4 服務支持

139、4.3.5 安全應急響應服務支持是用來支持軟件產品交付部署過程中的服務性活動，需供應商明確出軟件的服務支持方式以及服務水平、安全服務協議等內容。服務支持方式大多以產品、用戶文檔以及培訓咨詢等方式展示，主要用于說明軟件產品功能、對用戶使用進行指導、系統異常問題的解決處理等相關信息；服務水平協議，主要用于明確軟件交付部署方式、后續維保、新增需求的后續開發及服務支持方式等內容；信息安全服務協議，主要用于明確保密協議、知識產權歸屬及軟件交付安全標準等相關信息。供應過程是軟件產品或服務由供應商轉移到軟件用戶的過程，這個過程帶有傳播性，若其過程發生捆綁下載、下載劫持、物流鏈劫持等攻擊，風險傳播影響也將是不

140、可小覷的。因此，在該過程無論是企業內部還是供應商，建立成熟的應急響應機制是至關重要的。主要包括：1）應急預案，對于軟件供應鏈安全事件應急響應機制進行說明，包括事件分類分級處理、處理時效、響應流程等內容；2）應急響應團隊，明確軟件供應鏈安全事件應急響應處理團隊，明確人員職責及分工。58軟件供應鏈任一環節的干系人，如果出于方便等原因，引用未經審核的開源組件、下載非官方的軟件、工具等，都有可能帶來安全隱患。如 2015 年 9 月“XcodeGhost”惡意攻擊事件，開發者為了方便從非官網渠道獲取Xcode 開發工具，致使開發出的多款知名 APP 受到污染，對平臺下用戶隱私的安全造成了巨大的威脅。由

141、此，增強軟件供應鏈上所有干系人的安全意識是至關重要的。最小特權原則和零信任原則本身并不是控制措施，但在復雜和動態環境中，無論是供應商、管理人員、開發人員、測試人員、運營人員、還是終端用戶，都可以為其業務流程提供一個靈活的框架。在人員管理中，根據不同的角色，授予其不同級別資源訪問權限的身份和憑據，在企業組織中，為其所有員工定期進行相關培訓，如幫助開發人員了解編碼過程中的安全設計原則、安全開發標準等；幫助所有企業終端用戶明確企業安全策略，包括有關下載應用程序、使用工作/個人設備、分享數據等的公司策略，以及幫助其了解如何識別網絡釣魚電子郵件、常見的憑據盜竊戰術與當前的攻擊方法（如可疑附件、虛假賬單請

142、求等）等，以提高其安全意識，養成良好的安全習慣。1.最小特權原則最小特權原則是一種信息安全模式。在這種模式中，將僅向訪問者提供在給定時間段內完成工作職能所需的最低級別的訪問權限。此模式還可以應用到執行所需任務時需要訪問權限的應用程序、系統或互聯設備中。強制實施最小權限，僅在需要的時間提供所需的訪問權限，可大大減少攻擊面。2.零信任原則零信任是一種安全模型，基于訪問主體身份、網絡環境、終端狀態等盡可能多的信任要素對所有用戶進行持續驗證和動態授權，旨在通過嚴格的訪問控制框架來保護現代業務基礎架構。在當今如公共云、私有云、SaaS 應用程序等復雜的環境中，訪問路徑越來越多樣化，邊界變得越來越模糊，傳

143、統的基于邊界防御的網絡安全策略已無法應對頻發的現代安全風險，如何授予訪問權限是保護安全的關鍵。零信任的理念十分簡單：組織不得自動信任來自任何通信的任何服務、組件、訪問請求，無論是在網絡邊界的“內部”還是“外部”?；诹阈湃蔚南到y要求嘗試連接的任何人和任何事物都必須先通過認證、身份驗證和授權，然后才可授予訪問權限。4.4 人員管理 59軟件開發生命周期安全風險治理強調安全前置，通過組織管理手段及安全工具，在軟件開發全生命周期的各個階段（需求分析階段、研發測試階段、發布運營階段、停用下線階段）進行安全防護，從源頭提升安全質量，實現開發運營安全閉環，保障軟件應用全生命周期安全。軟件開發安全應從組織文

144、化、安全開發流程、安全技術及工具等多角度、多維度考慮以構建出安全的軟件產品。組織文化上，建設安全文化，加強部門之間溝通，提高安全團隊對基礎設施和工具的可見性，以便安全團隊在分配訪問權限和選擇安全解決方案時作出最佳選擇，同時加強開發人員安全意識，實現人人都為安全負責。安全開發流程上，實現軟件開發、運營的全流程安全覆蓋和安全風險管控，以確保軟件開發全生命周期的安全。軟件安全開發流程的優化促進跨團隊的有效溝通和協作，采用統一的 IT 治理模型和可度量的安全指標，在軟件安全開發流程中實現可跟蹤性、可審計性和可視性，同時進行數據反饋，形成安全閉環，不斷優化流程實踐，以建立更安全的環境。安全技術及工具上，

145、結合組織安全管理工作，對軟件全生命周期的每個階段，即需求分析階段、開發測試階段、發布運營階段和停用下線階段，采取必要的安全考慮及相應的安全防護措施。安全技術和工具方面聚焦于保障和提升軟件的安全技術能力，在軟件開發過程中應盡可能地實現各個階段安全工具自動化，支持 CI/CD 集成，從而實現持續交付的自動化和敏捷化，提升軟件交付速率。4.5 軟件開發生命周期安全風險治理4.5.1 建設全流程安全開發管控4.5.1.1 需求分析階段需求分析階段考慮安全，實現安全左移，安全團隊宣貫安全評估流程，提出安全質量要求，引導輸出安全需求，幫助開發人員提高其安全意識和安全能力，以保障業務安全。主要內容包括：（1

146、）安全需求分析，包括安全合規需求以及安全功能需求；（2）安全設計原則；（3）確定安全標準，規范安全要求，滿足業務機密性、完整性和可用性需求；（4）攻擊面分析，分析系統各個模塊可能會受到的攻擊；（5）威脅建模，確定安全目標、確定威脅列表，進行漏洞儲備；（6）安全隱私需求設計知識庫，構建安全需求知識分享平臺，根據安全需求，得出安全設計解決方案。604.5.1.2 開發測試階段4.5.1.3 發布運營階段為了盡可能避免軟件上線前存在安全風險，需要在開發及測試過程中進行全面的代碼安全審查，主要內容包括：（1）安全編碼，建立安全編碼規范，幫助開發人員避免引入安全漏洞問題；（2）管理開源及第三方組件安全風

147、險，選用第三方組件時評估其風險級別，對第三方組件進行安全檢查，提出解決風險方案；（3）變更管理，對于變更操作進行統一管理；（4）代碼安全審查，制定安全審查方法和審核機制，確定代碼安全審查工具；（5）開源及第三方組件確認，確認第三方組件的安全性、一致性，根據許可證信息考慮法律風險，根據安全漏洞信息考慮安全風險；（6）配置審計，制定配置審計機制，包括配置項與安全需求的一致性，配置項信息的完備性等；（7）安全隱私測試，基于安全隱私需求設計測試用例并進行驗證；（8）漏洞掃描；（9）模糊測試；（10）滲透測試。（1）發布管理，制定相應的安全發布流程與規范，包括對發布操作的權限管控機制，發布流程的監控機制

148、、告警機制等；（2）安全性檢查，進行安全漏洞掃描，以及校驗數字簽名的完整性等；（3）事件響應計劃，制定事件響應計劃，包括安全事件應急響應流程，安全負責人與聯系方式等。運營階段保障軟件產品可以穩定運行。主要內容包括：發布階段確?？梢越桓栋踩能浖a品，主要內容包括：（1）安全監控，制定運營階段安全監控機制，構建統一的安全監控平臺，持續監控并上報；（2）安全運營，定期進行常規安全檢查與改進，如若發現潛在安全風險則應及時告警，根據漏洞信息、業務場景等智能化推薦安全解決方案，保證全生命周期安全；（3）風險評估，制定和實施安全風險評估計劃，定期進行安全測試與評估；（4）應急響應，制定明確的應急事件響應流

149、程，具備專門的應急響應安全團隊，對于應急事件進行全流程跟蹤、可視化展示、自動化處理、及時復盤形成知識庫、量化風險指標；614.5.1.4 停用下線階段4.5.2 構建完善的開發運營安全工具鏈4.5.2.1 軟件成分分析 SCA軟件生命周期是指軟件的產生直到報廢或停止使用的生命周期。由此軟件開發生命周期安全風險治理需要考慮軟件停用下線階段的安全性，實現研發運營安全閉環。軟件停用下線前需提供滿足客戶使用的更新軟件，確?？蛻羰褂眠^程銜接。軟件停用下線后需保護云服務用戶的隱私與數據安全，具體包括制定服務下線方案與計劃，明確隱私保護合規方案，確保數據留存符合最小化原則。安全工具鏈是實現全面安全保障能力的

150、前提條件，是對軟件開發運營的安全賦能，因為在軟件開發流程中嵌入安全工具鏈既可以提升安全運營效率，也能進一步延伸安全管理能力?？紤]到安全開發體系建設工作推動的便利性和效果的顯著性，在對現有安全技術進行了分析和對比后，篩選出了適合進行實踐落地的安全技術，包括但不限于軟件成分分析 SCA 工具、交互式應用安全測試 IAST 工具、運行時自免疫 RASP 工具、容器安全工具、入侵與攻擊模擬 BAS 工具。軟件成分分析 SCA 技術是通過對二進制軟件的組成部分進行識別、分析和追蹤的技術。SCA 的目標是第三方基礎組件/可執行程序/源代碼等類型的以二進制形式存儲的文件，包括但不限于源代碼片段或 Packa

151、ge，可執行的二進制組件/程序，基礎 lib，tar/tgz 壓縮文件，鏡像/鏡像層，廣義的軟件構建過程等等。其中制品掃描是重要的質量關卡，同時也是運營、開發過程重要的安全信息來源，當前絕大部分企業已經建立制品庫，且對制品晉級管理關注度上升，然而僅13.55%的企業將所有交付制品納入制品庫，實現制品晉級管理，且具備完善的開源合規的制品管理。SCA 可以生成完整的 SBOM，SBOM 作為制品成分清單，同時建立軟件構成圖譜，為后續分析提供基礎，即分析開發人員所使用的各種源碼、模塊、框架和庫，以識別和清點開源軟件（OSS）的組件及其構成和依賴關系，并精準識別系統中存在的已知安全漏洞或者潛在的許可證

152、授權問題，把這些安全風險排除在軟件的發布上線之前，也適用于軟件運行中的診斷分析。SCA 允許組織在整個軟件供應鏈中對開源軟件的使用進行安全風險管理，保護最終用戶免受安全漏洞的影響，在保證組織能夠利用開源軟件帶來的優勢的同時，也能保持安全性和合規性。其檢測流程如圖 4-9 所示。（5）升級與變更管理，制定明確的升級與變更操作制度流程、權限管控機制、審批授權機制等，確保升級變更操作有明確的操作信息記錄，與版本系統信息保持一致；（6）服務與技術支持，有明確的服務與技術支持方式，對監管部門、運營商、用戶等提出的問題進行反饋和及時響應，并對反饋問題進行系統性分類整理，確保安全問題的及時響應；（7）運營反

153、饋，定期收集運營過程中的安全問題，通過反饋平臺統一收集、分類、全流程跟蹤、解決、復盤等，以優化研發運營全流程。62隨著開源軟件的日益普及，SCA 的重要性逐年增長。SCA 工具也正在成為應用程序安全的必備工具，SCA 工具可以精準識別應用開發過程中，軟件開發人員有意或違規引用的開源第三方組件，并通過對應用組成進行分析，多維度提取開源組件特征，計算組件指紋信息，深度挖掘組件中潛藏的各類安全漏洞及開源協議風險。同時，SCA 工具還可以對應用程序源代碼、支持庫、所有相關組件以及它們之間的間接和直接依賴項執行掃描，通過代碼掃描可以及早發現漏洞和許可證合規問題并降低修復成本，允許自動掃描以更少的成本發現

154、和修復安全漏洞。通過使用基于多源 SCA 開源應用安全缺陷檢測技術的安全審查工具，在整個軟件供應鏈中對開源軟件的使用進行安全風險管理，為組織提供具有可操作性的洞察力和詳細的補救措施：(1)創建準確的軟件物料清單（SBOM）：SCA 工具生成軟件物料清單（SBOM），其中包括已識別的源代碼，然后針對包括 NVD 在內的多個數據庫進行檢查。SBOM 可幫助安全專業人員和開發人員更好的了解應用程序中使用的組件并深入了解潛在的安全和許可證問題，同時可以快速識別和修復任何關鍵的安全和法律問題。(2)發現并跟蹤所有開源組件:SCA 工具可以幫助組織跟蹤當前運行的程序、源代碼、構建依賴項、子組件等所依賴組件

155、的使用情況，檢測掃描代碼中與知識庫中跟蹤的已知漏洞相對應的任何安全漏洞和依賴項中的安全漏洞。(3)制定和執行相關開源政策：SCA 工具可以制定細粒度的策略來定義和自動執行關于開源軟件組織可接受的安全性和合規性指南，實現快速響應各類安全事件?？梢曅越档?脆弱性提升自研代碼開源軟件第三方軟件商業標準軟件商業定制軟件軟件應用開源項目開源項目開源項目開源組件開源組件開源組件開源組件開源組件開源組件開源組件開源組件開源組件圖 4-9 SCA 檢測范圍 63(4)啟用主動和持續監控：為了更好地管理工作負載并提高生產力，SCA 工具繼續監控安全和漏洞問題，通過持續監控、掃描和來自強大漏洞數據庫的最新 CVE

156、 知識，實現更深入的洞察。同時對關鍵警報進行優先級排序和自動修復，以幫助開發人員在不中斷工作流程的情況下快速解決問題。(5)無縫集成到構建環境中：在 DevOps 環境中集成操作系統安全和許可證掃描，以便掃描代碼并識別構建環境中的依賴性。4.5.2.2 交互式應用安全測試 IAST交互式應用安全測試 IAST 技術是近幾年較為火熱的一項應用安全測試新技術。IAST 最顯著的特征就是通過運行時部署插樁 Agent 來收集安全信息，當外部掃描器發起掃描測試觸發這個 Agent 時，IAST 便持續監測應用程序中的流量信息，一旦檢測到漏洞，便實時提供報警并進行漏洞定位，被 Gartner 列為網絡安

157、全領域的 TOP 10 技術之一。IAST 技術實現原理主要包括以下幾種技術：(1）主動插樁技術主動插樁技術需要在被測試應用程序中部署插樁探針，使用時需要外部掃描器去觸發這個 Agent。一個組件產生惡意攻擊流量，另一個組件在被測應用程序中監測應用程序的反應，由此來進行漏洞定位和降低誤報，其主動插樁技術原理如下圖所示。DAST掃描器IAST插樁服務器服務端安全測試測試結果測試結果圖 4-10 IAST 主動插樁技術原理 641)被測試服務器中安裝 IAST 插樁探針；2)DAST Scanner 主動發起掃描測試；3)IAST 插樁探針追蹤被測試應用程序在掃描期間的反應，并動態分析測試覆蓋率和

158、上下文。當定位到具體漏洞信息時，將有關信息發送給管理控制臺，控制臺展示安全測試結果。主動插樁技術結合了 DAST 的部分能力，需要在被測試應用程序中部署插樁探針進而在底層函數 Hook 點實時監聽，并借助外部掃描器主動構造重放 Payload 數據來觸發這個探針。其中，在整套主動插樁系統中，一個組件主動產生定向攻擊重放流量，另一個組件在被測應用程序中監測應用程序的反應，由此來進行精準漏洞定位。(2）被動插樁技術1）被測試服務器中安裝 IAST 插樁探針；2）插樁探針在應用程序運行時獲取請求和代碼數據流、代碼控制流，進行動態污點追蹤；3）當定位到具體漏洞信息，插樁探針將獲取的信息發送給管理控制臺

159、，控制臺展示應用安全測試結果。被動插樁技術在程序運行時監視應用并分析代碼，它不會主動對 Web 應用程序執行攻擊，而是純粹被動地分析檢測代碼。因此，這是一個巨大的技術優勢，它將不會影響同時運行的其他測試活動，并且只需要業務測試(手動或自動）來觸發安全測試，有正常測試流量過來就可以實時的進行漏洞檢測，其被動插樁技術原理如圖 4-11 所示。(3）終端流量代理技術1）功能測試人員在瀏覽器或者 APP 中設置代理，將 IAST 檢測平臺地址填入；2）功能測試人員開始功能測試，測試流量經過 IAST 檢測平臺，IAST 檢測平臺將流量復制一份，并且改造成安全測試的流量；3）IAST 檢測平臺利用改造后

160、的流量對被測業務發起安全測試，根據返回的數據包判斷漏洞信息。運行時插樁技術需要在服務器中部署 Agent，如圖 4-12 所示，不同的語言不同的容器需要適配不同的 Agent，這對某些用戶或一些用戶的某些場景來說是難以接受的。而流量代理技術不需要服務器中部署 Agent，如圖 4-13圖 4-11 IAST 被動插樁技術原理開發/測試人員IAST插樁服務器IAST服務端開發/驗證測試測試結果測試結果 65所示，只需測試或使用人員簡單配置代理即可，且能檢測業務邏輯漏洞。該技術局限的地方在于安全測試會產生一定的臟數據，漏洞的詳情無法定位到代碼片段。當用戶的某些業務場景無法部署插樁 Agent 時，

161、流量代理和流量鏡像技術是一個很好的補充。圖 4-12 運行時插樁模式圖 4-13 流量代理模式DAST掃描器測試服務器安裝IAST代理管理服務器安全測試審查漏洞結果漏洞結果瀏覽器APP代理流量處理中心復制 流量安全 測試檢測模塊業務請求業務請求正常請求漏洞信息轉發流量業務Websrv4.5.2.3 RASP 運行時自免疫隨著針對應用程序的黑客攻擊威脅的不斷發展以及“HW”行動的興起，僅靠 Web 應用程序防火墻（WAF）已不再是抵御威脅的有效方法。傳統 WAF 通過在網絡流量到達應用程序服務器之間對其進行分析，完全獨立于 66圖 4-14 Java 代碼中實現 RASP 注入防護隨著針對應用程

162、序的黑客攻擊威脅的不斷發展以及“HW”行動的興起，僅靠 Web 應用程序防火墻（WAF）已不再是抵御威脅的有效方法。傳統 WAF 通過在網絡流量到達應用程序服務器之間對其進行分析，完全獨立于應用程序進行工作。在門外處理的方式，使其無法真正核實請求的合法性，難以保證其準確性，因此管理員只能使其處于“日志模式”。為了更好地預防針對應用程序的攻擊威脅以及應對“HW”等超大流量超大規模的實戰驗證，RASP（Runtime application self-protection，運行時應用自我保護）作為 Gartner 提出的一種新型 Web 防護手段，將保護代碼注入到應用程序中，與應用程序融為一體，使

163、應用程序具備自我保護能力，通過分析應用程序行為和上下文，對訪問應用系統的每一段代碼進行檢測，保護實時運行的應用程序。通過使用該應用程序持續監控其自身行為，當應用程序遭受到實際攻擊和傷害時，RASP 可以實時檢測和阻斷安全攻擊，無需人工干涉。市面上絕大多數 Java 版 RASP 技術都是在運行時階段字節碼加載前進行插樁，其優點是無需對源代碼進行修改真正做到對應用程序的無侵入。其實現原理：Java 源程序在運行時需要通過編譯器編譯成為.class 文件，即字節碼文件。Java 的跨平臺特性是 Java 字節碼文件可以直接在 JVM（Java 虛擬機）運行，而 JVM 提供的Java Agent

164、參數可以使得在字節碼加載前修改字節碼，完成 RASP Agent 的注入，當應用程序受到攻擊時，就會觸發 HOOK 函數，此時 RASP Agent 就可以獲取到函數參數，實現對 Java 運行程序的檢測。面對應用現代化，安全防護需要“左移”，推動安全戰略實現從“傳統基于邊界防護的安全”向“面向應用現代化的內生安全”模式轉變。RASP 作為降低應用風險的一項關鍵創新技術，彌補了傳統邊界安全防護產品的先天性防護不足，可應對無處不在的應用漏洞與網絡威脅，為應用程序提供全生命周期的動態防護和內生主動安全免疫能力，其必將加快企業數字化轉型，推動軟件供應鏈的創新發展。myAPP.javamyAPP.cl

165、ass被Hook方法插樁代碼JAM 674.5.2.4 容器安全工具4.5.2.5 入侵與攻擊模擬技術 BAS隨著云原生時代的到來，容器作為云原生的代表技術，簡化了應用程序或服務及其所有依賴項的構建、封裝和推進，為重要的應用程序和工作負載提供了靈活性和隔離，幫助開發人員實現了高效部署，然而容器的靈活性和實用性也帶來了一定的安全風險。由于容器的相對不透明性，使得很難識別安全風險以及容器交替運行時的不斷變化，也使得在 Kubernetes 階段進行掃描時檢測當前未使用的鏡像或容器更具挑戰性，因此在開發的早期階段確保容器安全至關重要。容器安全軟件和工具在開發和運行時環境中為容器中的所有資源提供持續性

166、保護，自動執行漏洞掃描，并通知開發人員和 IT 團隊容器環境中可能存在的威脅。容器安全軟件和工具不僅要保護承載容器的宿主機的安全、容器軟件自身的安全、容器鏡像安全、容器集群安全，同時還要監視生成管道的完整性以及容器內應用程序的基礎設施層。圖 4-15 為某容器安全工具架構。傳統的安全威脅檢測一般會利用漏洞掃描、滲透測試以及紅藍對抗等方法進行定期測試。然而，這些方法都有一定的局限性。如漏洞掃描報告通常只列出發現的漏洞，并且還可能產生誤報并標記某些可能對安全性影響不大的問題。滲透測試和紅藍對抗是資源密集型活動，對安全專業人員的要求較高，且成本相對也比較大。時至今日，越來越多的企業開始采用入侵和攻擊

167、模擬 BAS 工具進行安全測試，以更高效的方式實現業務安全。2020 年 Gartner 在預測分析：全球容器管理（軟件和服務）報告中預測到，到 2024 年，所有應用中將有15%的應用運行在容器中，遠高于目前的 5；此外，將有 75的大型企業會在生產中使用容器技術，而目前這一比例還不到 35。在開發和部署階段實現容器化的企業比例正在不斷增加，但容器安全性已經落后，雖然有幾種安全技術可以幫助企業改善其安全狀況，但許多組織都沒有全面的容器安全策略，企業在應用云原生技術時，應整體考慮容器安全，讓安全與云原生相融合，以更好的保護應用系統。API ServerpodKubernetes WorkerK

168、ubernetes MasterKubernetes Workerpod防御容器防御容器KubeletKube-proxyFluentdpodpodpodpodDockerKubeletKube-proxyFluentdDockeretcd安全調度中心pod安全管理中心SchedulerController圖 4-15 某容器安全工具架構 68漏洞、缺陷等安全威脅并不能避免，且一直處于增長比較迅速的態勢。在 DevOps 效率提升的前提下，如何保證安全也是防守者面臨的重要課題。BAS 相對傳統安全檢測手段，具有獨特優勢，可以更好的保護業務系統安全運行，對企業來講毋庸置疑是較好的選擇。與傳統安全

169、驗證方式相比，入侵和模擬攻擊 BAS 具有以下幾個優勢：BAS 允許防御者采用攻擊者的思維方式進行主動防御，而不是被動地等待掃描結果或發布補丁。除了提高效率和降低成本之外，BAS 規避了人的因素，避免因人或團隊不同帶來不同的測試結果。BAS 模擬了一個完整的攻擊，沿著網絡殺傷鏈，以自動和連續的方式模擬大量的攻擊，以查看它們是否預防和/或檢測安全威脅，有效驗證了安全措施。例如，BAS 會檢查發起的攻擊是否通過防火墻、IPS 甚至反病毒程序到達目標，而不是檢查目標應用程序中是否存在給定的漏洞。BAS 可以進行持續測試，自動探測隱藏的安全漏洞，及時捕捉到新發現的安全漏洞。加速了 DevOps 中持續

170、部署和持續交付的速度。CI/CD 管道是一組流程，需要遵循這些流程才能成功地將應用程序的一組軟件功能可靠且頻繁地交付給不同的云環境，例如開發、QA 和生產。這些流程集的有效自動化（在軟件工具的幫助下）將決定 CI/CD 管道的功效。CI 自動化涉及軟件開發過程的每個單元，如設計、代碼、構建和測試，并集成每個功能所需的適當軟件插件，以便無縫執行。使用 BAS 可以縮短交付周期，讓業務更安全的快速上線運行。69結合實際情況，企業在構建好軟件供應鏈治理體系后，可以借助軟件安全成熟度模型對其體系進行成熟度評估。軟件安全成熟度模型作為一類基于規范或描述的模型，在一定程度上也可以度量企業構建的軟件供應鏈安

171、全治理體系成熟與否，起到了一定的指導性或輔助性作用。4.6 軟件安全成熟度模型4.6.1 可信研發運營安全能力成熟度模型隨著軟件供應鏈安全風險加劇，實現主動式安全防御，構建覆蓋軟件應用服務全生命周期的安全體系框架勢在必行。在此背景下，中國信通院牽頭制定可信研發運營安全能力成熟度模型標準，強調安全左移，規范企業研發運營全生命周期安全體系，從源頭提升軟件質量，加固應用安全?？尚叛邪l運營安全能力成熟度模型行業標準規定了面向云計算的可信研發運營安全能力成熟度模型參考框架，分為管理制度以及涉及軟件應用服務全生命周期的要求階段、安全需求分析階段、設計階段、研發階段、驗證階段、發布階段、運營階段和下線階段九

172、大部分，每個部分提取了關鍵安全要素，規范了企業研發運營安全能力的成熟度水平，自低向高依次分為基礎級、增強級和先進級。該標準適用于企業在落地實踐研發運營安全時進行參考與評價，也可為第三方機構對于企業的研發運營安全能力審查和評估提供標準依據，如下圖所示。管理制度組織架構制度流程安全培訓第三方管理設定安全門限要求項目角色及權限管理開源及依賴組件管理配置審計環境管理變更管理安全審計配置管理安全研發要求要求階段安全需求分析階段設計階段開發階段發布階段安全需求分析開源及以來組件確認漏洞掃描應急響應安全運營風險評估運營反饋模糊測試滲透測試安全測試發布管理安全監控與防護服務下線方案與計劃數據留存最小化原則升級

173、與變更管理服務與技術支持安全性檢查事件響應計劃安全設計原則安全編碼代碼安全審查管理開源及依賴組件安全風險受攻擊面分析威脅建模風險消減設計安全需求知識庫驗證階段運營階段停用下線階段圖 4-16 可信研發運營安全能力成熟度模型 70數字化時代，隨著企業 IT 基礎架構云化及外部網絡威脅環境持續惡化，原有的平衡正在被打破，云安全越來越受到企業重視。作為我國云計算安全信任體系的權威評估，可信云以完整的衡量標準和評估體系，為云安全的發展提供有力規范。中國信通院依據可信研發運營安全能力成熟度模型標準，于 2021 下半年開展了首批面向供應鏈研發運營安全能力的試點評估。4.6.2 研發運營一體化（DevOp

174、s）能力成熟度模型研發運營一體化（DevOps）能力成熟度模型是中國信息通信研究院牽頭組織的全球首個 DevOps 標準。DevOps 標準體系旨在幫助組織：（1）明確概念、框架、能力。DevOps 的概念、框架和能力到達什么程度，做一個非常詳細明確的說明。（2）對于 DevOps 涵蓋的流程、組織、實施，有明確的指引，企業可以按照這個標準去提升自己 DevOps 各個環節的能力。DevOps 標準評估體系主要包括敏捷開發管理、持續交付、技術運營、應用設計、安全及風險管理、系統和工具等部分，如下圖所示。其中，安全管理在 DevOps 標準體系中至關重要，因為 DevOps 在一定程度上降低了安

175、全性，也是很多企業落地 DevOps 遇到的最大阻力之一。相比于傳統開發模型，該部分明確規定了 IT 軟件或相關服務在采用 DevOps開發模式下，將安全融入每個階段過程，使得開發、安全、運營各部門可以更好地緊密合作。安全管理分為四個板塊，包括：控制通用風險、控制開發過程風險、控制交付過程風險、控制運營過程風險，如圖 4-18 所示。圖 4-17 研發運營一體化（DevOps）能力成熟度模型一、研發運營一體化（DevOps)過程二、研發運營一體化（DevOps)安全架構三、研發運營一體化（DevOps)安全管理四、研發運營一體化（DevOps)組織結構敏捷開發管理持續交付技術運營需求管理 計劃

176、管理 過程管理需求收集需求澄清和拆解迭代管理需求分析故事與任務排期迭代活動需求與用例 計劃變更過程可視化及流動需求驗收度量分析配置管理構建與持續集成測試管理部署與發布管理 環境管理數據管理度量與反饋版本控制構建實踐測試分級策略部署與發布模式環境供給方式測試數據管理度量指標版本可追蹤性持續集成代碼質量管理持續部署流水線環境一致性數據變更管理度量驅動改進測試自動化監控服務數據服務容量服務連續性服務運營反饋應用監控監控平臺運營服務管理數據收集能力容量規劃能力高可用規劃業務知識管理質量體系管理數據處理能力容量平臺服務質量體系管理項目管理 事件響應及處置數據告警能力運營成本管理業務連續性管理 71安全及

177、風險管理組織建設和人員管理安全工具鏈 基礎設施管理第三方管理 數據管理 度量與反饋改進 需求管理 設計管理 開發過程管理 配置管理 構建管理 測試管理 部署與發布管理 監控管理 運營安全 應急響應 運營反饋控制通用風險控制開發過程風險控制交付過程風險控制運營過程風險圖 4-18 安全及風險管理分級技術要求其中，在安全管理中：（1）控制通用風險，在 DevOps 模式下，安全內建于開發、交付和運營過程中，其中通用風險覆蓋三個過程中的共性安全要求，包括：組織建設和人員管理、安全工具鏈、基礎設施管理、第三方管理、數據管理、度量與反饋改進；（2）控制開發過程風險，從應用的開發過程開始實施安全風險管理工

178、作，可以保障進入交付過程的代碼是安全的，降低后續交付、運營中的安全風險，保障研發運營一體化的整體安全，包括：需求管理、設計管理和開發過程管理；（3）控制交付過程風險，交付過程是指從代碼提交到應用發布給用戶使用，那么安全交付則是將安全嵌入到交付過程中，包括：配置管理、構建管理、測試管理、部署與發布管理；（4）控制運營過程風險，技術運營過程是指應用發布給用戶后的過程，將安全嵌入于運營過程中，通過監控、運營、響應、反饋等實現技術運營的安全風險閉環管理，包括：安全監控、運營安全、應急響應、運營反饋。綜上所述，安全管理更加側重考慮全流程端到端的全局安全管理及服務，包括人員的管理、工具、代碼和第三方合作的

179、安全，涵蓋了開發過程、交付過程以及技術運營過程中的風險等，貫穿 DevOps 能力成熟度模型的整體過程，旨在安全風險可控的前提下，幫助企業有效提升 IT 效能，更快速且更準確地實現研發運營一體化。4.6.3 BSIMMBSIMM（Building Security In Maturity Model，軟件安全構建成熟度模型）是一個基于軟件安全框架（SSF），由十二個安全實踐組成并針對多個軟件公司的軟件安全項目進行研究的模型，該模型對不同軟件安全項目所采取的措施和實踐進行量化，描述其共性和各自的特點。72圖 4-19 BSIMM12 的框架BSIMM 研究始于 2008 年，出版了 BISMM

180、1，當時對來自軟件廠商、技術公司和金融服務業界的 9 個頂尖軟件安全項目進行了數據收集和分析，隨著近年來的快速發展，BSIMM 已經逐漸覆蓋了軟件構建的整個過程。2021 年 BSIMM12 發布，旨在幫助企業規劃、執行、評估和完善其軟件安全計劃。BSIMM12 報告中提出了新的趨勢：（1）影響廣泛的勒索軟件和軟件供應鏈中斷促使人們更加關注軟件安全；（2）企業開始學習如何將風險轉化為數據；（3）增強的云安全功能；（4）安全團隊正在借調資源、人員和知識用于 DevSecOps 活動；（5）從“左移”變成“無處不移”的趨勢；（6）軟件物料清單活動增加了 367%。當前最新的BSIMM 12的SSF

181、共有4個領域，分別為管理、情報、SSDL觸點和部署，每個領域又各分為三項實踐，共形成 12 項安全實踐模塊，如下圖所示。區域管理情報SSDL觸點部署用于協助組織、管理和評估軟件安全計劃的實踐。人員培養也是一項核心的管理實踐。用于在企業中匯集企業知識以及開展軟件安全活動的實踐。所匯集的這些知識既包括前瞻性的安全指導，也包括組織機構威脅建模。與分析和保障特定軟件開發工件（artifacts)及開發流程相關的實踐。所有的軟件安全方法論都包含這些實踐。與傳統的網絡安全及軟件維護組織機構打交道的實踐。挼按鍵配置、維護和其他環境問題對軟件安全有直接影響。實踐管理情報SSDL觸點部署1.戰略和指標 (SM)

182、2.合規與政策 (CP)3.培訓 (T)4.攻擊模型 (AM)5.安全功能和設計 (SFD)6.標準和要求 (SR)7.架構分析 (AA)8.代碼審查 (CR)9.安全性測試 (ST)10.滲透測試 (AA)11.軟件環境 (CR)12.配置管理和安全漏洞管理 (CMVM)軟件物料清單 SBOM05軟件供應鏈安全始于對關鍵環節的可見性，SBOM 做為軟件供應鏈治理的核心技術之一，可以包含應用程序的多種關鍵信息，通過這些信息可以追溯軟件的原始供應鏈，極大提高開發人員對軟件安全風險的理解，幫助企業在網絡安全風險分析、漏洞管理和應急響應過程中提高效率，在軟件供應鏈安全治理中起到了重要作用。74SBO

183、M（Software Bill of Material，軟件物料清單）的概念源自制造業，其中物料清單 BOM 是用來詳細說明產品中包含的所有項目的清單。例如在汽車行業，制造商為每輛車提供一份詳細的物料清單，列出原始設備制造商制造的部件以及來自第三方供應商的部件。當發現有缺陷的部件時，汽車制造商可以準確地知道哪些車輛受到影響，進而通知車主維修或更換。如今，絕大部分應用程序都是組裝而成而非從零開始構建。通常軟件供應商并不了解其產品具體使用了哪些開源軟件，也無法確定產品是否使用了不安全或存在漏洞的軟件組件，因此供應商無法在開發階段及時規避這些風險，從而導致軟件發布后產生的安全風險較大與修補成本較高。

184、此外，當有漏洞被揭露時，很少有企業可以快速、準確地定位并響應一些關鍵性問題，例如，產品是否受到該漏洞的影響，該漏洞影響了哪些產品線，哪些軟件的版本是否存在這些問題等。實際上這一情況的根源在于未管理產品的軟件組成所造成的，從而大幅增加了開發、采購、維護與處理的成本。由此，企業需要維護準確、最新的 SBOM，以確保其代碼質量高、合規且安全。2021 年發生的幾起包括 Codecov、Kaseya 和 Apache Log4j 等備受矚目的軟件供應鏈攻擊事件，促使美國總統拜登發布了一項網絡安全行政命令（EO），其中明確提出要增強美國聯邦政府的軟件供應鏈安全，要求向美國聯邦政府出售軟件的任何企業，不僅

185、要提供軟件本身，還必須提供軟件物料清單（SBOM），以明確該軟件的組成成分，提高軟件供應鏈透明度，確保聯邦政府使用的軟件應用程序的安全性和完整性。5.1 SBOM 的重要性 75美國國家電信和信息管理局（NTIA）發布的構建軟件組件透明度：建立通用軟件物料清單（SBOM）第二版中提出，SBOM 是一個包含軟件組件列表和層次依賴信息且機器可讀的規范性清單。這些清單應當是全面的，或者應當明確說明不全面之處。SBOM 可能包括開源軟件或專有軟件，它可以是公開可見或設置限制訪問，SBOM 還應能夠識別并列出軟件組件、提供這些組件的相關信息以及它們之間的供應鏈關系。但特定 SBOM 中所包含的組件信息的

186、數量和類型可能會根據行業或部門以及 SBOM 消費者需求等因素而有所不同。對于這一情況，關鍵是要形成一個基線 SBOM 的最低預期，只要求該基線包含可以支持基本組件及其特性所需的最少信息量和流程。在最低基線 SBOM 的基礎上，隨著各部門進一步完善和實踐日益成熟，SBOM 可以逐步融入到各部門的開發流程中，成為企業與生俱來的 DNA 的一部分。通用 SBOM 屬性主要包括基線屬性集、未確定的屬性值、映射到現有的格式、組件關系以及附加元素，如圖 5-1所示。建立通用 SBOM 有助于我國軟件安全領域實現 SBOM 標準統一化，進一步加快修復漏洞的速度，提升安全漏洞修復能力。1.基線屬性集SBOM

187、 的基線屬性集包括：1)作者姓名：指SBOM的作者，SBOM的作者并不總是供應商，也就是說除了供應商，SBOM還可以由作者創建；2)時間戳：指上次更新 SBOM 的日期和時間；3)供應商名稱：指 SBOM 條目中組件供應商的名稱或其他標識符；4)組件名稱：指組件的名稱或其他標識符。組件名稱應該具備處理多個名稱或別名的功能；5.2 建立通用的 SBOM作者姓名時間戳 供應商名稱組件名稱版本字符串組件哈希值唯一標識符關系 基線屬性集對于未確定的屬性 需明確確定義區分無斷言（即數據缺 失）沒有值（即該屬性 不適用于此特定的 SBOM）未確定的屬性值包含包含于 組件關系除了基線屬性外，SBOM可能還需

188、要 額外的元素和組件 屬性以支持不同的 用例。附加元素基線屬性信息映 射到SPDX、Cyclo neDX和SWID等現 有格式映射到現有的格式圖 5-1 通用 SBOM 屬性 765)版本字符串：指組件的版本，版本信息有助于進一步識別組件；6)組件哈希值：指組件的加密哈希值；7)唯一標識符：指幫助唯一標識組件的附加信息。唯一標識符可以通過與全局唯一層次結構或命名空間對比或參考已有的全局坐標系來生成。一些可用作唯一標識符的系統包括通用平臺枚舉（CPE）、包 URL（PURL）、通用唯一標識符（UUID）（也稱為全局唯一標識符 GUID）、軟件遺產 ID（SWHID）和組件哈希值等都可以作為有效的

189、唯一標識符；8)關系：指SBOM組件之間的關聯。組件關系是SBOM模型設計中固有的組成部分，關系類型有包含（includes）和包含于（include in），只要選定并貫徹一個方向，方向的選擇不會影響使用 SBOM 模型。2.未確定的屬性值在某些情況下，某些屬性可能不可用、沒有意義，或對組件識別沒有實質性貢獻，其中一個重要原因是缺乏組件組成的第一手知識。當 SBOM 作者不是軟件組件的供應商時，作者可能會缺乏生成某些屬性所需的信息。另一個原因在于創建 SBOM（和組件）的時間點，大致為：預構建、構建或打包時以及構建后。例如，由（非供應商）作者在構建后執行的二進制軟件組成分析可能會檢測到組件，

190、但不會提取二進制組件以生成哈希值。SBOM 必須恰當地處理缺失或不適用屬性的情況。為此 NTIA 提出了一個小建議：總是提供所有的基線屬性，但需明確定義區分“無斷言（no assertation）”(即數據缺失)和“沒有值（no value）”(即該屬性不適用于此特定的 SBOM)?；蛘?，SBOM 格式可以允許缺少基線屬性，并將缺失某幾項屬性視為默認值（例如“無斷言”或“沒有值”）。3.映射到現有的格式SBOM 生成方式可以分為手動生成或使用自動化技術生成。手動生成方法可能適合較小的項目，通過表格或文件等形式手動列出所有軟件組件，以及每個組件的版本、許可證、依賴項和任何其他相關信息，但為具有上

191、千個直接和傳遞依賴項的項目手動生成 SBOM 清單是不現實的，且手動方法也容易出現人為錯誤，更新依賴項也容易忘記更新 SBOM 清單。而自動化技術則是將生成 SBOM 的自動化工具整合到持續集成和持續交付(CI/CD)管道中，以掃描所有軟件項目，列出專有和開源軟件組件以及相關屬性，例如許可證和對第三方庫的依賴關系，并根據需要更新其相關組件。SPDX、CycloneDX 和 SWID 等 SBOM 標準的使用也幫助 SBOM 實現了其自動化支持，SPDX 是一個由 Linux基金會運營的項目，旨在標準化組織共享和使用軟件物料清單中的信息的方式，SPDX 主要捕獲與來源、許可CycloneDX 是

192、一種輕量級的 SBOM 標準，設計用于應用安全環境和供應鏈組件分析。SWID 是一種標準化的XML 格式，用于標識軟件產品的組件并將其上下文化。如表 1(來自現有 SBOM 格式調查表 1)所示，映射了 SPDX、CycloneDX 和 SWID 中的基線屬性。77(4)組件關系開發 SBOM 的第一步是列舉供應商直接列入主要組件中的一級組件。然而，為了有效推廣 SBOM，SBOM 還需要捕獲組件之間已知的嵌套供應鏈關系。物理組件的物料清單通常將這些關系描述為“多級 BOM”。雖然屬性SPDXCycloneDXSWID作者姓名(2.8)Creator:metadata/authors/auth

193、or role(tagCreator),name時間戳(2.9)Created:metadata/timestamp供應商名稱(3.5)PackageSupplier:Supplier publisher role(softwareCreator/publisher),name組件名稱(3.1)PackageName:namename版本字符串(3.3)PackageVersion:version version組件哈希值(3.10)PackageChecksum:(3.9)PackageVerificationCode:Hash“alg”/./hash-algorithm:hash唯一標識符

194、(2.5)SPDX Document Namespace(3.2)SPDXID:bom/serialNumber component/bomreftagID關系(7.1)Relationship:DESCRIBESCONTAINS(Inherent in nestedassembly/subassembly and/or dependency graphs)rel,href表 5-1 將基線組件信息映射到現有格式 78SBOM 可能會支持多種類型的關系，但在“基線屬性集”中描述的基線關系屬性定義了一種單一類型的關系：包含（或包含于），上游組件（通常稱為依賴項）包含在下游組件或組件中。其他類型的

195、關系可能是必要的或是有用的，而現有的 SBOM 格式支持不同類型的關系。由此可以進一步細化“包含于”關系，例如明確下列三種情況的差異：直接包含（未修改的）一個上游二進制組件；通過鏈接或編譯包含（未修改的）一個上游源代碼組件；選擇一個上游的源代碼組件，對其進行修改（新建分支），然后通過鏈接或編譯將其包含在內。修改一個組件會創建一個新組件(例如，一個分支)，修改者會成為該新組件的供應商。重要的是保留修改組件的修改信息并傳遞其修改記錄。例如，SPDX 支持 GENERATED_FROM 和 DESCENDANT_OF 關系類型。雖然上游組件的信息通常是 SBOM 功能的一部分，但不使用組件的某些部分

196、的情況也很常見。軟件程序（組件）可能包含一個庫（組件），但只調用庫提供的一些函數?；蛘?，組件的某些特性可能會在構建或打包期間被禁用。這在一些 SBOM 用例中很重要，特別是在漏洞管理用例中。如果一個漏洞影響到上游組件，則該漏洞可能會影響也可能不會影響下游組件。漏洞可利用性交換(VEX)旨在傳達組件中漏洞的狀態。(5)附加元素除了基線屬性外，SBOM 可能還需要附加元素和組件屬性以支持不同的用例。并不是所有附加的元素或屬性都支持每個用例，所需的具體信息取決于用例的具體情況，包括但不限于：組件的使用壽命結束日期或技術支持結束日期；體現組件實施或支持技術能力的信息；對組件進行分組的機制，可能是通過生

197、產線或已實現的技術進行分組。79在成熟的體系下，SBOM 的生成可以通過軟件生命周期每個階段所使用的工具和任務流程化地完成，這些工具和任務包括知識產權審計、采購管理、許可證管理、代碼掃描、版本控制系統、編譯器、構建工具、CI/CD 工具、包管理器和版本庫管理工具等，如圖 5-2 所示。SBOM 中應該包含軟件組件與此組件所依賴的任何其他基礎軟件組件之間的關系。軟件產品在發布任何版本時，SBOM 都應作為產品文檔的一部分被提供，在 CI/CD 的標準實踐中，SBOM 中包含的信息將不斷更新。它從在需求中集成安全性需求開始，或者是 SBOM 中的一些元素已經在需求階段被添加到用例中，這樣安全性和S

198、BOM 就可以成為 DevOps 過程中標準和結構化的一部分。軟件開發階段的不同，SBOM 的生成方法也是不同的，主要以軟件構建為階段劃分，分為三個階段：軟件構建前、軟件構建時和軟件構建后。軟件構建前，SBOM 主要作為版本控制系統一部分，或由挖掘產品構建管道輸入的工具創建源碼級 SBOM，該階段的生成的 SBOM 有助于關鍵組件的識別及在創建產品之前查找漏洞，也便于從構建到成為源文件的整個過程的追溯跟蹤，但構建前的 SBOM 可能會有易受到攻擊的源代碼，只是它們并不會包含在最終可執行文件中。軟件構建中，SBOM 生成方法有三種：5.3 SBOM 的生成規格+風險配置+實例+分布式軟件+插件+

199、代碼+資質第3方的SBOM+可執行程序+helloworld.pkgpackager+BoMHelloVendorHelloWorld 1.0BSD-1-clauseSPDX-123456SBOM生產流程編碼說明階段性材料組件軟件制造商+用戶構建測試計劃發布部署運營監控用戶軟件制造商設計、規格SCA、VCS、SCM編譯器、構建工具資格證明分配CDN持續部署配置管理威脅情報圖 5-2 SBOM 的生成流程 801）作為構建制品自動化生成 SBOM，生成的 SBOM 通常不會出現人工輸入錯誤，而且會包含更具權威性的軟件組件特征，實現 SBOM 的簽名自動化，這也為供應商和下游消費者提供了更多的可審

200、計性。但該方法中SBOM 供應商必須確定構建過程中將生成的 SBOM 格式，如 SPDX、CycloneDX 和 SWID 等。2）在構建管道中通過構建插件生成 SBOM，這些插件與底層構建和依賴關系管理系統集成，生成一種支持的SBOM 格式。這種方法很簡單，但可能需要額外資源來集成所有構建管道。3）從容器化過程中導出容器鏡像 SBOM，隨著越來越多的軟件以容器鏡像的形式交付，例如 Docker/Open Container Initiative(OCI)格式，但值得注意的是容器鏡像有分層的概念，每層可能都會包含各種軟件應用程序，包括操作系統(OS)、操作系統包、應用程序及其關聯庫，還有其他可

201、能已集成到各層的制品。SBOM 描述容器鏡像時，應該會匯總并標識來自所有層的所有軟件。軟件構建后，并非所有交付軟件的SBOM都能在構建時生成。許多軟件功能，尤其是在老舊系統中使用的功能，一開始并不是用目前軟件版本控制或者持續集成的方法開發的，構建后的 SBOM 可能是來自各種不同供應商、過程以及工具的 SBOM 集合。此類生成的 SBOM 應盡可能補充接近工程過程的組件數據、已知的未知情況等。通常情況下，一般應用 SCA 工具可掃描上游供應商組件以及構建后的 SBOM。81如今，SBOM 已成為安全業界公認的遏制軟件供應鏈風險的最佳方案之一，實施 SBOM 有助于揭示整個軟件供應鏈中的漏洞與弱

202、點，提高軟件供應鏈的透明度，減輕軟件供應鏈攻擊的威脅，驅動軟件供應鏈的安全。通過使用SBOM可以幫助企業進行漏洞管理、應急響應、資產管理、許可證和授權管理、知識產權管理、合規性管理、基線建立和配置管理等，如圖 5-3 所示。SBOM 作為獨立的實體，并非是所有安全問題的解決方案。但 SBOM 有助于獲得做出正確選擇的信息，是團隊做出智慧安全決策的信息來源。(1)對于開發和運營團隊來說，在軟件開發過程中，開發人員可以使用 SBOM 監視和修復不同組件中存在的軟件漏洞。例如，開發團隊可能會收到有關 Ramda 漏洞的警報，了解這一點后，開發人員可以使用 SBOM 查找使用 Ramda 庫的每個軟件

203、，并立即修補問題。同時，通過使用 SBOM，開發人員能夠創建和實施允許列表和拒絕列表，從而能夠更好地控制哪些組件和版本可在軟件中使用，哪些組件和版本是被禁止的。在軟件交付運營過程中，運營團隊如果收到安全風險預警，并及時通知開發人員時，開發人員利用 SBOM 能夠追蹤溯源，發現存在漏洞的組件，及時進行漏洞修復或組件的替換等工作。(2)對于軟件供應商來說，構建 SBOM 提升了軟件供應鏈透明度，可以幫助企業組織全面洞察每個應用軟件5.4 SBOM 的優勢圖 5-3 SBOM 的作用 82的組件情況，從而更高效的定位并響應漏洞問題。同時，支持提供 SBOM 可以幫助供應商在競爭時，利用SBOM 作為

204、差異化因素，從而在市場中脫穎而出。(3)對于采購方來說，通過 SBOM 可以清晰直觀地看到其感興趣的產品信息，例如基線組件信息或許可信息等，也可以通過 SBOM 了解承包商/供應商管理系統、第三方風險的合規管理及報告等。(4)對于運營商來說，SBOM 增加了軟件及其組件的可見性，有助于他們在其生產業務之前驗證軟件的狀態。SBOM 的出現為保護軟件供應鏈奠定了重要基礎，成為軟件供應鏈的有利抓手，通過提供一組附加信息把軟件組成成分和依賴關系以及作者等信息可視化并統一記錄管理，大大提升了軟件供應鏈整體透明度，對于降低軟件使用和維護成本，保障軟件供應鏈安全具有重要意義。當下，我們正在見證 SBOM 被

205、認可和發揮作用的過程，未來，在 SBOM 逐漸實現標準化、服務產業化、生成功能集成化、生態化下，將會有越來越多的組織機構采用 SBOM 方法以滿足行業內的更多需求。83開源威脅治理06Perforce 的 Open Source Initiative(OSI)和 OpenLogic 聯手開展了一項關于開源軟件狀態的全球調查，數據顯示，在過去 12 個月中，77%的受訪者在其組織中增加了對開源軟件的使用，36.5%的受訪者表示他們的使用量顯著增加。也有數據顯示，有 90%的組織都依賴于開源軟件，而且開源軟件也經常被嵌入到其他開源項目中。但是，盡管開源為企業的創新和快速發展提供了源動力，但與之而來

206、的還有安全風險問題，為攻擊者提供了潛在的安全威脅入口點。這一點在 3.2 小節為大家進行了概述。在軟件供應鏈的構建中，由于開源社區貢獻者眾多，當攻擊者將惡意軟件植入開源軟件中，一旦開發中利用了這些開源軟件，攻擊者便會基于此對企業組織發起惡意攻擊。此外，開源軟件的引入還存在合規性問題，如若沒有強意識做好前期的規劃和預防，當違反開源許可協議時，從法律角度講，都會給企業帶來安全風險。針對眾多開源威脅問題，亟需找尋合適的威脅治理工具，才能從根本解決此類安全威脅問題。84通常情況下，常見的開源安全威脅有如下幾種：1.漏洞利用在 DevOps 快速發展的推動下，從公共存儲庫中提取和使用代碼的開發人員可能會

207、在不知不覺中將易受攻擊、有風險、未經許可或過時的組件整合到他們的項目中。據 Synopsys 網絡安全研究中心(CyRC)發布的 2020 年 OSSRA 報告顯示，75%的商業代碼庫包含開源安全漏洞，近一半包含高風險漏洞。由于開源的分布式特性，漏洞可能會在很長一段時間內未被檢測到，但是攻擊者可以在很長一段時間利用此漏洞。例如前文提到的例子：2017 年信用報告機構 Equifax 的重大漏洞，其中暴露了 1.43 億人的個人信息。事件發生的原因是攻擊者注意到 Equifax 使用了一個開源 Apache Struts 框架的版本，該版本有一個高風險的漏洞，而攻擊者利用了這些信息。2.許可證管

208、理困難單個專有應用程序通常由多個開源組件組成，其項目根據多種許可類型中的任何一種發布，例如 Apache 許可、GPL 或 MIT 許可?？紤]到企業開發和發布軟件的頻率以及存在超過 200 種開源許可證類型的事實，這導致管理開源許可證變得困難。組織必須遵守不同許可的所有單獨條款，否則許可條款會使企業組織面臨法律訴訟的風險，損害公司的財務安全。3.潛在的侵權問題開源組件可能會引入知識產權侵權風險，因為這些項目缺乏標準的商業控制，從而為開源項目引入商業代碼提供了可能。這種風險在 SCO Group 的真實案例中很明顯，該案例聲稱 IBM 竊取了 UnixWare 源代碼的一部分并將其用于他們的 P

209、roject Monterey 以尋求數十億美元的賠償。4.操作風險在企業中使用開源組件時，其主要風險來源之一是運營效率低下。從操作的角度來看，主要關注的是未能跟蹤開源組件并在新版本可用時更新這些組件。這些更新通常會解決高風險的安全漏洞，延遲可能會導致災難，就像 Equifax 事件一樣。因此，對所有開發團隊的開源使用情況進行清點至關重要，不僅要確?？梢娦院屯该鞫?，還要避免不同團隊使用同一組件的不同版本。庫管理需要成為開源使用專用策略的一部分，軟件成分分析工具提供了一種以自動化、易于管理的方式實施這種做法的方法，而無需手動更新電子表格。6.1 開源軟件安全風險 85另一個問題是被遺棄的項目，這

210、些項目可能從開源社區的有力支持逐漸走向消亡，直到沒有人再更新它們。如果此類項目以庫或框架的形式進入應用程序，開發人員有責任修復未來的漏洞。跟蹤不經常更新的項目是良好的庫管理的工作之一。5.開發人員的不當行為一些安全風險是由于開發人員的不當行為而產生的，例如從開源庫復制和粘貼代碼。復制和粘貼是一個問題，首先是因為復制的項目代碼中可能存在漏洞，其次是因為一旦將代碼片段添加到代碼庫中，就無法跟蹤和更新代碼片段，從而使應用程序容易受到未來可能出現的漏洞。企業組織可以通過創建專門的禁止將代碼段直接從項目復制中粘貼到應用程序代碼庫的開源策略來避免此問題。另一個可能發生的不當行為是通過電子郵件或 IM 軟件

211、在團隊之間手動傳輸開源組件。這與推薦的最佳實踐相反，即使用存儲庫管理器來同步組件。86當今的軟件開發環境下，開發人員往往采用開源軟件以加快開發速度。然而隨著開源組件的引入，開源組件漏洞、許可證法律風險問題都是潛在的安全威脅，如何做好安全態勢檢測，在軟件開發生命周期的每個階段做好跟蹤成為必然。開源威脅治理技術中，軟件成分分析（SCA）是其中最為重要的基礎性核心工具，其提供了對集成到開發團隊創建的軟件中的開源組件和庫的可見性，幫助管理安全性和許可證相關的風險，確保嵌入到應用程序中的任何開源組件都符合某些標準，以避免引入可能導致數據泄露、知識產權受損或法律糾紛的風險。隨著開源使用的持續增長，顯然需要

212、 SCA 通過檢測軟件許可證、依賴項以及代碼庫中的已知漏洞和潛在漏洞來分析開源組件，使開發和安全團隊能夠管理其安全風險和許可證合規性。2019 年，Gartner 在報告中把 SCA 納入 AST 技術領域范圍，從而形成了包含 SAST、DAST、IAST 和 SCA 的應用軟件安全測試技術體系，并正式發布了有關 SCA 的技術洞察報告。報告中，對軟件成分分析技術進行了準確定義：軟件成分分析產品通常在開發過程中對應用程序進行分析，以檢測開源軟件組件是否帶有已知的漏洞，例如具有可用安全補丁程序的過期庫，以及需要相應授權許可（法律風險）的商業軟件或第三方產品。在開源威脅治理中，SCA 工具通常應用

213、“清單、分析和控制”框架，讓團隊全面了解開源使用情況以便給出相應的解決方案。6.2 開源威脅治理技術清單分析控制管理 OSS 漏洞的道路始于全面而準確的依賴項清單。畢竟，如果不了解其代碼庫中的所有組件，組織就無法解決漏洞或許可合規性問題。如果 SCA 工具確實檢測到一個易受攻擊的庫，它會披露重要的上下文信息，如漏洞描述、受影響的庫版本、CVSS 評分和嚴重性、CVE 和 CWE 標識、關系路徑(該攻擊是如何引入代碼的)。它還將突出顯示任何許可證遵從性問題，并顯示代碼中發現許可證的位置。最后，SCA 解決方案通過提供補救指導幫助組織控制開源風險。這包括有關如何更好地升級有問題的 OSS 組件的信

214、息。此外，用戶可以輕松地為不同的組件實施拒絕/標記/批準策略，以確保最佳風險狀態。正因如此，SCA 技術在開源威脅治理中得到廣泛應用，并大放異彩。87通常情況下，開源威脅治理前應做好如下幾點。6.3 開源威脅治理的前提6.3.1 樹立開源風險意識6.3.2 明確開源治理規范近幾年從國家層面針對開源也從政策法規的角度做了重要指示，明確了軟件供應鏈安全建設、及對關鍵信息基礎設施建設的重要性，將它提升到了新高度，在行業中也針對其出臺了一系列標準，指出了從軟件設計的不同階段做好安全防范，包括組件漏洞、安全運營等不同維度都有了明確要求。這些都是從比較高的維度對開源/軟件供應鏈安全做了明確的政策引導。反觀

215、之下，站在企業角度，在開源組件的引入和利用之前，從最初的軟件規劃設計階段就應做好開源風險意識的認知，加強開源相關專業人才的培養、同時做好相關專業知識的培訓，從本質上對其重視，讓相關技術人員明確認知到開源風險，提升風險意識。對于企業而言，應該參照國家相關標準規范等，明確要求，同時結合自身制定內部的開源威脅治理規范，便于提前做好開源威脅治理，事先規避相關開源風險。推動內部形成共識，促進開源能力提升。1.漏洞通常情況下，漏洞信息一般都會兼容 OWASP TOP10、國家信息安全漏洞庫（CNNVD）、國家信息安全漏洞共享平臺（CNVD）及 CWE 標準。當發現漏洞時可以對這些漏洞數據進行搜集，通過數據

216、的清洗、關聯和匹配，再結合企業形成的組件 SBOM 清單和引擎進行實時分析。實時更新、查詢實時獲取漏洞庫引擎組件BOM用戶組件庫CVECNNVD漏洞庫開源組件平臺查看BOM告警通知圖 6-1 漏洞分析 886.3.3 建立開源治理制度體系企業需要構建自己的開源管理制度，從企業內部做好開源軟件從最初的引入到最后的輸出管理，形成開源管理的閉環，規范化地做好每個階段的內容。（1）建立開源軟件的審查管理機制無規矩不成方圓，企業和軟件供應商應建立對開源軟件的審查管理機制，嚴格執行對開源軟件全生命周期的安全使用和風險控制。建立針對開源軟件的頂層審查管理機制。設立相應的組織機構，明確管理職責，結合企業的實際

217、特點，制定審查管理制度和流程；建立開源軟件安全準入機制，制定評估要點，在其生命周期內持續評估其完整性、安全性和法律風險，實時掌握開源軟件資產和與其關聯的軟件系統的安全風險狀態；借助于開源軟件的自動化工具持續檢測和發現開源軟件資產，持續跟蹤開源軟件漏洞情報；建立開源軟件的漏洞緩解工作機制，研究開源軟件的漏洞緩解措施，開展應急響應處置，及時規避網絡安全風險；建立開源軟件的運營管理平臺，按照審查管理制度流程，執行開源軟件全生命周期的運營管理，跟蹤并記錄開源軟件動態，提升開源軟件治理效率。（2）推進源代碼安全保障實踐方法落地企業使用開源軟件面臨的首要問題仍然是代碼的安全性問題。在軟件源代碼安全保障實踐

218、方面具有代表性的是微軟提出的安全開發生命周期(Security Development Lifecycle，SDL)和 Gartner 基于敏捷開發推出的DevSecOps 的方法。其中，SDL 將安全要素嵌入培訓、需求分析、系統設計、編碼實現、測試驗證、發布和2.許可證開源促進組織 OSI 頒發了上百個開源許可證協議。對這些開源協議進行風險梳理，尤其當引用了強傳染性的協議時，要特別注意通過智能化的分析去找到相應的組件。當然通過組件也可以找到相應的許可證協議，這樣就能夠及時確定組件或者項目的知識產權風險。3.組件分析組件分析需要支持開發階段、CI/CD階段以及測試階段，全流程對開源組件的檢測，

219、梳理并管控開源組件的信息，并從企業、部門、項目及任務等多角度分析組件的影響范圍和依賴關系?；诙嗑S度的依賴關系分析，通過自動化和智能化的工具協助企業形成 SBOM 清單，從而在追溯的過程中，能夠快速地定位受影響的組件。89響應等軟件開發和運營的 7 個階段。DevSecOps 通過設計一系列可集成的控制措施，增大安全監測、跟蹤和分析力度，將安全融入敏捷過程中，并將安全能力賦予各個團隊，同時保持“敏捷”和“協作”的初衷。無論 SDL 還是 DevSecOps，都可以看到，安全的位置實際上都進行了左移，并且貫穿于所有的過程中。安全活動如下:安全需求分析：結合業務實際需求，依據行業標準規范，如等級保

220、護、分級保護，識別岀軟件系統的安全需求，作為后續安全設計的輸入；安全設計：依據安全需求分析文檔，以減少攻擊面為原則，圍繞用戶輸入驗證、異常處理、身份鑒別、密碼管理、會話安全、訪問控制、安全審計、數據脫敏、防 Web 攻擊等方面對軟件系統進行安全設計；安全編碼：使用指定的安全開發工具，嚴格依據安全設計文檔對軟件系統進行編碼實現；安全測試：借助于源代碼審計、滲透測試和壓力測試等綜合測試方法，充分驗證軟件系統的安全性、可用性和完整性；安全發布：結合實際網絡拓撲，合理部署，減少來自網絡的攻擊面；安全響應：制定網絡安全事件響應計劃和處置流程，有效響應網絡安全事件。（3）借助專業力量持續評估開源軟件安全風

221、險企業應引入或借助專業的技術力量持續加強對開源軟件的安全風險評估。通過常態化滲透測試、代碼安全性分析或者建設網絡靶場，持續、動態地驗證、評估開源軟件的可靠性、可用性和安全性，提升開源軟件的安全應用能力。（4）合作建立開源軟件的漏洞情報庫現有的 CVE/CPE 體系以及 NVD 等漏洞庫，已經無法滿足開源軟件安全治理的需求，需要創新開源軟件的漏洞情報研究、共享、共治機制，合作建立開源軟件漏洞情報庫。90開源治理工具還要與開源治理方案的三個階段也就是安全開發、安全測試和安全管理相結合。在安全開發階段，首先，工具需要結合企業的 IDE，做到安全前置，幫助開發者快速定位漏洞并提供修復方案。其次，工具具

222、備的企業級核心引擎要支持二次開發，因為每家企業的情況是不一樣的，需要對接不同的工具和平臺。第三，工具對于開發人員要友好，不能增加他們的工作量，還要給他們帶來文化和價值的賦能，提升他們相應的能力。在安全測試階段，工具要具備對第三方開源組件的安全性測試功能和系統上線前開源組件的安全審查功能，幫助提高軟件產品的安全性，防止應用帶“病”上線。在安全管理階段，第一點是對第三方組件和供應商軟件的安全準入，要制定相應的準入標準和評估體系，這與軟件供應鏈安全也是相關的。第二點是在企業內部建立安全組件庫，比如 maven 私服庫等，好處在于有一個統一管理的組件引入來源。第三點是軟件和組件的可視化清單分析。有了這

223、樣一個清單，就能夠及時地進行相應的定位。最后一點就是要助力安全部門的合規審查及相關開源治理工作。我們會發現安全合規以及法律部門的介入，都會逐步推進整個開源治理體系的建設。6.4 開源威脅治理階段 91為了減輕開源威脅帶來的安全威脅，國內外安全企業研發設計了相應的治理工具。從使用成本分類，可分為開源（免費）的開源威脅治理工具和商業化的開源威脅治理工具。SCA 是開源威脅治理的核心工具，開源 的 SCA 工 具 有 Snyk Open Source（Snyk）、OpenSCA（懸 鏡 安 全）、Veracode SCA（Veracode）、DependencyCheck（OWASP）等幾個代表性的

224、工具。每個開源威脅治理工具各有不同，各具特色。6.5 開源的 SCA 工具6.5.1 Snyk Open SourceSnyk Open Source 允許在應用程序使用的開源庫中查找和修復漏洞。它還允許查找和解決這些開源庫中（或由這些庫引起的）許可問題。該平臺主動、無縫地查找和解決 Docker 映像和開源依賴項中的許可證違規和漏洞。1.產品優勢1.查找漏洞 映射完整的應用程序依賴樹；檢測所有開源依賴項中的薄弱環節；利用 API、集成或 CLI 添加要測試的項目；不斷測試新發現的漏洞；針對平臺龐大的漏洞數據庫檢查依賴關系。2.報告（標準計劃及以上）可見性：在一個位置查看所有許可證問題和安全漏

225、洞的狀態，概覽設計用于在大屏幕上顯示；問責制：查看團隊解決問題的速度；可審計：項目中使用的所有依賴項的清單，可以導出為 CSV。923.許可證（標準計劃及以上）審查合規性：獲取項目中使用的許可證及其依賴項的清單；保持合規：防止在發出 GitHub 拉取請求時使用有風險的許可證；自定義策略：為企業制定定制的許可策略。定義特定許可證的嚴重性級別，并在項目使用有問題的許可證時收到警報。4.團體（專業計劃及以上）團隊靈活性：為團隊定義區域，以專注于與他們相關的項目；超級強大的報告：了解公司中的薄弱環節狀態；快速過濾器：在報告中包含過濾器，以便快速訪問重要數據。2.檢測能力Snyk Open Sourc

226、e 支持這些開發語言、構建工具和包管理器。支持語言包管理器或工具.Net(C#,F#,Visual Basic)Nuget,PaketBazelSee API docs.C/C+N/AElixirhexGoGo Modules,dep,govendorJavaGradle,Maven表 6-1 Snyk 檢測能力 93JavaScriptnpm,yarnPHPComposerPythonpip,Poetry,pipenvRubyBundlerScalasbtSwift and Objective-C CocoaPods6.5.2 OpenSCAOpenSCA 作為懸鏡安全旗下源鑒 OSS 開源

227、威脅管控平臺的開源版本，繼承了源鑒 OSS 的多源 SCA 開源應用安全缺陷檢測等核心能力，通過軟件成分分析、依賴分析、特征分析、引用識別、合規分析等方法，深度挖掘組件中潛藏的各類安全漏洞及開源協議風險，保障應用開源組件引入的安全。(1)產品優勢1.豐富的語言支持，海量知識庫支撐 支持主流編程語言的軟件成分分析，如：Java、JavaScript、PHP、Ruby；云平臺實時的組件庫/漏洞庫/許可證庫/特征庫等海量知識庫支撐。2.組件依賴解析，可視化 SBOM 分析 組件的直接依賴及間接依賴解析分析；94 組件安全漏洞分析，可快速定位漏洞影響范圍并及時修復；透明化 SBOM（軟件物料清單），助

228、力快速梳理內部軟件資產。3.許可合規分析，知識產權安全保障 支持主流許可證的檢出；分析開源許可證的合規性及兼容性風險。4.企業級核心引擎，更高檢出更低誤報 擁有企業級 SCA 核心檢測引擎及分析引擎；基于海量知識庫，多源 SCA 開源應用安全缺陷檢測等算法，對特征文件進行精準識別，提高組件的檢出率。(2)檢測能力OpenSCA 現已支持以下編程語言相關的配置文件解析及對應的包管理器，后續會逐步支持更多編程語言，豐富相關配置文件的解析。支持語言包管理器解析文件JavaMavenpom.xmlGradle.gradlePHPComposercomposer.lock composer.json表

229、6-2 OpenSCA 檢測能力 95RubyGemgemfile.lock gems.lockedGolangGomodgo.mod go.sumRustCargocargo.lockErlangRebarrebar.lockPythonpippipfile pipfile.lock setup.py(3)數據可視化OpenSCA 具備 HTML 格式報告導出功能，將檢測結果以可視化形式統計、展示，提升了檢測報告的可讀性，便于組件依賴清單及漏洞信息的管理維護。報告結果概覽：1.統計檢出的組件、漏洞數量及占比情況。圖 6-2 結果概覽 962.在檢出的組件依賴列表，會明確展示組件的風險等級、檢

230、出的漏洞數、依賴方式等信息。圖 6-3 依賴列表3.點擊 內的組件，可查看組件的詳細信息，包括檢出路徑、組件漏洞信息等。圖 6-4 漏洞詳情 97(4)應用場景1.安全開發 OpenSCA 包含 IDE 開源風險檢測插件，幫助個人/企業開發者快速定位并修復漏洞；開發人員友好，輕量級低成本零門檻安裝；企業級 SCA 核心引擎，支持二次開發。2.安全測試 產品第三方開源組件的安全測試；提高軟件產品安全性，防止應用帶病上線。3.安全管理 第三方組件及供應商軟件的安全準入；企業內部安全組件庫的建立；軟件或組件資產可視化清單梳理；安全部門合規審查及相關開源治理工作。6.5.3 Veracode SCAV

231、eracode SCA 用于構建第三方組件清單，包括開源和商業代碼，以識別漏洞。Veracode SCA 主要通過掃描編譯應用程序中的庫列表，然后識別每個庫中的已知漏洞。同時，Veracode 也可以通知新公布的影響應用程序的漏洞，而無需執行新的掃描。Veracode SCA 支持兩種掃描方法，可以在開發生命周期的不同階段運行它們：掃描上傳的應用程序和基于代理的掃描。(1)產品優勢 981.在開發環境中進行測試可以直接從命令行啟動掃描，以便在管道和 IDE 中快速反饋。在軟件開發生命周期的早期查看并修復代碼錯誤。2.修復時間短自動修復功能規定了智能修復，生成自動拉取請求，并最大限度地減少中斷，

232、以獲得更高的準確性和更快的修復率，修復時間從幾小時縮短到了幾分鐘。3.自動化開源策略和治理通過持續監控、廣泛的分析和靈活的策略輕松管理開源使用。(2)檢測能力基于代理的掃描語言支持矩陣。支持語言包管理器JavaMavenGradleAntJarsScalaSBTKotlinMavenGradleGoTrash表 6-3 Veracode SCA 檢測能力 99GlideGoVendorGoDepgo getGo modulesDepPythonpipPipenvJavaScriptNPMYarnBowerObjective-CCocoaPodsSwiftCocoaPodsRubyBundler

233、PHPComposerC/C+MakeC#/.NETNuGetDLL 1006.5.4 Dependency-CheckDependency-Check 是 OWASP 的一個實用開源程序的 SCA 工具，用于識別項目依賴項并檢查是否存在任何已知的，公開披露的漏洞。執行依賴項檢查時將收集到的有關依賴項的信息與下載到本地的 CPE&NPM 庫數據進行對比，以此確認該依賴項中是否存在漏洞，如果檢查發現掃描的組件存在已知的易受攻擊的漏洞則標識出來，最后生成報告進行展示。(1)產品優勢Dependency-Check 支持面廣（支持多種語言）、可集成性強，作為一款開源工具，在多年來的發展中已經支持和許

234、多主流的軟件進行集成，比如：命令行、Ant、Maven、Gradle、Jenkins、Sonar 等；具備使用方便，落地簡單等優勢。(2)檢測能力支持語言包管理器JavaMaven、Ant、Gradle.NETPythonRubyPHPNode.jsSwift/OCJavaScript表 6-4 Dependency-Check 檢測能力 1016.5.5 不同工具對比通過對幾個開源工具的調研，從多個細分維度進行統計、對比，結果如下表所示：平臺名稱Snyk Open SourceOpenSCAVeracode SCADependency-Check發布時間2019 年2021 年 12 月20

235、21 年 10 月2012 年廠商Snyk懸鏡安全VeracodeOWASP背景英國中國美國美國官網地址https:/snyk.io/product/open-source-security-management/https:/ 6-5 工具對比表 102產品介紹Snyk Open Source 作為 Snyk SCA 產品的開源版本，允許在應用程序使用的開源庫中查找和修復漏洞。其中還包括 Snyk 許可證合規性，以幫助管理開源許可證使用OpenSCA 作為源鑒 OSS 開源威脅管控平臺的開源版本，繼承了源鑒 OSS 的多源SCA 開源應用安全缺陷檢測等核心能力，通過軟件成分分析、依賴分析、特

236、征分析、引用識別、合規分析等方法，深度挖掘組件中潛藏的各類安全漏洞及開源協議風險Veracode SCA 用于構建第三方組件清單，包括開源和商業代碼，以識別漏洞。在掃描時確定庫和漏洞列表，同時也可以通知新公布的影響應用程序的漏洞，而無需執行新的掃描Dependency-Check 是一種軟件組成分析（SCA）工具，它試圖檢測項目依賴項中包含的公開披露的漏洞。它通過確定給定依賴項是否存在通用平臺枚舉（CPE）標識符來完成此操作。如果找到，它將生成一個報告，鏈接到相關的 CVE 條目適用人群安 全、開 發、測試安 全、開 發、測試開 發、安 全、測試開 發、安 全、測試檢測能力檢測語言支持Java

237、Script、PHP、python、.Net、C/C+、Elixir、Go、Java、Swift and objective-c、Ruby、Scala 等Java、JavaScript、PHP、Ruby、Golang、Rust、Erlang、Python等Java、Scala、Kotlin、Go、Python、JavaScript、Objective-C 等Java、.NET、Python、Ruby、PHP、Node.js、Swift/OC 等 103檢測能力包管理器支持Npm、yarn、Composer、pip、Poetry、pipenv、Nuget、Paket、Gradle、Maven、C

238、ocoaPods、Bundler 等Maven、npm、Composer、Gradle、Gem、go mod、Cargo、Rebar、pip 等Maven、Gradle、Ant、Bundler NPM、Composer、Pip、Gradle 等Maven、Ant、Gradle 等軟件成分分析支持支持支持支持軟件特征分析支持支持不詳不詳軟件直接依賴分 析支持支持支持支持 104檢測能力軟件間接依賴分析支持支持不支持不支持實時檢測支持支持支持支持容器鏡像檢 測支持支持支持支持代碼安全檢測支持支持支持支持檢測場景需求階段支持支持支持支持設計階段支持支持支持支持 105檢測場景 編碼階段支持支持支持支

239、持測試階段支持支持支持支持安全管理階段支持支持支持支持平臺/工具鏈集成IDE插件支持支持支持不支持代碼倉庫支持支持不支持支持特征庫及知識庫漏洞庫兼容CVENVD、CNNVD、CNVDCVENVD組件庫更新不詳支持不詳不詳 106特征庫及知識庫漏洞庫更新支持支持不詳不詳許可證庫更新支持支持支持不詳漏洞庫查詢支持不支持不支持不支持組件庫查詢支持不支持不支持不支持特征庫規則庫更新不詳支持不詳不詳漏洞修復建議支持支持支持不支持 107特征庫及知識庫漏洞利用難度支持支持不支持不支持報告支持支持支持支持總結1.各開源威脅治理工具都有豐富的語言及包管理器支持，可以更好地滿足用戶對工具的需求；2.每個工具都支

240、持軟件成分分析、實時檢測、容器鏡像檢測、代碼安全檢測；3.每個工具都覆蓋需求階段、設計階段、編碼階段、測試階段、安全管理階段的檢測場景，可以更好地支持檢測功能；4.每個工具都支持檢測結果以不同的報告形式展現，可以更好地對安全態勢分析；5.Snyk Open Source、OpenSCA 支持軟件特征分析，其它不詳；6.Snyk Open Source 漏洞庫更新、許可證庫更新;OpenSCA 支持組件庫更新、漏洞庫更新、許可證庫更新、特征庫規則庫更新；Veracode SCA 支持漏洞庫更新；其它不詳。備注：由于某些信息未對外公布，以“不詳”為結論展示。108在落地實踐中，商業化的 SCA 工

241、具更適合在大型企業的場景中使用。針對 SCA 的專項商業工具往往功能比較齊全，包含針對第三方組件的完整性、安全性和合規性檢測的同時，能提供較多的接入方式，例如與組件庫的對接，與代碼倉庫的對接，同當前開發流程的對接等等。國內代表廠商工具如：源鑒 OSS（懸鏡安全）、開源衛士（奇安信）、FOSSCheck(棱鏡七彩)等；國內不管是源代碼文件的 SCA 檢測工具還是二進制文件的 SCA檢測工具，種類還是比較齊全的。國外代表廠商工具如：Black Duck（Synopsys）、Veracode SCA（Veracode）、CxSCA（Checkmarx）、Contrast SCA（Contrast S

242、ecurity）。不管是國內還是國外的應用安全廠商，都有自己成熟的 AST 工具鏈、甚至還有平臺和服務體系，也衍生了更豐富的工具布局和規劃設計，以適應云原生、物聯網、產業互聯網等不同應用場景的需求。在開源治理中，企業應該選擇具有如下能力的 SCA 工具：1.有豐富的語言支持和海量的知識庫支撐。每一個企業都會用到很多語言，除了前端和后端，還包括隨著市場需求變化引入的新技術和新框架。這就要求工具的檢測能力要有非常大的覆蓋面。知識庫包括組件庫、許可證庫和特征庫等，有大量的知識庫支撐才能使分析結果比較完善。2.具備組件依賴解析和可視化 SBOM 分析的能力。從組件定位到相關部門和企業，從相關組件的漏洞

243、定位到受影響的組件，這實際上是多維度關聯分析。同時通過工具化的方式，生成可視化的 SBOM 清單去幫助企業快速梳理內部的資產。3.具備許可證分析能力。要能夠做到對主流許可證的檢出以及對合規性和兼容性的檢測。4.擁有企業級的核心引擎。整個引擎能夠獨立出來，那么基于海量的知識庫，對特殊的特征文件能進行精準識別，提高組件的檢出率。如果知識庫的體量不夠大，不是企業級的檢測和分析引擎，檢出的結果一般是比較差的，誤報率會比較高，同時給出的修復建議和方案也不能夠滿足企業需求。5.具有豐富的檢測能力。對開源組件、二進制文件、第三方軟件、漏洞、容器鏡像等具有檢測能力，可以針對未知威脅做好檢測工作。6.擁有動態分

244、析能力。隨著技術的進步和發展，開源檢測工具也需要有與時俱進的分析能力。比如傳統靜態分析技術包含基于依賴關系分析、基于文件級別的分析、基于代碼片段的分析。由于使用者對結果精準度要求的逐漸提升，動態組件的實時分析能力至關重要。它是在測試環境，依賴 IAST 插樁技術原理，在用戶進行功能測試和性能測試的同時，發現運行中相應組件的信息。這就能夠避免數量巨大的誤報和檢出無法應用的漏洞。6.6 商業化的 SCA 工具 109軟件成分分析依賴分析特征分析引用識別按風險等級預警SCA工具基礎能力圖 6-5 SCA 工具基礎能力SCA 工具選項眾多，對于企業組織機構而言，面對眾多選擇往往會無所適從。第三方調研咨

245、詢機構根據多維度的評判，對 SCA 工具做過匯總式整理，可以作為企業組織選擇工具的參考。1.云計算開源產業聯盟2022 年 7 月，由中國信通院發起成立的云計算開源產業聯盟對外正式發布了中國 DevOps 現狀調查報告（2022）。本次調查由中國信息通信研究院聯合包括中國農業銀行、中國工商銀行軟件開發中心、建信金科、招商銀行、中信銀行、華泰證券、百度、騰訊、華為云 DevCloud、中興 RDCloud、京東、中國聯通軟件研究院在內的超 50 家企業共同發起。問卷以中國信息通信研究院牽頭編制的研發運營一體化（DevOps）能力成熟度模型系列標準為參考，聚焦中國 DevOps 實踐成熟度現狀，對

246、 DevOps 轉型現狀、未來 DevOps 的發展、企業對政策/資質的需求等情況進行了調查。報告中對開源軟件安全工具的使用情況做了詳盡的調查和統計，展示出主流的開源軟件安全工具市場使用率。如下圖所示：圖 6-6 開源軟件安全工具市場占比 1103.數世咨詢國內數字化產業第三方調研與咨詢機構數世咨詢正式發布了2022 年中國數字安全百強報告，百強報告調研了國內 700 余家經營網絡安全業務的企業，基于 2021 年度的上百項評價指標結合多種角度、不同維度的企業相關數據進行梳理和評價?；诖?，根據安全領域進行劃分，分類，形成了此圖譜。在開發安全的分類中，對于能力者和創新者也做了展示，也是企業作為

247、工具選型的強有力依據。圖 6-8 數世咨詢軟件成分分析能力圖譜2.嘶吼安全產業研究院2022 年 7 月 13 日，嘶吼安全產業研究院聯合國家網絡安全產業園區（通州園）正式發布嘶吼 2022 網絡安全產業圖譜。據悉，此次圖譜是嘶吼安全產業研究院結合企業營收、客戶類別、涉及領域、創新能力、投入情況等數據進行深度剖析，精制出品?？梢哉f是在強有力數據支撐的前提下，為每一個細分領域進行分類，為進一步規劃網安產業布局。這也是各個安全廠商工具產品能力的強有力體現。圖 6-7 嘶吼安全產業研究院軟件組件安全分析與監測能力圖譜 1114.斯元商業咨詢2022 年，斯元商業咨詢對外正式推出了Emerging T

248、echnology Vendor Index網安新興賽道廠商速查指南。該指南主要是助力企業安全負責人、渠道合作伙伴和安全從業者及時了解網安行業的新興賽道及前沿產品，在項目產品選型時，高效檢索細分賽道和代表性廠商。圖 6-9 斯元商業咨詢軟件成分分析 SCA 分類廠商軟件供應鏈安全治理發展趨勢07近年來，諸如 SolarWinds、MIMECAST、HAFNIUM 和 Log4j2 漏洞事件已經將軟件供應鏈相關風險的現實問題擺在了人們的面前，讓企業組織意識到了減少軟件供應鏈安全風險的重要性。據數據顯示，軟件供應鏈攻擊影響了 62%的企業組織，可見對企業的危害之大。而且，DevSecOps、云原生

249、、微服務等新技術應用，都為軟件供應鏈的安全帶來了新的安全威脅，軟件供應鏈安全治理在未來會有以下趨勢。113SBOM 是安全和合規最佳實踐的基礎。在美國總統拜登簽署的“關于改善國家網絡安全的行政命令”中，SBOM 是關鍵部分。根據Anchore 2022 軟件供應鏈安全報告，盡管 SBOM 在提供對軟件供應鏈的可見性方面發揮著基礎性作用，但只有三分之一的組織遵循 SBOM 最佳實踐，因此還有很大的實踐增長空間。當前，SBOM 在國內尚缺乏廣泛的認知和了解，頂層的規范、標準與行業要求也未完成建立。造成當下 SBOM落地較難、使用率較低的現狀。但隨著以中國信通院軟件物料清單建設總體框架為代表的 SB

250、OM 標準落地，以及 SBOM 價值的逐步體現，相信 SBOM 會得到越來越多的應用實踐。7.1 軟件物料清單（SBOM）將得到更多實踐圖 7-1 SBOM 實踐使用率 114據Anchore 2022 軟件供應鏈安全報告顯示，由于開發人員在他們構建的容器化應用程序中加入了大量的開源軟件(OSS)，在“最重要的容器安全挑戰”的調查中，24%的受訪者將 OSS 容器的安全性列為第一大挑戰，近一半(45%)受訪者將其列為三大挑戰之一。在“未來18個月優先容器工作計劃”的調查中，“改善軟件供應鏈安全”高居榜首，甚至超過了“提升容器使用率”這一底層訴求?？梢?，未來隨著容器化使用率的不斷提升，開源和供應

251、鏈安全面臨的威脅也逐漸增多。做好容器中的開源和供應鏈安全是未來重點關注的方向。圖 7-2 容器安全挑戰圖 7-3 未來 18 個月優先容器工作計劃調查7.2 供應鏈和開源安全將成為容器安全中的新熱點 115從 2019 年起，我國就成為了世界第一大專利申請國以及第一大論文發表國，且與第二名的差距逐年拉大。這意味著我國在各行業核心技術上，從以學習借鑒為主的跟隨者變成了以創新創造為主的引領者。在這種態勢下，強化對知識產權的重視和尊重是必然結果。2021 年，GPL3.0 許可證侵權案的首例判決，法院認定被告方因使用了原告方的系統代碼（該代碼后續開源版本中已將“適用 GPL3.0 協議”的表述刪除）

252、，因此違反了 GPL3.0 協議導致 GPL3.0 協議自動解除，被告失去了 GPL3.0 協議下的源代碼授權保護，進而構成侵權，且侵權事實成立，最終被判罰 50 萬元。本次判例，讓開源許可證風險真正走到了開源生態相關方的面前。為避免侵犯他人知識產權，引起法律糾紛，開源許可證管理將成為企業在未來開源軟件使用中必不可少的工作。7.3 開源許可證風險將獲得高度關注圖 7-4 GPL3.0 許可證侵權案的判決書 116圖 7-5 RASP 使用場景隨著第三方組件應用率的提升，組件漏洞的影響愈發廣泛，單一組件的漏洞可能會影響成千上萬的用戶和設備，諸如 Log4J2 漏洞（CVE-2021-44228）

253、、Spring 框架漏洞（CVE-2022-22965）等嚴重級軟件基礎設施漏洞的爆發事件引發了社會廣泛的關注和熱烈討論。隨之而來的問題是，在業務系統的安全運營過程中，要如何降低不斷爆發的組件漏洞所造成的風險。傳統安全運營思路更多關注修補過程，而對緩解程序重視不足。在嚴重漏洞爆發時，在漏洞的公布到官網修復補丁發布這段真空期，安全工程師通常采用下線業務系統這種簡單粗暴的方式避免漏洞被攻擊者利用，但這種方式會讓正常業務也無法運行，這在金融、能源、政府等民生類業務系統上是難以接受的。RASP 可以有效地解決這一窘境，RASP 運行在應用內部的特性，使之擁有函數級的威脅攔截能力。RASP 可以做到只攔

254、截漏洞相關的風險函數，對業務系統的運行造成最小的影響。從使用場景看，RASP 解決了傳統安全運營模式在組件漏洞爆發后的緩解期內缺乏精準性手段的問題，之后會成為軟件供應鏈安全運營的基礎性工具。7.4 RASP 會成為軟件供應鏈安全運營的核心工具 117總結08科技的發展讓社會協作變得更加高頻和具有深度，在信息技術行業亦是如此。我們自己的業務系統會集成第三方的代碼、使用第三方提供的開發環境、應用第三方生產的構建工具、運行在第三方開發的微服務和容器之上，這種深度協作方式讓我們的業務生產和運營效率指數級提升，但同時帶來的，也有軟件供應鏈風險史無前例的增長。SolarWinds Orion 事件讓人們見

255、識了供應鏈攻擊能做到什么，Apache Log4J2 漏洞讓人們了解了開源代碼的千瘡百孔，Equifax 信息泄露事件讓人們知道了大型企業的安全建設在軟件供應鏈安全漏洞前是多么的脆弱不堪。這一切，促成了我們對本報告的編撰工作，我們希望用系統性的思維和方式，收集、分析、整理、闡述軟件供應鏈安全治理與運營的方方面面。由于篇幅所限，本文提及的工具、方法和措施只是軟件供應鏈安全領域的滄海一粟，更多的還需要讀者在實踐中探尋。結語CONCLUSION數字化的發展，極大依賴于信息技術的發展，其中最重要的就是軟件。DevOps、Scrum 等敏捷開發的理念，促進了軟件開發的效率，開源軟件等大大促進了軟件的繁榮

256、。但是，數字化時代，軟件系統和經濟利益相關性越來越高，也吸引了更多的惡意攻擊者，通過發現、利用系統潛在漏洞獲取利益，因此對軟件系統自身的安全性提出了更高的要求。信息系統的安全，不僅僅是運營階段的安全監測防護，而是需要全生命周期的安全保障，尤其是開發階段輸出的系統軟件自身的健壯性，包括自身代碼的安全、依賴的組件的安全、使用配置的安全性，這也是“安全左移”或者“DevSecOps”的核心要義，要把安全覆蓋到開發運營的全生命周期。軟件供應鏈安全是保障系統軟件安全的關鍵因素，軟件供應鏈安全的治理需要所有從業者從理念上提高意識；在技術上需要同行共同潛心研發，突破卡脖子技術；加強能力共享，共同推進軟件供應

257、鏈安全公共基礎設施建設。白皮書旨在希望能推動行業共識，促進軟件供應鏈安全的健康發展。2022 年 8 月何國鋒引用參考1Aqua.Software Supply Chain AttacksEB/OL.https:/ 美國“加強軟件供應鏈安全實踐的指南”解讀 EB/OL.https:/ 上官曉麗,孫彥,李彥峰.信息通信技術供應鏈安全政策法規與標準研究 J.中國信息安全,2021 No.143 10 45-48.4REVERSINGLABS.A(Partial)History of Software Supply Chain AttacksEB/OL.https:/ software supply

258、 chain is under attackEB/OL.https:/ supply chain attacks and security:state and outlookEB/OL.https:/www.i-scoop.eu/cybersecurity/software-supply-chain-security/7OWASP.Free for Open Source Application Security ToolsEB/OL.https:/owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools8I

259、TProPortal.The threats of open source software in cloud nativeEB/OL.https:/ Open Source Security Risks You Should Know AboutEB/OL.https:/www.xfive.co/blog/5-open-source-security-risks/10Bytesafe.SLSA:A Novel Framework For Secure Software Supply ChainsEB/OL.https:/bytesafe.dev/posts/slsa-introduction

260、/11nnovecs.TOP 10 SOFTWARE DEVELOPMENT TRENDS TO ADD MASSIVE VALUE TO YOUR BUSINESSEB/OL.https:/ Security Trends:Software Supply Chain SurveyEB/OL.https:/ Conikee.3 Critical Software Development Security Trends and Best PracticesEB/OL.https:/ Common Risks for Supply Chain Cyber Attacks and What to D

261、o About ThemEB/OL.https:/www.argon.io/blog/risk-for-supply-chain-cyberattacks/15 David Shavgulidze.Supply Chain Security Analysis of the Georgian EcosystemEB/OL.https:/www.isaca.org/en/resources/news-and-trends/isaca-now-blog/2022/supply-chain-security-analysis-of-the-georgian-ecosystem16Stephen Pri

262、tchard.Software supply chain attacks everything you need to knowEB/OL.https:/ Complete Guide to Software Composition AnalysisEB/OL.https:/ 懸鏡安全.IAST 技術進階系列（一）：關鍵語言支持 EB/OL.https:/ 懸鏡安全.IAST 技術進階系列（二）：全場景多核驅動 EB/OL.https:/ 懸鏡安全.IAST 技術進階系列（三）：高并發&高可用場景支持 EB/OL.https:/ 中國信息通信研究院.研發運營安全白皮書（2020）R.北京:中國

263、信息通信研究院,2020.22 中國信息通信研究院.研發運營一體化（DevOps）能力成熟度模型 R.北京:中國信息通信研究院,2018.23 中國信息通信研究院.軟件供應鏈安全發展洞察報告（2021 年）EB/OL.北京:中國信息通信研究院,2021.http:/ 何熙巽,張玉清,劉奇旭.軟件供應鏈安全綜述 J.信息安全學報,2020,5(1).25 國家保密科技測評中心.開源軟件風險分析及治理措施研究 EB/OL.20202021.http:/ 國家保密科技測評中心.開源軟件漏洞安全風險分析 EB/OL.20202021.http:/ 阿里云云棲號.對 SolarWinds 事件更深的思考:如何防御供應鏈攻擊 EB/OL.20212021.https:/