淺談軟件供應鏈安全治理與應用實踐

隨著容器、微服務等新技術日新月異，開源軟件成為業界主流形態，軟件行業快速發展。但同時，軟件供應鏈也越來越趨于復雜化和多樣化，軟件供應鏈安全風險不斷加劇，針對軟件供應鏈薄弱環節的網絡攻擊隨之增加，軟件供應鏈成為影響軟件安全的關鍵因素之一。近年來，全球針對軟件供應鏈的安全事件頻發，影響巨大，軟件供應鏈安全已然成為一個全球性問題。全面、高效地保障軟件供應鏈的安全對于我國軟件行業發展、數字化進程推進具有重要意義。

近日，在由中國信通院指導、懸鏡安全主辦的中國首屆DevSecOps敏捷安全大會（DSO 2021）現場，《軟件供應鏈安全白皮書（2021）》（以下簡稱“白皮書”）正式發布。本白皮書著重分析了軟件供應鏈安全，梳理了軟件供應鏈的安全現狀，透過現狀全面剖析軟件供應鏈的安全風險及面臨的安全挑戰，有針對性地提出如何對軟件供應鏈的安全風險進行防范與治理，系統闡述了軟件供應鏈安全的防護體系及軟件供應鏈安全的應用實踐以供參考，最后白皮書結合現在軟件供應鏈安全的發展趨勢進行了全面的分析及展望。

由于篇幅有限，僅摘選本報告“軟件供應鏈安全治理”及“軟件供應鏈應用實踐”兩部分進行分享。 

一、軟件供應鏈安全治理

目前，業界已充分認識到造成網絡安全事件出現的主要原因之一，是由于軟件開發者在開發過程中對開發工具、開發團隊、開發生命周期和軟件產品自身管理不當，致使軟件存在著安全缺陷，破壞或影響最終用戶的信息安全。 

通過推進針對軟件生命周期進行全流程安全管控的落地實踐，有助于從軟件生命周期的源頭保障軟件供應鏈安全。通過建立軟件開發過程中保證軟件供應鏈安全的體系化方法，為軟件開發過程中盡可能避免和消除軟件的安全缺陷、保證軟件供應鏈安全奠定重要基礎。

從軟件安全開發生命周期角度分析軟件供應鏈安全的應用實踐方法，主要有以下幾個階段。

1、體系構建階段

SDL 軟件安全開發生命周期 

微軟在21世紀初期的軟件產品開發實踐中，意識到無法通過技術層面徹底解決軟件面臨的安全風險。因此，微軟嘗試從流程和管理的角度解決這個問題，并探索在各個軟件開發環節中加入安全過程、把控安全風險，確保每個環節交付到下一環節的交付物都安全可控。于是，針對傳統的瀑布式模型微軟提出了“SDL 軟件安全開發生命周期” 這一概念。 

軟件安全開發生命周期（SDL），是一個在幫助開發人員構建更安全的軟件和解決安全合規要求的同時降低開發成本的軟件開發過程。SDL將軟件開發生命周期劃分為7 個階段（如圖所示），并提出了 17 項重要的安全活動，旨在將安全集成在軟件開發的每一個階段，以減少軟件中漏洞的數量并將安全缺陷降低到最小程度。SDL更側重的是軟件開發的安全保障過程，旨在開發出安全的軟件產品。 

 圖 1 SDL 軟件安全開發生命周期

在 SDL 的 7 個階段中（如圖 1所示），SDL 要求前 6 個階段的 16 項安全活動，為開發團隊必須完成的安全活動。同時，SDL 認為開發團隊應該保持靈活性，以便選擇更多合適的安全活動，如人工代碼分析、滲透測試、相似應 用程序的漏洞分析，以確保對某些軟件組件進行更高級別的安全分析。SDL 重視各種工具的使用，重心在從需求階段到測試階段的工具集，如威脅建模、靜態源代碼分析等工具。

SDL 的 7 個階段主要的含義如下： 

培訓：針對開發團隊進行安全意識與能力的培訓，以確保 SDL 能有效實施并落地，同時針對新的安全問題與形勢 持續提升團隊的安全能力； 

需求：通過安全需求分析，定義軟件產品安全實現過程中所需要的安全標準和相關要求； 

設計：通過分析攻擊面，設計相對應的功能和策略，降低和減少不必要的安全風險。同時通過威脅建模，分析軟 件的安全威脅，提出緩解措施； 

