SBOM：軟件供應鏈的未來還是幻影？

距離軟件物料清單（SBOM）要求發布已經過去了兩年時間，但業界還遠未達到這一要求。SBOM到底是能夠實現的夢想，還是虛無縹緲的幻想呢？

美國總統拜登于2021年5月發布的網絡安全行政令引入了強制軟件物料清單（SBOM）的概念。其意圖總結起來非常簡單：提供對新軟件所用組件的透明度和可見性，以此提升軟件供應鏈安全。

18個月后的2022年12月，代表亞馬遜、蘋果、思科、谷歌、IBM、英特爾、萬事達、Meta、微軟、三星、西門子、威瑞信（Verisign）等科技巨頭的游說團體聯系美國行政管理和預算局（OMB）：“我們請求OMB阻止各機構要求提供[SBOM]，除非已深入了解應如何提供這些清單，且機構已準備好使用提交的清單。”

如果過了18個月還在原地踏步，沒發揮出SBOM的功效，那就得問問還需要做些什么才能實現拜登的網絡安全行政令了。

SBOM的作用

SBOM旨在提供對應用隱藏區域的可見性，從而提高軟件供應鏈的安全性，SBOM詳細呈現應用中用到的每個代碼組件。美國網絡安全公司Tanium安全總監Matt Psencik解釋稱：“SBOM構建的列表包含了每個應用程序使用到的所有包和共享庫，還有它們的版本號。”

“如果某個包里混進了漏洞，你可以更新、刪除那個包，或者聯系供應商問問有沒有新補丁可以修復漏洞。”他補充道。

SBOM旨在提供應用所含每個代碼組件的詳細信息，無論是商業軟件組件、開源軟件（OSS）庫和依賴項，還是什么內部開發的庫。Tigera安全工程經理Anthony Tam表示：“可以使用這一信息來確定安全修復和更新的優先級，跟蹤和管理漏洞，以及監測相關規定和標準的合規情況。”

SBOM通常可以類比為食品的成分表。知道成分，購買者才能檢查消費該產品是否涉及什么風險。但相比食品成分表，SBOM要深入得多，提供的數據更多更詳細。

盡管列出了所有來源的每個組件，但軟件供應鏈的首要目標和最大問題是開源軟件。開源軟件也是SBOM項目的最大問題和阻礙。

開源軟件問題

開源軟件遍布各處，任何新應用似乎都無可避免地要用到開源軟件組件，開源軟件就在那里，隨時隨地免費取用，可以幫助開發人員加快其新應用的開發速度。

問題在于，開源軟件實在是太多了，往往由個人或小型協作團隊開發（通常都沒報酬），而且每個開源軟件庫往往都進一步依賴其他庫或組件，其他庫或組件又有自己的依賴項。在自由市場對速度經濟的需求下，期望應用開發人員知道自己的應用用到了哪些依賴項，或者知道其應用使用或未使用某個開源軟件庫的哪些部分是不可能的。

看看下面這些數字。GitHub 2022年Octoverse報告表明，2022年GitHub上有5200萬個新的開源項目，GitHub開發者全年對開源項目做出了4.13億次貢獻。SourceForge托管著50萬個開源軟件項目，Apache則托管著另外350個。此外還有別的開源軟件源。 

這些開源項目的開發人員大多是程序員而非安全專業人士。理論上，這些代碼的開放性質就給第三方研究人員留下了檢查代碼找出缺陷、漏洞和惡意軟件的空間。但很遺憾，這相同的開放性也讓攻擊者能夠找到這些漏洞，有時候還能插入他們自己的惡意軟件。

SBOM旨在讓商業軟件應用開發人員、應用購買者和用戶更能看到這些開源軟件問題。但開源軟件市場的巨大規模導致了諸多困難。這也是SBOM項目進展緩慢的主要原因。

SBOM現狀

SBOM發展進程中的一個明顯問題是，既沒有明確規定SBOM應該提供什么、以何種格式提供，也沒有具體說明應如何解釋和使用SBOM。類似規范就是美國國家電信和信息管理局（NTIA）于2021年7月發布的《軟件物料清單最小必要元素》了。但正如該文檔所斷言的，“SBOM的最小必要元素只是個起點，聯邦政府應鼓勵或開發關于如何實現SBOM的資源。”

美國網絡安全與基礎設施安全局（CISA）是SBOM項目的焦點，將其作用描述為“促進社區參與、發展和進步，重在擴展 和可操作化，以及工具、新技術和新用例。”

