從主流安全開發框架看軟件供應鏈安全保障的落地
從SolarWinds攻擊到Log4j漏洞，再到近期以反戰名義對開源軟件供應鏈投毒事件，軟件供應鏈安全問題愈演愈烈，因其帶來的巨大危害引發全球關注。尋求有效、可落地的保障方法成為軟件供應鏈相關各方的共同目標。
安全開發框架作為軟件開發生命周期中各階段安全實踐、活動和措施的集合，能夠指導使用者提高軟件生產和產品的安全性，并且它們越來越多的將供應鏈因素考慮在內，形成一個不斷完善的保障體系。
本文通過對六種主流安全開發框架的最新版本進行分析，總結了共性和差異，歸納了供應鏈安全保障的主要環節，提出了操作指南細化的初步思路。
六種框架包括安全軟件開發框架(NIST SSDF) V1.1、軟件聯盟安全軟件框架(BSAFSS) V1.1、SAFECode安全軟件開發基本實踐 V3、軟件保障成熟度模型(OWASP SAMM) V2.0、安全內建成熟度模型(BSIMM) V12和微軟安全開發生命周期(MSSDL) 2022。
一、六種主流安全開發框架的異同點
六種主流安全開發框架面向開發組織，以軟件的風險管控和漏洞防控為目標，以軟件開發生命周期為主線。框架均采用多級分類的形式：即首先劃分為大類，然后逐級細化，名稱不同，但最終都細化為具體的安全要求或措施，以指導使用者。
六種框架的最新版均較多涉及軟件供應鏈安全方面的內容，如第三方組件/開源組件的安全管控、對供應商的安全要求、開發工具和環境的安全防范、構建部署環境的安全防護、第三方組件漏洞響應等；SSDF V1.1作為應美行政令要求而出臺的高層級實踐框架，參考了其他5個框架的內容。
各框架之間也存在著較大的差異，主要差異如表1所示。
二、軟件供應鏈安全保障的主要環節
通過對各框架具體內容的分析可以發現，除了自主研發軟件代碼和產品的安全措施外，軟件供應鏈安全保障實踐主要涉及4個環節。
1、第三方組件的安全管控
作為最終軟件產品的重要組成部分，商業、開源和其他第三方來源組件等“外來原料”的安全性是軟件供應鏈安全保障首先要考慮的問題，六種安全開發框架也都將針對第三方/開源組件的保護作為重點。
SAFECode安全軟件開發基本實踐將第三方組件安全風險管理(TPC)作為單獨一部分進行系統描述。TPC管理共有4個步驟：TPC列表維護、評估來自TPC的安全風險、緩解或接受風險、監控變化，每個步驟又包含若干具體措施，如圖1所示。
其他幾種框架關于第三方組件的安全要求也符合圖1模型中的步驟，只是對某些方面的措施進行了細化，例如：
- 第三方組件列表維護方面
框架考慮了來源信息和依賴關系的記錄與分析(SSDF PW.4.1、BSAFSS SM.2-2/SM.2-3、SAMM SB1/SB2/SB3、BSIMM SR2.4/SE3.6)，以及第三方組件的獲取、批準、符合性、保存和維護(SSDF PW.4.1/PW.4.4、SAMM SA3、MSSDL開源軟件風險管理實踐1)等要求；
- 風險評估方面
框架考慮了第三方組件的安全漏洞檢測及發現(SSDF PW4.4/PW.7.1/ PW.8.1/RV.1.1、BSAFSS VM.1-3、SAMM ST1、BSIMM CR1.2、MSSDL開源軟件風險管理實踐2)、安全性評估(BSIMM SFD2.1)、使用復雜性評估(SAMM SA2)等實踐；
- 風險緩解方面
框架考慮了第三方組件漏洞的公開和修復(SSDF RV.1.3、BSAFSS VM.1-3/VM.3)、打補丁(BSAFSS VN.1、SAMM EM1)、控制開源風險(BSIMM SR3.1、MSSDL開源軟件風險管理實踐3和4)等措施；
- 在生命周期監管方面
框架考慮了監控第三方組件的生命終止(BSAFSS EL.1-3)、定期替換已終止的第三方應用及依賴關系(SAMM OM2)等內容。
小結：所有框架對第三方/開源組件的維護、風險評估和緩解(特別是安全漏洞的檢測和修復)都有詳細的措施；除SSDF和BSIMM外也都提到了對組件生命周期變化的監控。它們都把第三方/開源組件的風險管控放在重要位置，而且已具備系統性的管控措施。
2、針對供應商的安全要求
如果說第三方組件是供應鏈中重要的原材料，軟件供應商無疑就是其中最主要的主觀因素。提高供應商的安全意識、能力，對其進行必要的安全要求，也是供應鏈安全中不可或缺的一環。
安全開發框架中對供應商的安全要求主要包括對供應商進行評估并簽署安全協議、要求供應商使用一致的安全方法并對其進行培訓、明確供應商的安全事件響應責任等5個方面，詳細如表2所示。
小結：多個框架都要求對供應商進行評估和簽署安全協議；BSIMM對供應商的要求最為全面，涉及所有5個方面；上述這些對供應商的要求貫穿于軟件開發生命周期的全過程，在安全層面將供應商與組織捆綁在一起。
3、軟件基礎設施的安全性
軟件產品的基礎設施包括開發、構建、部署、運維等過程中所使用的工具和環境等，這些設施一般由第三方提供，近年來發生的供應鏈攻擊事件也多與其相關，如Codecov供應鏈攻擊事件，因此它們的安全性也成為目前關注的焦點。6種安全開發框架對各階段基礎設施的安全性也有較為詳細的要求：
- 開發工具和環境的安全性方面
框架考慮了開發環境的隔離、開發終端的加固(SSDF PO.5.1/PO.5.2)；內部代碼庫和加密服務密鑰保護、最新版開發工具的使用、開發框架的安全配置、開發環境訪問的強身份認證(BSAFSS DE.1-2/DE.1-3/DE.2-1/DE.2-2/IA.1-1)；開發環境安全質量評估、SDK之類的庫和組件及系統的安全性評估(SAMM SA1/AA1)等措施。
- 安全構建方面
框架考慮了使用最新版本和批準的編譯器等構建工具(SSDF PW.6.1/PW.6.2、SAFECode實踐、MSSDL實踐8)、對構建工具進行檢查驗證及強制執行安全基線(SSDF PW.6.1、SAMM SB1/SB3)、選擇適當的編譯特性并進行安全配置(SSDF PW.6.2、BSAFSS DE.2-3/DE.2-4/DE.2-5)、構建過程的自動化(SAMM SB2)等措施。
- 部署和運維環境的安全性方面
框架考慮了容器和虛擬化環境的使用編排及部署自動化(BSAFSS DE.2-6、SAMM SD2、BSIMM SE2.7)、部署的安全檢查和安全配置(BSAFSS DE.2-6、SAMM SD2、BSIMM AA1.1/ SE2.2)、確保安裝在正確硬件和授權用戶的機制(BSAFSS SM.6-1)、可部署工件風險數據的發布(BSIMM CMVM3.6)、主機網絡及云安全能力保障(BSIMM SE1.2/SE2.6)、基礎運維設施安全的驗證(BSIMM CMVM3.5)等措施。
小結：BSAFSS和SAMM在3個方面均有涉及；SSDF更關注開發和編譯環境的安全；BSIMM在部署和運維環境安全方面的實踐更多一些，特別是運維；SAFECode和MSSDL主要對安全構建進行了要求。雖然各有側重，但所有框架都有對基礎設施安全保護的要求，并且相信后續版本中此類措施會越來越多。
4、軟件自身安全性的保護
軟件（包括補丁）的偽造和篡改同樣是供應鏈攻擊的主要手段之一。軟件完整性保護就是通過驗證軟件來源、授權、完整性等信息的一致性來防止此類問題的機制，代碼簽名和來源信息驗證是其中最為主要的方法；此外，補丁的安全性也是軟件自身保護的重要部分。框架的相關措施包括：
- 軟件完整性保護方面
措施包括建立代碼簽名和第三方工件簽名之類的軟件完整性保障機制(SSDF PS.2.1/ PS.3.1、BSAFSS SM.4-1、SAMM SD3、BSIMM SE2.4/SE3.2)、軟件來源數據的收集維護及驗證(SSDF PS.3.1/PS.3.2、BSAFSS SM.4-2、BSIMM SE2.4)、每個交付產品特定軟件版本的唯一標識(BSAFSS SM.4-3)等。
- 補丁安全性防護方面
措施包括對補丁進行功能和安全測試(BSAFSS VN.1-3)、通過可信和自動化渠道交付補丁(SSDF RV2.2、BSAFSS VN.2-1)、對補丁進行簽名以確保其完整性(BSAFSS VN.2-2)、追蹤打補丁流程對SLA的合規情況(SAMM EM3)等。
小結：多數框架對軟件完整性保護進行了要求，并遵循主流的防篡改方法；在補丁安全性防護方面，BSAFSS從測試、傳輸、防篡改等角度進行了要求，最為全面。
三、安全開發框架主要指導作用思考
安全開發框架以軟件開發生命周期為主線，基于組織和企業的實踐和操作經驗，并將供應鏈相關的安全措施納入，目前各類安全開發框架的內容也較為豐富，對軟件供應鏈安全保障工作具有一定的指導作用，主要體現在以下兩點：
一是在直接使用方面，鑒于框架不同的編制背景，軟件供應鏈安全決策和策略制定等相關人員可更多的參考結果導向框架的內容，關注目標和效果，并結合自身的實際情況，從中選取適當的實踐作為策略制定和實施的基礎；具體安全實施等人員可較多的參考過程導向的框架，關注實現的技術和方法，并結合自身情況選擇性實施。
二是在進一步細化后使用方面，由于各框架的許多內容之間存在著對應關系，因此未來可考慮將結果導向和過程導向的兩類框架結合起來，選取便于落地的實踐，并進一步細化每項實踐對應的具體操作、技術、機制和工具等內容，形成覆蓋“保障結果->過程方法->具體操作->輔助工具”的軟件供應鏈安全保障字典式詳細實施方案，滿足相關各方人員的需求。