實施：按設計要求，實現對應功能和策略，以及緩解措施涉及的安全功能和策略。同時通過安全編碼和禁用不安 全的 API，減少實施時導致的安全問題，盡量避免引入編碼級的安全漏洞，并通過代碼審計等措施來確保安全編碼規范的實行； 

驗證：通過安全測試檢測軟件的安全漏洞，并全面核查攻擊面，各個關鍵因素上的威脅緩解措施是否得以驗證； 

發布：建立相應的響應計劃，進行最終安全檢查，確認所有安全活動均完成后將最終版本發送給客戶； 

響應：當出現安全事件與漏洞報告時，及時實施應急響應和漏洞修復。在此過程中新發現的問題和安全問題模式，可用于 SDL 的持續改進過程中。

DevSecOps 

DevSecOps 是一種全新的安全理念和模式，由 DevOps 的概念延伸和演變而來。其核心理念是安全是整個 IT 團隊 每個人的責任，需要貫穿從開發到運營整個業務生命周期每一個環節才能提供有效保障。 

DevSecOps 覆蓋編碼階段、測試階段、預發布階段、發布階段、線上運營階段，強調自動化與平臺化，由 CI/CD 平臺推動整個開發和運營流程自動化。DevSecOps 依賴于 DevOps 流程工具鏈（如圖 2 所示），將威脅建模工具、安全編碼工具、安全測試工具、容器安全檢測工具、基線加固工具、漏洞管理工具等自動化工具無縫集成到 DevOps 流程中，進而實現開發 - 安全 - 運營一體化。 

圖 2 DevSecOps 工具鏈

很多企業在向 DevSecOps 轉型時，會發現很多傳統的安全工具在集成性和實用性上都難以滿足 DevSecOps 的需求， 因此，在 DevSecOps 的不同階段需要采用不同的 DevSecOps 安全工具（如圖 3 所示），這些安全工具主要的共同特點是高度自動化以及可集成性。

圖 3 DevSecOps 安全工具在不同階段的自動化程度

在軟件供應鏈中每個階段都在面臨不同的安全風險，為了更好的對軟件供應鏈進行風險治理，在 DevSecOps 模式 下，安全開發工具鏈需要盡量覆蓋軟件生命周期中的所有階段（如圖 4 所示）。 

圖 4DevSecOps 模式下軟件生命周期

除了以上所提到的工具之外，在 DevSecOps 的應用實踐過程中，還有一些更為前瞻性的安全工具，具體可參考 DevSecOps 敏捷安全技術金字塔（如圖 5所示）。該金字塔在《2020 DevSecOps 行業洞察報告》中首次被提出， 目前已發展到 2.0 版本。其描述了一組層次結構，金字塔底部是基礎性技術，越上層的技術對 DevSecOps 實踐成 熟度的要求越高。

圖 5 DevSecOps 敏捷安全技術金字塔 V2.0 版

DevSecOps 敏捷安全技術金字塔的不斷升級，是為了給業界更好的預測和參考，關于 DevSecOps 敏捷安全技術 未來演進方向的預測是開放且持續性的，隨著 DevSecOps 實踐的不斷發展，其中的安全工具會進行調整和更新。

2、設計階段

軟件供應商風險管理流程

軟件供應商風險是指與第三方供應商相關的任何可能影響企業利益或資產的固有風險。在選擇第三方軟件供應商 時，為了避免因引入第三方供應商而帶來眾多潛在的安全風險，需要穩健的流程來識別和管理日益增加的軟件供 應商風險。因此，企業亟需構建有效且穩健的軟件供應商風險管理流程。 

構建完整的軟件供應商風險管理流程可以提高軟件供應鏈的透明度，同時幫助企業實現降低采購成本、識別和減 輕供應商相關風險以及對軟件供應商風險管理系統的持續優化改進。以下是針對軟件供應商基本風險管理流程（如 圖 6所示）。

圖 6 軟件供應商風險管理流程

標準確立：結合企業的實際情況，構建軟件供應商評估模型，制定軟件供應商考核的評估標準及安全框架； 

資格評估：根據制定的軟件供應商評估模型和相關標準，對初步符合要求的軟件供應商進行多維度的綜合性資格評估，選出匹配度最高的供應商； 

風險評估：對通過資格評估的軟件供應商進行安全風險評估，針對軟件供應商面臨的潛在的安全風險、存在的弱點 以及有可能造成的影響綜合分析其可能帶來的安全風險進行評估； 

風險監控：對軟件供應商實施長期性的安全風險監控，持續識別和管理軟件供應商的安全風險，根據監測結果實施更新軟件供應商的風險管理策略。