2023年4月，CISA發布了三份SBOM相關文檔。第一份題為《共享生命周期報告》，展示了SBOM如何從編制者流向消費者，以及SBOM如何在此過程中充實產品。

但該文檔并沒有指明應怎樣創建SBOM和如何共享SBOM，也沒有說明應如何解釋SBOM。

另外兩份在4月份發布的文檔題為《軟件物料清單（SBOM）文件類型》和《漏洞可利用性數據交換（VEX）最低要求》。“類型”文檔列出了六種不同SBOM類型及其優勢與限制。該文檔結語寫道，“這些定義僅作為起點……”

“VEX”文檔（VEX概念是在NTIA最低要求文檔中提出的）中寫道，“本文檔規定了創建VEX文檔所需的最少元素。如第4.1節所述，這些元素源自現有VEX文檔和實現，但可能不完全符合。本文檔也規定了一些可選VEX元素。”

這些文檔中列出了軟件作者可以在SBOM生產和消費中使用的一些選項，但并未說明作者應該或必須做什么。或許這種缺乏指導和允許市場力量表述和解決問題的情況才是SBOM項目當前最大的阻礙。

不同安全供應商開發不同產品幫助自動化這一過程：首先要能夠生成SBOM，然后要能夠接收、處理和修復，通過SBOM找出或凸顯的任何問題。自動化是這類項目的基礎，但隨意的自動化不能解決問題。

Phylum聯合創始人兼首席安全官Pete Morgan解釋了這個問題。“我在家弄了個小型測試實驗室，有六到七種工具可以用來分析代碼并生成SBOM。然后，我還有五到六種其他工具可以接收生成的SBOM，嘗試解釋這些SBOM并做點什么。我用相同的代碼庫進行測試，每種工具都產生了不一樣的SBOM，而且無一能被其他工具解釋。”

VEX

盡管嚴格意義上不是SBOM本身的一部分，但VEX文檔是SBOM項目的重要一環。SBOM可幫助購買者了解所用軟件中存在的漏洞。但這些漏洞必須為人所知，通過軟件開發人員（或者別的渠道）提供的VEX通知他們。

該流程的基礎是開源軟件開發人員，而這就是個問題。從技術上講，開源軟件開發人員必須將代碼中發現的任何漏洞告知用戶。Morgan是這么描述這個問題的：“這些開發人員是幾乎所有軟件產品的基礎，但他們沒有高級產品安全團隊支持。期待他們向我們提供關于自身代碼的準確漏洞信息是有點癡心妄想了。這跟讓盲人觀察員告訴我們有沒有人過來沒什么兩樣。”

盡管如此，VEX（以及正在研討的其他幾個擴展）也是“有意思的想法，只是我們現在缺乏有效使用的流程或對流程的了解。”

WithSecure高級威脅情報分析師Stephen Robinson認為，維護SBOM和VEX文檔是關鍵。“更新SBOM并向消費者傳達這些更新是一個關鍵問題。安全形勢隨著CVE被發現和補丁的發布而不斷變動，SBOM也會隨之變更。”

美國國家網絡安全戰略

SBOM項目的價值和問題都根植于開源軟件這一無定形的存在。期望單個開發人員和合作小組能夠及時準確地生成SBOM文檔根本就是不現實的。 

2023年3月1日發布的《國家網絡安全戰略》戰略目標3.3談到了將安全責任從用戶身上轉移到軟件開發商身上。具體講，“責任必須放在最有能力采取措施防止不良結果的利益相關者身上，而不是通常要承擔不安全軟件后果的最終用戶身上，也不是組件的開源開發者身上……”。

這么做可以將SBOM和VEX文檔的責任集中在出品商業軟件的供應商公司身上，而不是開源軟件庫的開發者身上。但問題在于，沒有具體的指南或指示說明該如何實現這一目標。缺乏這類指南，急于向市場推出新產品的中小企業或初創公司就很容易漏掉隱藏在其所用開源軟件庫子依賴項中的漏洞。

Psencik評論道：“只有在積極跟進軟件包漏洞相關情報源搜索漏洞，并在發現帶漏洞軟件包時切實進行修復的情況下，SBOM對企業而言才有價值。當前的大多數SBOM都是給你提供更多信息的一種工具，但如果不根據這些信息采取行動，那SBOM也不過是安全團隊工具箱中的又一款積灰工具。”

還需要做些什么？

SBOM項目進展緩慢不假，待解決的問題很多也是真的，但幾乎沒有哪個網絡安全專家會質疑這個項目。業界普遍認為，這是軟件供應鏈安全的重要發展，一旦實施，將惠及所有人。

