近年來，軟件物料清單 (SBOM) 已成為軟件安全和軟件供應鏈風險管理的關鍵要素。
我們採訪了軟件供應鏈風險戰略負責人 Tim Mackey在 Synopsys 了解有關 SBOM 優勢和挑戰的更多信息。
BN:Log4shell 漏洞導致的關鍵認識是什麼?
TM:Log4Shell 經驗強調開源使用在組織中很普遍。甚至發現商業軟件也有開源組件作為依賴項。這使人們更加關注開源項目是由外部志願者創建和維護的，而不是他們自己的員工或第三方商業供應商。這意味著 IT 部門對商業軟件中開源軟件的使用缺乏任何控制——即使他們對直接下載和使用的開源軟件有成熟的開源管理流程，或者在他們的定制軟件開發工作中使用了開源軟件。
BN:組織需要了解開源的哪些方面，以便更好地準備應對它帶來的獨特挑戰?
TM:第一步是通常只是認識到您正在使用開源，然後您可以從那裡定義一個可行的治理工作流。由於開源團隊不知道誰下載了他們的代碼，因此您沒有更新推送機制；你有一個拉動機制。所以，當一個項目被有效地放棄，或者在它維護的生命週期結束時，我們希望那些維護者去說，“嘿，我完成了這個項目，”並在上面放一個漂亮的小通知說不會有任何新的更新，但這通常不會發生。
現在，能夠識別“已放棄”和“已完成”的項目是一個單獨的問題。如果您沒有參與該項目，則無法做出決定，因此，如果您不知道自己正在使用某個項目，請開始問這些問題。這確實是難題的第一大塊——接受你擁有開源，接受它的管理方式不同，並製定一個包括參與這些項目的流程。
事情變得特別具有挑戰性的地方是，當你說，在依賴關係或供應鏈的三到四個層次上，你可能不一定知道你有開源代碼在運行。這是整個 Log4j 經驗的教訓之一，人們在問題發生之前並不知道有一個叫做 Log4j 的東西。
BN:SBOM 到底是什麼?
TM:從根本上說，SBOM 是一個列出應用程序使用的庫的文件。它是治理計劃的關鍵組成部分，不僅包含軟件供應鏈中的開源使用，而且還成為其他運營元素的錨點。今天討論的最常見的操作元素是使用 SBOM 來傳達給定應用程序的軟件供應鏈中組件內的漏洞暴露情況。
BN:SBOM 本身是否足以緩解開源的安全和許可風險?
TM:沒有。因為 SBOM 出現在行政命令中，所以引起了很多關注，“我需要去擁有一個 SBOM.’出於實際目的，當今許多組織都在創建 SBOM，它只是一份材料清單，上面寫著:“我有這些組件來自這個地方，這是它們的版本。”
它是實際上是靜態的東西。它表示該軟件在交付時的樣子。它在這方面很棒，但它不會告訴您它是否比其他東西更安全或更不安全。它嚴格地告訴您該特定軟件的成分列表是什麼樣的，這就是人們被欺騙的地方。每個人都在談論的 SBOM 並不是這只神奇的獨角獸–它是需要在公司內部實施的工作流的一部分。
SBOM 中的“SB”並不意味著銀彈。
p>
問題是 SBOM 數據需要進入工作流程。 SBOM 接收端的人員可能會說，“在這裡，我得到了這個我不知道如何處理的文件”，這就是工作流——組織需要的一組流程
換句話說，SBOM 提供的知識顯然很有價值，但如果您的組織沒有使用它的流程，那麼擁有 SBOM 和相關漏洞信息的好處微乎其微.缺乏流程是最大的挑戰，因為雖然採購團隊可以向所有供應商索取 SBOM，但如果沒有明確定義的流程來根據 SBOM 中的信息採取行動，那麼所發生的一切就是你已經現在目錄中又多了一個文件。
BN:為了從 SBOM 中獲取價值，一個成功的、定義良好的流程應該是什麼樣的?
TM:所有組織都有一個 IT 部門負責維護該組織內部軟件的補丁。所有軟件都是由組件構建的。我們從 Synopsys OSSRA 報告中得知商業軟件中的開源使用率平均為 78%。因此，您知道將有一些組件是開源的，並且它們將需要更新。如果信息附加到 IT 正在管理的資產，SBOM 會傳達該信息。
現在，當出現新的漏洞披露時，IT 可以去查詢 SBOM 管理系統然後說，“啊哈——我有這個，但我的補丁是從哪裡來的?”補丁來自 SBOM 的出處信息——這就是 SBOM 的作用。這並不是要告訴您您有一個新漏洞——它是一份文檔，準確描述了您嘗試運行的工件中的內容，如果您擁有該工作流程，現在您可以做正確的事情。
BN:SBOM 必須滿足哪些要求?
TM:要發揮作用，SBOM 必須既準確又完整，這是兩個不同的問題，但要解決一個問題，依賴於解決另一個問題。
首先，必須記錄應用程序中打包的所有外部庫，以便完成 SBOM，包括開源軟件、商業第三方庫和通過引入的任何軟件第三方合同。理想情況下，SBOM 將從應用程序的源代碼中提取，儘管這可能是一個困難的過程，具體取決於應用程序構建過程的定義方式。例如，在為兩個不同平台編譯應用程序時，您可能需要兩個不同的 SBOM；一種用於 Windows，一種用於 Linux。
同樣，重要的是準確識別組件，識別從其來源點到版本的所有內容。從應用程序的源代碼中提取的第一方 SBOM 是最準確的，但也有第三方 SBOM。在這種情況下，將掃描應用程序而不是源代碼。這可能會導致一些信息丟失，因為您無法確定庫的精確版本；因此，只有在第一方 SBOM 不可用時或作為對第一方 SBOM 進行雙重檢查的一種方式，才使此方法適用。
BN:您對 SBOM 的未來有何看法解決開源漏洞和整體軟件供應鏈風險?
TM:我們處於 SBOM 時代的早期階段。大多數供應商仍在努力創建 SBOM，並且在可預見的未來還將繼續。然而，雖然供應商能夠提供 SBOM 是開源安全敏銳度的一個指標，但它並不是唯一的指標。重要的是，如果組織向供應商請求 SBOM，但沒有處理該 SBOM 並從中獲取價值的工作流程，那麼讓供應商提供 SBOM 會增加成本而沒有好處。
有趣的是，許多都失敗了請注意，SBOM 的安全用例通常與軟件組合分析 (SCA) 解決方案已經提供的內容保持一致。 SBOM 作為整體風險緩解策略的一部分最為有用。這意味著有適當的流程來衡量通過 SBOM 傳達的風險，然後有一些流程來減輕該風險。
圖片來源:Momius/depositphotos.com