軟件供應商評估模型

為了確保企業可以擁有較為穩定的供應鏈，提高企業的綜合競爭力，經過多方面的綜合考察分析，以下構建了一 個系統化、結構化的軟件供應商評估模型以供參考。軟件供應商評估模型的關鍵意義在于從不同的維度對軟件供 應商進行評估，通過考察軟件供應商的綜合實力，以選擇最合適的合作伙伴。以下是通過十二種不同維度對軟件 供應商評估的全過程（如圖 7所示）。

圖 7 軟件供應商評估模型

財務實力：評估軟件供應商的財務能力以及穩定性，確保供應商具有穩定性和可靠性來提供業務所需要的服務； 

質量承諾：評估軟件供應商的相關軟件產品是否符合國家及行業標準要求，信息安全和數據保護控制流程必須遵 守法律、監管或合同義務以及任何行業標準的信息安全要求； 

企業資質：評估軟件供應鏈上的第三方供應商是否能夠提供軟件安全開發能力的企業級資質，是否具備國際、國家或行業的安全開發資質，在軟件安全開發的過程管理、質量管理、配置管理、人員能力等方面是否具備一定的經驗，具有把安全融入軟件開發過程的能力； 

技術儲備：評估軟件供應商是否擁有自主研發能力以及自主技術知識產權，對科技知識是否有進行不斷的積累和及時更新，對企業提高技術水平、促進軟件生產發展是否有開展一系列的技術研究； 

合作能力：評估軟件供應商是否擁有高效的溝通渠道以及全面的解決方案，擁有共同的價值觀和工作理念有助于建立長期的合作關系； 

軟件交付能力：評估軟件供應商在整個軟件及信息服務交付的過程中，是否能滿足軟件持續性交付的要求；

應急響應能力：評估軟件供應商從軟件開發到運營階段是否持續實行實時監控機制，是否有利用適當的網絡和基 于端點的控制來收集用戶活動、異常、故障和事件的安全日志，是否具有適當的業務連續性和恢復能力，以防止或減輕業務中斷和相關影響； 

服務能力：評估軟件供應商的售前服務能力、培訓服務能力以及售后維護服務能力是否滿足企業的要求，在合作 期間內是否可以始終如一的提供高水平的質量和服務；

創新能力：評估軟件供應商的綜合創新能力，包括技術創新能力、研究開發能力、產品創新能力以及生產創造力等；

內部管理能力：評估軟件供應商是否擁有完善的內部管理制度流程、有效的風險防范機制以及是否對員工定期進行安全培訓等，對供應商內部安全開發標準和規范進行審查，要求其能夠對開發軟件的不同應用場景、不同架構設計、不同開發語言進行規范約束，審查軟件供應商對其自身信息安全保密程度； 

軟件成本：評估軟件供應商所提供的軟件成本是否存在虛報等現象，審查產品及相關服務是否可以按照合理的價格交付； 

軟件適用性：評估軟件在開發部署以及動態運行時的適用性，是否可以持續滿足新的需求。

軟件供應商風險管理的作用

通過對軟件供應商風險管理有助于企業更加高效準確地控制軟件供應商帶來的新的安全風險，以下是軟件供應商 風險管理的具體作用。 

降低風險：通過對軟件供應商進行徹底的審查可以識別其可能對業務構成的安全威脅的任何潛在弱點，根據軟件供應商對企業業務的影響確定漏洞的重要性； 

降低成本：通過對軟件供應商風險進行充分的評估，可以以主動而非被動的方式應對安全威脅，減少潛在的安全風險，避免網絡安全攻擊或其他數據泄露等問題給企業造成的財務損失； 

提高效率：通過對軟件供應商進行實時風險監控，可以提前預知風險并及時做出響應，提高企業處理安全風險的 效率； 

培養長期合作關系：通過對供應商風險的管理、評估和跟蹤監控，加強對供應商健康狀況的監督，有助于培養可靠的長期合作關系。

3、編碼階段

構建詳細的軟件物料清單

軟件供應鏈安全始于對關鍵環節的可見性，企業需要為每個應用程序持續構建詳細的 SBOM（Software Bill of Material，軟件物料清單）（如表 2 所示），從而全面洞察每個應用軟件的組件情況。SBOM 是描述軟件包依賴樹 的一系列元數據，包括供應商、版本號和組件名稱等多項關鍵信息，這些信息在分析軟件安全漏洞時發揮著重要作用。