Viakoo首席執行官Bud Broomhead評論道：“加強使用和標準化可以改善SBOM的現狀，尤其是在為企業提供經驗證的SBOM自動化使用方法來改善安全方面。”

其中存在的主要問題可能更多是政治性的，而非組織性的。根據《國家網絡安全戰略》，美國當局將尋求“塑造市場力量”，并“通過聯邦購買力和撥款”來實現這一目標。但對所有網絡安全供應商強制執行聯邦要求是不可行的。

這就變成了聯邦政府能否切實塑造市場力量的問題。Morgan警告道：“事實上，如果只是讓市場自行調節，我認為我們永遠實現不了這一目標。我確實覺得監管不可或缺。”但政府只能監管聯邦機構的采購。銷售領域不包含聯邦市場的小型軟件開發商就可以無視此類監管。

Morgan指出，某些行業，比如高度安全敏感的關鍵行業，已經有了嚴格的軟件安全控制機制。“但對于參與市場力量的其他軟件產品來說，速度就是驅動力：我們能以多快的速度推出產品？我添加新功能的速度有多快？多快能發布出來？涉及到了解這些組件的相互關聯深度并加以記錄和更新的時候，這就很成問題了。所以，我確實認為監管很有必要。”

Teleport安全副總裁Reed Loden提出了兩點具體建議。“首先，要求通用CI/CD方法默認生成SBOM；其次，要求在一些合規或法律義務中納入SBOM。基本上，你要么需要讓SBOM成為毫不費力就能提供的‘一鍵生成’產物，要么明確要求SBOM落地（這會觸發實現第一點建議，因為大家會希望能默認生成）。”

Jscrambler聯合創始人兼首席技術官Pedro Fortuna給出了一個解決辦法。他說：“想要盡可能地提升SBOM的有效率，就必須解決兩個問題。首先，必須及時更新SBOM并推送給消費者。這一點可以通過獨立第三方運行時監測解決方案實現（不需要軟件作者配合），這種解決方案能夠持續動態識別所有軟件組件。” 

其次是必須驗證供應鏈完整性。該運行時監測解決方案應驗證所有子組件的完整性未受損，而且其中未運行任何惡意代碼。此處的問題在于，如果監測解決方案是由獨立第三方開發的，那就可能會有很多種，且Morgan提出的SBOM不一致的問題會繼續存在。但如果解決方案是由CISA開發或其委托開發的，那就是強制性的，且不參與‘塑造市場力量’。

Endor Labs聯合創始人兼首席執行官Varun Badhwar認為，某種形式的更為激進的指導對于打破困境僵局是必要的。他表示：“我希望看到CISA提供更多的監管指導，因為他們可以與其他監管機構合作制定并發布指導方針，鼓勵或要求在特定行業使用SBOM，例如關鍵基礎設施、政府合約和軟件采購流程。” 

“CISA還可以倡導財政激勵措施，鼓勵各企業采取SBOM實踐，比如為投資實現SBOM的公司提供稅收減免、補助或其他形式的財政支持。CISA可以采取類似開源安全基金會（OpenSSF）的做法，與構建SBOM技術的供應商合作，從而彰顯最佳實踐，為企業廣泛采用SBOM做好準備。”

建立行業聯盟來促成SBOM解決方案一致性確實可以平衡強制監管和市場力量。這里面唯一的弊端在于，委員會在培育賽馬時往往會搞出一匹駱駝。

終極夢想

批評CISA明顯沒有強力推進SBOM可能有失偏頗。該機構之前可是很有耐心地在把一個好主意打造成一項有價值的服務。想想KEV（已知被利用漏洞）列表。在早期的時候這東西可沒什么明顯價值。但KEV一直在增長，現在常被用作現成的漏洞分類源——如果漏洞出現在KEV列表中，你會自動知道應該緊急加以修復。

SBOM項目也在緩慢推進。只是我們不清楚這是因為CISA是在黑暗中摸索，還是因為這就是預想計劃的一部分。不過，即使實現了SBOM，也很可能無法完全解決問題。JupiterOne代理首席信息安全官Guillaume Ross評論道：“我覺得，提高透明度終歸是件好事。但供應鏈安全領域沒有萬能藥，網絡安全領域的任何一部分都沒有。”

所以，回到我們最初的問題，我們可能未來十年內都不知道SBOM是會成功還是仍舊是個幻想。我們所知道的是，在此期間需要投入大量工作。