莫被軟件物料清單（SBOM）一葉障目

很多安全從業人員都在權衡軟件物料清單（SBOM）可能給軟件質量和安全帶來何種好處。了解和評估軟件風險需要SBOM，因為安全人員應能通過SBOM了解給定軟件系統的軟件構建過程。在某種程度上，某些產品和軟件系統已經包含了SBOM；然而，按照美國第14028號行政令《改善國家網絡安全》的明確要求，以及美國管理與預算辦公室、國家標準與技術研究所（NIST）和網絡安全與基礎設施安全局 （CISA）最近的聯邦指導意見，將SBOM應用到軟件質量與安全的評估上，卻還是相當新鮮的操作，并未經過廣泛驗證。

從未通過的羅伊斯法案

大約在2013年，SBOM立法H.R.5793——《網絡供應鏈管理與透明度法案》（通稱“羅伊斯法案”）被提出，但從未得到足夠的推動力作為強制命令、法案或要求而獲得通過。當時業界沒興趣通過要求透明度來管理軟件供應鏈風險。

《國會記錄——評論擴展》中概述了這項立法要解決的問題。有鑒于現代軟件開發的極端復雜性和不斷增長的規模，以及開源軟件攻擊日趨嚴重的形勢，這些問題如今已然加劇。隨著現代軟件開發中開源軟件消費率的不斷提升，若想更好地管控軟件風險，消費者就必須警惕開源軟件項目中日漸積累的技術債務。軟件復雜性提高、軟件系統規模增大，以及技術債務不斷累積，對政府想要通過軟件供應鏈追求軟件完整性和可靠性的愿望來說可不是什么好兆頭。

“羅伊斯法案”未獲通過的事實可以看做是錯失了解決當時不斷增長的軟件安全威脅與風險的機會。十年后的今天，安全界仍在苦苦追尋恰到好處的SBOM實現方式，希望SBOM既有用，又不會淪為遭對手利用的目標。考慮到當下對聯邦指南中概述的要求的疑慮，業界難免擔憂SBOM是否已準備就緒。

SBOM必須提示未知風險

SBOM面臨的挑戰之一是了解如何確定風險軟件并加以推進。用“風險”這個詞是因為所有軟件都有漏洞，而SBOM必須能夠區分軟件組件的風險級別或提供與之相關的上下文，無論組件是獨立的還是已經集成到了軟件系統中。簡單粗暴地認為軟件組件存在相關通用漏洞與暴露（CVE）就不能用是毫無意義的，因為所有軟件都可能存在漏洞。考慮到軟件實現和使用的上下文——組件功能（登錄、加密、訪問控制、授權）、運行環境，以及是否能夠加以強化來減少特定攻擊面，SBOM必須能夠簡潔明了地確定哪些CVE是最危險和可利用的。軟件組件集成到系統的方式很重要，因為軟件組件可能實現得很糟糕或者壓根兒就不正確，導致暴露出軟件系統中的漏洞。

用CVE建立起開源軟件消費的安全基準很合理；然而，統計一堆CVE來確定哪些軟件風險較小或較高，卻只會將視線綁定到“已知的已知”（我們知道并能理解的事物，如下圖所示）上，幾乎無法幫助企業了解潛在哪些弱點可能會暴露漏洞并（在一段時間里）影響該軟件組件的整體安全。此外，SBOM相關實踐的當前狀態也不會激勵軟件供應鏈商去了解軟件的缺陷傾向或攻擊傾向率。這一點很重要，因為一些軟件組件由于固有的技術債務、低代碼質量和可能暴露漏洞的安全問題而經常遭到攻擊，需要大量修復。修復量大就意味著開發人員和工程團隊沒多少時間用在為客戶創建和交付新功能上。

缺陷傾向是指軟件產品發布后其中組件出現缺陷的可能性。各種各樣的社會技術因素都會導致諸如低代碼質量和設計缺陷等缺陷傾向。攻擊傾向指的是軟件組件遭到成功漏洞利用的比率，或者軟件組件含有可利用弱點（錯誤、缺陷或瑕疵）或漏洞的概率。

SBOM解決方案必須能夠讓企業了解給定軟件組件的潛在風險（如上圖所示），幫助企業在選用和規避哪些軟件組件方面做出明智的決定。舉個例子，美國國家安全局（NSA）網絡安全信息表中就有建議勸告開發人員規避用C和C++開發的軟件，因為這兩種編程語言不會執行良好的內存管理檢查。這條建議將會如何影響軟件供應鏈，尤其是嵌入式安全關鍵系統，以及供應商會不會轉向Rust和Go等內存安全的編程語言，我們拭目以待。

深入探索

SBOM不會消失，我們有必要攜手共同改善軟件安全。這就可能需要開發出一系列工具和標準來豐富SBOM，提供對軟件特性更深入的分析和洞察，幫助了解軟件風險。企業可藉此有效評估和驗證軟件完整性及其他軟件保障屬性。最后，考慮到及時修復軟件漏洞的行業挑戰，軟件供應鏈商不僅要了解給定軟件組件的相關風險，還需要知曉在一段時間內使用該軟件組件的相關維護措施。使用缺陷傾向和攻擊傾向率能夠提供可行情報，幫助降低風險軟件的使用，指導軟件供應鏈商構建更能抵御網絡攻擊的軟件系統。 

理論上，應規避具有高缺陷傾向和攻擊傾向率的軟件組件，從而刺激和鼓勵使用安全性更好的替代品。SBOM并不能直接提升代碼質量和安全性，但可以使軟件供應鏈商更加了解軟件構建過程中的風險。鑒于眾人糾錯并不能讓所有漏洞都浮出水面，提高開源軟件的代碼質量和安全性尚需文化轉變。