表 1 軟件物料清單示例

上表是一份軟件物料清單示例，其中 SPDX 和 SWID 是兩種國際通用的 SBOM 字段標準。SPDX（The Software Package Data Exchange，軟件包數據交換）是 Linux 基金會下的開放性標準，其用于交流軟件物料清單信息，包括組件、許可證、版權等信息。SPDX 通過為公司和社區共享重要數據提供通用格式來減少冗余工作，從而簡化 流程并提高合規性。SWID（Software Identification，軟件標識）標簽旨在為組織提供一種透明的方式來跟蹤在他們的托管設備商安裝的軟件，它于 2012 年由 ISO 提出，并于 2015 年更新為 ISO/IEC 19770-2:2015。

SWID 標 簽文件包含有關軟件產品特定版本詳盡的描述性信息。除表格中的兩種應用最為廣泛的 SBOM 字段標準外，還有 CycloneDX、CoSWID、CPE、Grafeas 等其他較為常見的標準，各標準的應用場景存在一定的區別。 

SBOM 的概念源自制造業，其中物料清單是詳細說明產品中包含的所有項目的清單。例如：在汽車行業，制造商會 為每輛車維護一份詳細的材料清單。此 BOM 列出了原始設備制造商自己制造的零件和第三方供應商的零件。當發現有缺陷的部件時，汽車制造商可以準確地知道哪些車輛受到影響，并可以通知車主維修或更換。

同樣，構建軟件的企業也需要維護準確、最新的 SBOM，其中包括第三方和開源組件的清單，以確保其代碼質量高、合規且安全。企業通過要求軟件供應商提供 SBOM，以發現潛在的安全和許可證問題，或者應用程序是否使用過 時的庫版本。

當發現此類問題時，管理員可以要求供應商使用較新版本重建應用程序，在等待更新的軟件期間，安全人員有機會采取臨時緩解措施來保護應用程序免受攻擊者利用該漏洞進行攻擊，還可以幫助安全人員在漏洞 被披露或核心庫發布新版本時 , 對應用程序和代碼進行抽查以避免出現安全問題。

舉個例子：如果安全人員手中有一份在其環境中運行的每個應用程序的物料清單，那么早在 2014 年 4 月，當 Heartbleed 漏洞最初被披露時，安全人員就無需測試每個應用程序中是否包含 OpenSSL，而是可以通過檢查列表 就立即知道哪些應用程序依賴于易受攻擊的版本和需要采取的措施。

SBOM 生產流程

在成熟的體系下，SBOM 的生產可以通過軟件生命周期每個階段所使用的工具和任務流程化地完成，這些工具和 任務包括知識產權審計、采購管理、許可證管理、代碼掃描、版本控制系統、編譯器、構建工具、CI/CD 工具、包 管理器和版本庫管理工具等（如圖 8 所示）。

圖8 SBOM 生產流程

SBOM 中應該包含軟件組件與此組件所依賴的任何其他基礎軟件組件之間的關系。軟件產品在發布任何版本時， SBOM 都應作為產品文檔的一部分被提供，在 CI/CD 的標準實踐中，SBOM 中包含的信息將不斷更新。它從在需求中集成安全性需求開始，或者是 SBOM 中的一些元素已經在需求階段被添加到用例中，這樣安全性和 SBOM 就可以成為 DevOps 過程的標準和結構化的一部分。 

為了確保持續一致性，應在測試工作中將 SBOM 作為測試用例的一部分，同時 SBOM 信息應隨著使用工具和組 件的更新而更新，使 SBOM 信息自動更新成為 CI/CD 管道中每個構建周期標準的一部分。在發布運營階段使用 SBOM 可以在使用的庫或組件存在漏洞時，以更快的時間檢測出有哪些應用程序中存在這些漏洞，并及時進行修復工作。

SBOM 可提高軟件供應鏈的透明度

盡管 SBOM 對許多人來說依然很陌生，但其需求卻不斷呈現增長態勢。Gartner 在其 2020 年的“應用程序安全測 試魔力象限”中預測到：“到 2024 年，至少一半的企業軟件買家要求軟件供應商必須提供詳細的、定期更新的軟 件物料清單，同時 60% 的企業將為他們創建的所有應用程序和服務自動構建軟件材料清單，而這兩組數據在 2019 年都還不到 5%。” 

