SBOM: 過度炒作的概念并不能保護供應鏈安全

了解SBOM

SBOM就像是商店里食物包裝背面的營養成分清單一樣，記錄著該商品包含的所有成分。盡管目前官方還未出臺SBOM的統一標準，但一些非官方的格式標準已經成為了最佳的候選格式。迄今為止，市面上最受歡迎的標準是由Linux基金會贊助的軟件數據包交換標準(SPDX)。

同大多數格式一樣，SPDX試圖提供一種通用的方法，來表示軟件生產中有關成分的基本信息，包括：名稱、版本、哈希、軟件生態、已知漏洞和許可證信息等輔助性數據以及相關的外部資產。然而，軟件并不像食品那樣簡單，也沒有像美國食品藥物管理局那樣的機構來強制執行一些推薦指南。

所有東西都是可選的，因此不需要任何東西

SPDX與其他標準之間最大且最明顯的差異之一就是，它同整個開源生態系統一樣，不是經過驗證的標準，而是一套建立在通用指導方針之上的社區di。開源社區的范圍十分廣闊，其成員遍及世界各地。通常情況下，包管理器和托管環境都是由不同的委員會來設定，且這些委員會都是獨立運營的。盡管SBOM的標準代表了將眾多信息庫統一起來的早期嘗試，但是它們受到了追溯應用標準的一些基本限制。

首先，當我們思考到“SPDX實際提供了什么”時，差異就開始逐漸顯現了。事實證明，在該標準中，幾乎每個字段都是可選的。然而，這種字段的可選性顯然是在試圖消除不同軟件生態系統之間差異。如果沒有加密哈希或其他信息來幫助我們將庫與SBOM文檔所提供的信息進行主動聯系的話，那么作為真相來源的SBOM就失去它的本質作用。

SBOMs 未能實現“來源”功能

除了不完整這一特點之外，許多輸入的內容也無法以當前的格式正確表示，尤其是來自類似與版本控制系統存儲庫等地方的輸入。雖然像SLSA這樣的新興框架正在嘗試著應用“來源”的概念，然而目前并沒有任何一種格式可以成功做到這一點。我們必須將準確的來源數據集成到SBOM格式中，以確保我們能夠對自己所使用軟件的內部構成有一個清晰的了解。至少也應該了解以下內容：

● 作者身份信息: 無論是維護者，還是創作者，兩者都是供應鏈的重要組成部分。它們掌握著進入“王國”的鑰匙，并決定著我們在下游所使用的軟件會如何發布。即使不能獲取完整的數據，但至少我們絕對會做得比現在更好。

●?開發工具: 這包括構建工具、CI/CD基礎設施以及在上游的軟件開發過程中所使用的工具。想象一下，如果組織使用的庫所攜帶的漏洞會被引入到組織內部的話，那么單純地保護內部開發基礎設施又有什么用呢?

●?控制和保護: 如果要進行第三方風險管理，那么我們必須要搞清楚幾個問題：開發團隊的安全態勢是什么樣子的?是否使用了分支機構保護裝置?以及采用了什么樣的審查流程?

●?工件證明: 對于SBOM文檔中的每一個條目，都必須要有一個與之進行綁定的實際工件。這應該包括一個實際的構建工件，以及一個持續開發的工件，例如版本控制系統中的標記分支。

實際上，在考慮SBOM的操作方式之前，我們還必須要對上述的每一個元素都有一定的了解，這樣才能更好地理解我們正在使用的軟件中的內容構成。

我們不能依賴簡單的快照

最后，SBOM普及過程中的最大挑戰就是，靜態格式的SBOM只能提供軟件當時的情況相關信息，而無法時刻更新即時的相關內容。為了使數據更加有意義，SBOM必須具有連續交付和訪問的能力。

如果一個企業將從云存儲提供商那里接收到一個供應商SBOM。那么該SBOM文檔中不僅會包含著成千上萬的關于軟件的片段，而且還會記錄著這些軟件包的多個版本。并且，由于大型企業每天都要發布數百甚至數千個版本，所以當該企業收到這些信息時，它很可能就已經過時了。也就是說，當你為任何一個大型企業創建出SBOM的時候，這些數據就已經了失去效用價值。

版本的迭代總是伴隨著一些包的新增以及另一些包的刪除。現代開發的最佳實踐意味著軟件的構建和交付是持續進行的，這也將會導致版本迭代的加快，以及發布周期的縮短。而這同時也意味著對于SBOM的交付幾乎是毫無意義的。所以說，為了使SBOM發揮其真正的價值，那么圍繞著SBOM的可擴展自動化就顯得十分有必要的了。

SBOM背后最主要的目的只是提高軟件內容和外部的可見性。所以，不要誤以為它們會保護你的軟件供應鏈。而我們需要僅僅是一個能夠真正發揮作用的部分及時的信息而已。

來源：數世咨詢