現代軟件是使用第三方組件組裝而成的，它們以復雜而獨特的方式粘合在一起，并與原始代碼集成以實現企業所 需要的功能。在現代多層供應鏈中，單個軟件可能有成百上千的供應商，從原材料來源到最終組裝系統的全套供 應商中找出某一組件的來源需要花費大量的時間和精力。因此，為所有組件構建詳細準確的 SBOM，幫助企業跟 蹤當前運行的程序、源代碼、構建依賴項、子組件等所依賴組件的使用情況，檢測軟件組件是否帶有已知的安全 漏洞或功能漏洞。

圖 9 SBOM 的作用

SBOM 有助于揭示整個軟件供應鏈中的漏洞與弱點，提高軟件供應鏈的透明度，減輕軟件供應鏈攻擊的威脅。通過 使用 SBOM 可以幫助企業進行漏洞管理、應急響應、資產管理、許可證和授權管理、知識產權管理、合規性管理、 基線建立和配置管理等（如圖9所示）。 

通過自動化創建 SBOM 可以在漏洞披露時及時地進行響應排查以及快速的安全修復，最小化軟件供應鏈的安全風 險；在開源組件和版本快速迭代的情況下，從風險管理的角度跟蹤和持續監測閉源組件和開源組件的安全態勢； 

同時 SBOM 列舉了管理開源組件的許可證，可以保護企業免受不當使用相關的法律或知識產權的風險，保護應用 程序在軟件供應鏈中的合規性，避免將已知缺陷傳遞到軟件供應鏈的下游。

SBOM 為漏洞風險治理節省大量時間

SBOM 的使用可以為軟件供應鏈的漏洞治理節省大量時間。及時性對于企業在漏洞修復時是非常重要的。以往， 企業在修復已部署系統的漏洞缺陷時往往需要幾個月甚至是數年的時間，其重要原因之一是企業無法在漏洞出現 的第一時間知曉該信息。

軟件供應鏈下游的企業需要等待上游軟件供應商完成軟件補丁，才可以進行漏洞修復， 在等待的時間內，下游企業往往會面臨無法預知的安全風險。而構建詳細準確的 SBOM 則可以避免這一現象的發生， 允許所有利益相關者在漏洞發現時立即開始評估漏洞，并開始制定相關的補救措施。以下通過一張對比圖來說明 SBOM 對漏洞風險治理時間的影響（如圖 10 所示）。

圖 10 SBOM 對漏洞風險治理時間的影響

受感染的開源組件在軟件中未被修復的每一分鐘都會增加潛在被利用的風險，SBOM 有助于企業在漏洞披露的早期 對漏洞進行識別，通過 SBOM 提供受感染開源組件和依賴項的準確位置，采取適當的步驟進行修改，為企業在風 險分析、漏洞管理和補救過程中節省數百小時至數月的時間。

使用基于 SCA 技術的工具

企業需要謹慎、合理地選擇、獲取和使用第三方閉源組件和開源組件。軟件安全團隊或研發團隊通過必要的技術 手段確保所使用的第三方組件的安全性，及時獲取所使用第三方組件和開源組件的漏洞情報，并適時做出響應。 

軟件成分分析（Software Composition Analysis ，SCA）是一種對二進制軟件的組成部分進行識別、分析和追蹤 的技術。SCA 可以生成完整的 SBOM，分析開發人員所使用的各種源碼、模塊、框架和庫，以識別和清點開源軟 件（OSS）的組件及其構成和依賴關系，并精準識別系統中存在的已知安全漏洞或者潛在的許可證授權問題，把 這些安全風險排除在軟件的發布上線之前，也適用于軟件運行中的診斷分析。 

軟件成分分析分為兩種模式，靜態和動態。靜態模式是使用工具對目標工程文件進行解壓，識別和分析各個組件 的關系；動態模式則是依賴于執行過程，在程序執行的同時收集必要的活動元數據信息，通過數據流跟蹤的方式對目標組件的各個部分之間的關系進行標定。通過使用基于多源 SCA 開源應用安全缺陷檢測技術的安全審查工具，可以精準識別應用開發過程中，軟件開發人 員有意或違規引用的開源第三方組件，并通過對應用組成進行分析，多維度提取開源組件特征，計算組件指紋信息， 深度挖掘組件中潛藏的各類安全漏洞及開源協議風險。

某金融企業的業務團隊無法接受速度的遲滯，在研發效率和編碼速度的考量下，大量的軟件應用都基于第三 方的組件、開源代碼、通用函數庫實現，隨之而來是絕大多數應用程序都包含開源組件的安全風險，為企業 帶來了許多未知的安全隱患。為了更好地進行開源組件治理工作，該企業引入基于 SCA 技術的工具，與 DevOps 流程無縫結合，在流水線 的測試階段自動發現應用程序中的開源組件，提供關鍵版本控制和使用信息，并在 DevOps 的任何階段檢測 到漏洞風險和策略風險時觸發安全警報。所有信息都通過安全和開發團隊所使用的平臺工具實時發送，實現 及時的反饋循環和快速行動。 

在不改變該企業現有開發測試流程的前提下，將 SCA 工具與代碼版本管理系統、構建工具、持續集成系統、 缺陷跟蹤系統等無縫對接，將源代碼缺陷檢測和源代碼合規檢測融入到企業開發測試流程中，幫助企業以最 小代價落地源代碼安全保障體系，降低軟件安全問題的修復成本，提升軟件質量。

4、發布運營階段

建立成熟的應急響應機制

在軟件的發布運營階段，企業需要具備安全應急響應能力（如圖 11所示），能在軟件發布后對發生在軟件和軟件 補丁獲取渠道的軟件供應鏈安全事件、軟件安全漏洞披露事件進行快速的安全響應，控制和消除安全事件所帶來的 安全威脅和不良影響，進而追溯和解決造成安全事件的根源所在。 

發布運營階段包括監測告警、應急響應、事件處置、持續跟進等關鍵活動。在日常的運營管理中，企業可以通過采 用自動化分析技術對數據進行實時統計分析，發現潛在的安全風險，并自動發送警報信息。在有突發事件出現時， 通過監測預警，安全人員可以迅速地進行安全響應，在最短的時間內確定相關解決方案并進行事件處置，在解決之后進行經驗總結并改進。通過監測預警技術對軟件系統進行實時自動監測，當發現安全問題時，立即發出警告， 同時實現信息快速發布和安全人員的快速響應。 

圖 11 安全風險監測分析及響應

在發布運營階段發生突發事件之后的應急響應與對安全事件進行處理的管理能力相關，因此，企業需要加強檢測預 警能力、提高應急響應速度、加快應急處置效率，從事后被動救火轉化為主動應急管理。充分預估突發事件的場景， 通過管理活動與技術手段避免突發事件的發生，在突發事件發生時能夠及時監測預警，并有序進行處理行為。

由于在應用程序發布很久之后，仍有可能在其中發現新的安全漏洞，這些漏洞可能存在于構成應用程序的底層開源 組件中，導致“零日”漏洞的數量不斷增加。因此，企業需要制定事件響應和漏洞處理策略，與領先的漏洞研究機 構進行合作，積極監控大量漏洞信息來源。同時，進行持續性的安全檢查，定期的安全檢查可以保護應用程序免受 新發現的安全漏洞的影響。

構建完善的運營保障工具鏈

BAS

2017 年，Gartner《面向威脅技術的成熟度曲線》中首次提及入侵與攻擊模擬（ Breach and Attack Simulation， BAS）工具（如圖 12 所示），并將其歸到新興技術行列。在 2021 年，Gartner 將 BAS 納入“2021 年頂級安全和 風險管理趨勢”。 

圖 12 BAS 技術原理

BAS 通過模擬對端點的惡意軟件攻擊、數據泄露和復雜的 APT 攻擊，測試組織的網絡安全基礎設施是否安全可靠， 在執行結束時，系統將生成關于組織安全風險的詳細報告，并提供相關解決方案。同時結合紅隊和藍隊的技術使 其實現自動化和持續化，實時洞察組織的安全態勢。 

BAS 可以確定漏洞的覆蓋范圍并對檢測出的漏洞提供補救意見，防止攻擊者對漏洞加以利用。除了自動化和持續 監控之外，BAS 還使安全團隊改變了他們的防御方式，采取更為主動積極的策略，維護組織各個方面的安全。

WAF

早在 2007 年，國家計算機網絡應急技術處理協調中心檢測到中國大陸被篡改網站總數累積達 61228 個，比 2006 年增加了 1.5 倍。其中，中國大陸政府網站被篡改各月累計達 4234 個。為了更好的應對網絡攻擊，Web 應用防護 系統也被稱為網站應用級入侵防御系統（Web Application Firewall, WAF）應運而生，WAF 可以對來自 Web 應用 程序客戶端的各類請求進行內容檢測和驗證，確保其安全性和合法性，對非法的請求予以實時阻斷，從而對各類 網站站點進行有效的安全防護（如圖 13 所示）。

圖 13 WAF 技術原理

WAF 通過增強輸入驗證，可以在運營階段有效防止網頁篡改、信息泄露、木馬植入等惡意網絡入侵行為，從而減 小 Web 服務器被攻擊的可能性。同時，WAF 還可以判斷用戶是否是第一次訪問，將請求重定向到默認登錄頁面并 且記錄時間，通過檢測用戶的整個操作行為可以更容易識別攻擊。

RASP

作為第一道防線，WAF 能夠阻止基本攻擊，但難以檢測到 APT 等高級威脅，不僅如此，企業需要持續“調整”WAF 以適應不斷變化的應用程序，這一過程消耗了安全管理人員大量的精力。此時，運行時應用程序自我保護技術 （Runtime Application Self-protection，RASP）（如圖 14所示）作為新一代運行時保護技術被引入，RASP 可以 提供更深入的保護能力，更廣泛的覆蓋范圍，并且可以花費更少的時間。 

RASP 將保護代碼像一劑疫苗注入到應用程序中，與應用程序融為一體，使應用程序具備自我保護能力。RASP 結 合應用的邏輯及上下文，對訪問應用系統的每一段堆棧進行檢測，當應用程序遭受到實際攻擊和傷害時，RASP 可 以實時檢測和阻斷安全攻擊，無需人工干預，最終實現軟件應用的自我保護，確保軟件應用的安全運行。

 圖 14 RASP 技術原理

RASP 在運營階段可以應對無處不在的應用漏洞與網絡威脅，為應用程序提供全生命周期的動態安全保護，可以精 準識別應用運行時暴露出的各種安全漏洞，進行深度且更加有效的威脅分析，快速定位應用漏洞，大大提升修復 效率，保障應用程序的安全性。

威脅情報平臺

通過建立威脅情報平臺（Threat Intelligence Platform，TIP）（如圖 27 所示），可以幫助安全人員明確企業的在 線資產和安全狀況，根據企業自身資產的重要程度和影響面，進行相關的漏洞修補和風險管理；同時可以幫助安 全人員了解企業自身正在遭受或未來面臨的安全威脅，提供解決建議。

圖 15 威脅情報平臺原理

威脅情報平臺與各類網絡安全設備和軟件系統協同工作，為威脅分析和防護決策提供數據支撐，通過對全球網絡 威脅態勢進行長期監測，以大數據為基礎發布威脅態勢預警，實時洞悉風險信息，進而快速處置風險。

容器安全工具

在發布運營階段，通過使用容器安全工具（Container Security）（如圖 28 所示），可以自動化構建容器資產相關 信息，提供容器環境中各類資產的狀態監控，包括容器、鏡像、鏡像倉庫和主機等基礎資產信息，使資產擁有較 強的可擴展能力；通過建立智能應用補丁掃描工具，為安全人員提供鏡像管理、鏡像檢測以及自動化補丁修復建議。

 圖 16某容器安全工具架構

為了更好地應對未知和迅速變化的攻擊，容器安全工具可以對數據進行持續監控和分析，通過結合系統規則、基 線和行為建模等要素，自適應識別運行時容器環境中的安全威脅；建立一鍵自動化檢測機制，給安全人員提供可 視化基線檢查結果，同時將企業現有的安全技術與持續運營的安全模型相結合，實現持續化的動態安全檢測。

二、軟件供應鏈安全應用實踐

可信研發運營安全能力成熟度模型

中國信息通信研究院云計算與大數據研究所自 2019 年起，聯合業界眾多頭部廠商專家制定《可信研發運營安全能 力成熟度模型》標準，提出可信研發運營安全能力體系框架（如圖 17 所示）。可信研發運營安全能力體系框架的 構建繼承 SDL 與 DevSecOps 的核心理念，安全前置，汲取 SDL 與 DevSecOps 體系的優點，優化具體安全實踐要素，是一種貫穿研發運營全生命周期的安全理念。

 圖 17 可信研發運營安全能力體系框架

可信研發運營安全能力體系框架強調安全左移，分為管理制度以及涉及軟件應用服務全生命周期的需求階段、安 全需求分析階段、設計階段、開發階段、驗證階段、發布階段、運營階段和停用下線階段八大部分，每個部分提 取了關鍵安全要素，規范了企業研發運營安全能力的成熟度水平。根據各階段安全要素達標情況，可信研發運營 安全能力成熟度模型共分為 3 個級別，自低向高依次為基礎級、增強級和先進級。

云安全共享責任模型

在云計算環境下，云服務提供商與云租戶需要進行軟件供應鏈安全共治，但云服務普遍存在安全責任劃分不清晰 與治理措施不明確等問題，為了解決這些問題，2019 年，微軟在《Shared Responsibility in the Cloud》中提到 云安全共享責任模型（如圖 18 所示）。云安全共享責任模型指出，在基礎設施即服務（IaaS）、平臺即服務（PaaS） 和軟件即服務（SaaS）三種不同的云服務模式下，云服務提供商（Cloud Service Provider，CSP）和客戶之間需 要分擔的安全責任不同。CSP 需要承擔客戶在使用云服務時保障物理安全的責任，客戶需要負責確保其解決方案 及其數據被安全地識別、標記和正確的分類，以滿足任何合規義務的責任，其余的責任則由 CSP 和客戶共同承擔。

圖 18 云安全共享責任模型

在構建以混合云作為運行環境的軟件程序時，應仔細評估應用程序的依賴性和安全影響，通過使用成熟的 DevSecOps 模型可以幫助組織評估整個軟件供應鏈，并確定需要嚴格控制的安全關鍵點。為了提高可見性和支持混合云體系結構，許多云服務商顯示或允許應用程序接口（API）與安全進程的交互。不成 熟的 CSP 可能不知道如何以及在多大程度上向客戶提供 API。例如，通過檢索日志或權限控制的 API，云租戶可以 獲得敏感性較高的信息。然而這些 API 可以幫助云租戶檢測到未經授權的訪問行為，因此 API 的開放是必要的。

Grafeas 開源計劃

Grafeas（希臘語中的“scribe”）是由 Google 發起，聯合包括 Redhat、IBM 在內的多家企業共同發布的開源計 劃。Grafeas 是一個開源工件元數據 API（如圖19 所示），它提供了一種統一的方式來審計和管理軟件供應鏈。Grafeas 定義了一個 API 規范，用于管理軟件資源，例如容器鏡像、虛擬機鏡像、JAR 文件和腳本。組織可以使用 Grafeas 來定義和聚合有關項目組件的信息。Grafeas 為組織提供了一個中央事實來源，用于在不斷增長的軟件開 發團隊和管道中跟蹤和執行策略。構建工具、審計工具和合規性工具都可以使用 Grafeas API 來存儲和檢索有關各 種軟件組件的綜合數據。

圖 19 Grafeas 開源計劃原理

同時，作為 Grafeas 的一部分，Google 推出了 Kritis，其是一種 Kubernetes 策略引擎，通過在部署前對容器鏡像 進行簽名驗證，可以確保只部署經過可信授權方進行過簽名的容器鏡像，降低在環境中運行意外或惡意代碼的風險。 

Grafeas 為組織成功管理其軟件供應鏈所需的關鍵元數據提供了一個集中的、結構化的知識庫。它反映了 Google 在數百萬個版本和數十億個容器中構建內部安全和治理解決方案所積累的最佳實踐，包括： 

● 使用不可變的基礎設施來建立針對持續性高級威脅的預防性安全態勢； 

● 基于全面的組件元數據和安全證明，在軟件供應鏈中建立安全控制，以保護生產部署；

● 保持系統的靈活性，并確保圍繞通用規范和開源軟件的開發人員工具的互操作性。

Grafeas 旨在幫助組織在現代軟件開發環境中應用上述提到的最佳實踐，實現以下功能和設計要點： 

● 全面覆蓋：Grafeas 根據軟件組件的唯一標識符存儲結構化元數據，因此組織無需將其與組件的注冊表放在一起， 它可以存儲來自不同儲存庫組件的元數據； 

● 混合云適配性：組織可以使用 Grafeas API 作為中央通用元數據存儲； 

● 可插入：Grafeas 可輕松添加新的元數據； 

● 結構化：針對常見的元數據類型的結構化元數據模式，讓組織可以添加新的元數據類型，并且依賴于 Grafeas 工 具可以管理這些新數據； 

● 訪問控制：Grafeas 允許組織控制多個元數據的訪問； 

● 查詢能力：使用 Grafeas 的組織可以輕松查詢所有組件的元數據，不必解析每個組件的單一報告。 

在軟件供應鏈的每個階段，不同的工具會生成有關各種軟件組件的元數據，示例包括開發人員的身份、代碼、何時 簽入和構建、檢測到哪些漏洞、哪些測試通過或失敗等，然后 Grafeas 會捕獲此元數據。  

報告下載地址：https://www.dsocon.cn/#/down