網管人員為了需要清礎識別供應鏈所產生的網路風險並加以控制，SBOM（軟件物料清單）因此而誕生，網管人員輕易地利用 SBOM 執行監管要求，同時又能清礎識別設備中所有的韌體，這就是 SBOM 越來越受歡迎的原因。但是我們需要什麼生成 SBOM ? SBOM 它又必須包括些什麼？以及它又是如何幫助團隊應對快速演變的威脅？如果您能夠瞭解了 SBOM 並使用得當，那麼擁有自動化優勢的 SBOM 對威脅持續監控，不僅可以顯著提高開發效率並能夠縮短設備和產品網路安全認證時程，最後達成縮短上市的時間。
我們網管人員除了監控內部創建的代碼外，當今的產品和設備許多還來自於供應鏈自行取用的開源軟體以及第三方韌體組件的複雜組合。面對這些越來越多非內部開發的韌體，除了一些供應商有披露韌體內容之外，網管人員幾乎無法了解這些設備產品製造商，他們所使用的代碼是否帶有風險。
請先瞭解 SBOM 是什麼
SBOM 最初由美國食品和藥物管理局 (FDA) 於 2018 年提出，作為醫療器械網絡安全管理上市前提交的一部分。他們隨後被稱為網絡安全材料清單 (CBOM)，強調了它們對產品安全的重要性。(FDA) 目標是創建構成設備的所有軟件和硬件組件的列表。經由列表使組織能夠有效地管理其資產並充分了解所用軟件的風險。
供應鏈安全和 SBOM
軟件供應鏈攻擊的威脅使SBOM成為確保供應鏈安全的關鍵部分。
在過去的幾年裡，軟體供應鏈攻擊開始成為頭條新聞。考慮到軟體和供應鏈變得多麼複雜和多層次。今天的連接設備和產品可能依賴於來自多個來源的數十甚至數百個軟體庫：一些是內部開發的，另一些是從第三方供應商處購買的，添加到組合中的是開源項目。
再加上疫情大流行所造成的嚴重供應鏈中斷和中斷，導致關鍵業務供應鏈短缺。供應鏈延誤和故障，促使設備和產品製造商尋找新的和未經認證審查的供應商，這種情況給了供應鏈風險管理增加了新的挑戰。
典型案例：SOLARWINDS 和 LOG4SHELL
2020 年的SolarWinds 供應鏈攻擊深入滲透到聯邦政府的基礎設施和一些最大、最精通技術的組織中，這讓人質疑人們對每天使用並構成產品基礎的軟體和設備究竟了解多少。
另一個發人深省的例子是2021 年底在廣受歡迎且無處不在的Log4j 開源 Java 庫中發現的嚴重漏洞。該漏洞一經披露，就清楚地表明了開源組件中固有的風險，還是我們軟體產品不可或缺的一部分。在其披露後的數小時內，通過該漏洞進行嘗試攻擊的數量驚人，於是這提醒了我們，我們對供應鏈中開源組件的可見性和控制是漏洞管理的重要組成部分。
這一塊如果做得好，當我們允許 SBOM 檢查和監控通過供應鏈收到的組件，我們就可以在威脅和漏洞成為頭條新聞之前對其進行管理。
拜登總統的網路安全行政命令 (EO 14028) 使 SBOM 成為必須
2021 年 5 月，為了應對 SolarWinds 漏洞等供應鏈攻擊威脅的增加，拜登總統發布了一項加強國家安全的行政命令 (EO 14028) 。EO 14028 號召組織和聯邦機構共同努力提高網絡安全。
該行動的一部分是建議軟體開發人員向其客戶提供 SBOM。該軟體材料清單包括有關應用程序使用的庫、附加組件和自定義源代碼的信息。
SBOM 用例
雖然行政命令明確表示監管越來越需要使用 SBOM，但一些組織仍然將監管視為必須忍受的必要之惡，而不是可以增強其安全性和合規性戰略和流程的工具。
從最早的開發階段到後期生產，如果持續使用，SBOM 可以幫助產品安全團隊檢測和降低整個產品生命週期中的風險，。
除了作為監管要求之外，SBOM 還是一種對軟體或數據產品製造商管理軟體供應鏈風險至關重要的做法。SBOM 提供價值的幾個用例。
遵守聯邦要求
在拜登總統發布行政命令後，那些向聯邦政府提供軟體的公司需要提供 SBOM，其中詳細說明了所使用的組件以及版本之間所做的更改。
降低軟體消費者的風險
SBOM 提供對軟體組成的可見性，使組織能夠驗證軟體是否滿足其合規性標準和安全要求並評估風險。這對於醫療保健、關鍵基礎設施供應商/公用事業、汽車和金融等受到嚴格監管的行業尤為重要。
更快地將優質產品推向市場
設備製造商對其產品保持高標準，並且在許多情況下在生產後進行更改的能力有限。SBOM 使他們能夠跟踪上游軟體的變化，以便在生產早期識別和修復新漏洞，此時修復更容易且成本更低。
支持併購
收購新公司時，企業需要在收購前完成盡職調查以調查其投資。此過程的一部分涉及全面評估購買風險。SBOM 提供了對公司在其產品開發中使用的軟體的可見性，從而能夠更準確地評估產品和設備。
滿足 SBOM 要求的第一步：NTIA SBOM 的最低要素
NTIA 制定了最低要求指南，以幫助製造商加入。
2021 年 7 月，在網絡安全 EO 14028 的推動下，經過多年的努力，NTIA（美國國家電信和信息管理局）發布了軟體物料清單 (SBOM) 的最低要素。NTIA 文檔提供了一份詳細列表，列出了 SBOM 必須包含的最少元素，以便軟體開發人員、製造商、購買者和用戶可以獲得更高的透明度，並對他們創建和依賴的複雜且相互關聯的軟體進行控制。
除了提供 SBOM 使用的基本用例（如漏洞管理、軟體清單和許可證）之外，還創建了該文檔以開始就未來的 SBOM 要求和功能進行對話，以用於更廣泛的用例和擴展操作使用。該文件是減少產品和設備的攻擊面以及深化供應商和製造商的對話和標準化流程的重要一步。
NTIA 文件創建了 SBOM 標準化，使公司、供應鏈供應商和客戶能夠設定明確的期望，同時縮短迭代周期。通過列出 SBOM 中預期的明確標準，該文檔的指南有助於在供應鏈參與者之間建立可見性、信任和安全意識。
使用 SBOM 的最低要求元素
NTIA 的最低要求分為三類：數據字段、自動化支持以及實踐和流程。讓我們更深入地了解每一個：
數據字段
由於 SBOM 的目的是提供有關軟體組件的信息，因此第一個必需元素涵蓋應包含有關每個組件的哪些數據是有意義的。此數據還可用於跟踪整個軟體供應鏈中的組件並將它們映射到數據庫。
NTIA 定義了七個基線字段：
- 供應商名稱 – 組件製造商
- Component Name – 供應商確定的單位名稱
- 組件版本 – 由供應商確定的版本號或類別
- 其他唯一標識符 – 額外的唯一數據。NTIA 建議使用這些來支持跨數據用戶和生態系統的映射自動化工作。例如，通用平台枚舉 (CPE)、軟體標識 (SWID) 標籤和包統一資源定位器 (PURL)
- 依賴關係 – 組件與其他軟體的上游關係
- SBOM 數據的作者 – 創建 SBOM 數據的實體（不是軟體創建者）
- 時間戳 – 組裝 SBOM 數據的時間
自動化支持
NTIA 還鼓勵跨部門和組織使用 SBOM 數據，以實現透明度、增強安全性、滿足合規性標準等。為了實現這一點，SBOM 必須是機器可讀的，因此這些流程可以自動化。
不幸的是，沒有一種 SBOM 格式，但 SBOM 社區使用的各種數據格式已經變得非常普遍。NTIA 支持它們並要求 SBOM 至少符合以下一項：
- 軟體包數據交換 (SPDX)
- 氣旋DX
- 軟體標識 (SWID) 標籤
從上游提供商獲取數據給使用 SBOM 的人帶來了挑戰。這需要為每種格式創建獨特的流程，以在一個位置規範化和合併數據。
對於提供商而言，格式化對於提供一致性至關重要。一旦選擇了一種格式，就應該遵守它，因為更新對消費者來說是一種負擔。這可能需要他們更改攝取過程以適應更新。
實踐和流程
- 最後，NTIA 承認，既定的組織文化和流程對於確保所有團隊的整合至關重要。為了提供幫助，它定義了組織應遵循的以下準則：
- 頻率 – 必須為每個新產品或設備版本創建新的 SBOM。在更新有關組件或新代碼的數據時，應重新創建它們。在Cybellum，我們將其稱為“動態 SBOM”，即每次更新或發佈時都能準確代表產品的 SBOM。
- 深度 – SBOM 應該包含所有頂級組件、以及它們的傳遞依賴。這些頂級依賴項應具有足夠的詳細信息，以使 SBOM 消費者能夠找到其他傳遞依賴項。隨著時間的推移，組織將能夠提供更深入的信息。
- Known Unknowns – 定義依賴圖是否完整，或者依賴圖是否未知且不完整。
- 分發和交付 – 通過公開 SBOM 可用性並確保可以檢索和訪問數據，使任何需要它的人都可以使用 SBOM 數據。
- 訪問控制 – 可以控制對 SBOM 的訪問，但應指定條款，包括有關如何將 SBOM 數據集成到用戶安全工具中的信息。
- 容忍錯誤 – 在實施 SBOM 實踐時容忍錯誤和錯誤，以實現改進和發展。
VEX – 了解真實 SBOM 風險的關鍵框架
雖然 SBOM 有助於組織了解產品中包含的第三方軟體組件的潛在風險，但它並不能洞察實際風險。為了解決這個問題， NTIA 提出了漏洞利用交換 (VEX)，它是 SBOM 的配套工件。它允許設備製造商傳達在 SBOM 中列出的其軟體組件之一中發現的漏洞的可利用性。這使組織無需回過頭來確定 SBOM 中列出的產品的漏洞是否會影響他們。
使用 VEX 允許 OEM 評估他們在其產品中使用的具有漏洞的組件是否可以在最終產品中被利用。有幾個因素可能會阻止漏洞被利用，例如：
- 最終代碼可能不會實際執行具有漏洞的庫的任何部分
- 條件編譯語句已從最終可執行文件中排除漏洞
- 當前的安全控制可防止漏洞被執行
在上述情況下，儘管組件存在漏洞，但不會導致最終產品存在漏洞。對於開發人員而言，這是一項必不可少且可節省時間的知識。在這種情況下，漏洞不需要進一步修復；因此，不會浪費額外的開發時間來創建不必要的修復。
VEX 對於希望驗證供應商提供的設備的安全性的資產所有者也很有幫助。過去，要辨別給定設備上使用了哪些軟體組件很複雜。如果製造商不告訴資產所有者該設備容易受到攻擊，資產所有者幾乎不可能知道。
許多使用 Treck TCP/IP 堆棧的設備都是這種情況。 在 Treck 庫中發現了一個稱為Ripple20的零日漏洞 。這個庫已經深深地嵌入到許多設備中。
有了像 VEX 這樣的系統，產品所有者可以很快了解到他們的系統是脆弱的，從而允許他們採取措施來緩解它。這對於已經成為惡意行為者主要目標的公用事業、醫藥和政府機構等行業尤為重要。
能夠快速識別和修復漏洞可以決定它們是否受到威脅。
VEX 在概念上類似於 基於上下文的分析 系統，用於確定數字系統的組件是否易受攻擊。
先進的基於上下文的分析通過結合底層硬件架構、操作系統配置、加密機制、密鑰、強化機制、完全控制流和所使用的 API 調用，在降低供應鏈風險方面比 VEX 更進一步。這允許對給定產品進行更深入和準確的分析。
保護供應鏈以促進發展是開發更安全產品的重要因素。知道使用了哪些組件是不夠的。相反，需要深入分析來識別漏洞並確定它們的適用性。
VEX 可能無法提供像基於上下文的分析那樣深入的評估；對防禦供應鏈攻擊還是有幫助的 。使用 VEX 等自動化工具結合 SBOM 和上下文感知漏洞分析是有效管理供應鏈漏洞所必需的。
不應忽視的 SBOM 領域
為了提高透明度和可見性，NTIA 建議支持具有更多元素的更廣泛用例，並鼓勵組織向供應商索取這些用例。這些包括：
- 附加數據字段 – 組件哈希、生命週期階段、其他組件關係和許可證信息
- 基於雲的軟體和 SaaS – 為雲提供商創建和維護 SBOM，而不僅僅是本地軟體
- 完整性和真實性 – 驗證 SBOM 數據來源的機制，如數字簽名
- 漏洞 – 鏈接到外部漏洞數據源，而不是僅僅依賴 SBOM 中的漏洞數據
- 依賴項中的漏洞和可利用性 – 確定漏洞對軟體組件的影響並通過VEX 向下游傳達此信息
- 遺留軟體和二進制分析 – 在 SBOM 數據不可用時實施二進制分析工具，例如使用遺留代碼
- 實施靈活性/統一性 – 將更廣泛的規則和程序與特定領域的迴旋餘地結合起來
NTIA 的文件沒有提供什麼？
雖然該文檔在幫助公司獲得可見性和控制其供應鍊和軟體組件、漏洞和合規風險方面大有幫助，但值得注意的是，SBOM 並不能解決所有安全問題。NTIA 的指南提供了一份清單，供您立即開始，並隨著我們的進步而改進。作為一項正在進行的工作，它並不全面，列表中的組件也不一定完整。
還需要注意什麼：威脅建模和風險評估
雖然檢測和管理漏洞是網絡安全策略的關鍵部分，但產品和設備安全團隊還需要注意其他安全風險，這些風險可以通過 SBOM 檢測到：
- 調試和遠程訪問軟體，這些軟體可能是合法且無漏洞的，但如果黑客可以訪問它們，也被視為有風險的軟體。在連接的產品和設備中使用它們時應仔細考慮。
- 不必要的軟體包，例如車輛 ECU 中的打印實用程序，或不可用硬件的驅動程序。這些也可能是合法且無漏洞的，但如果不需要，則不應出現在產品中 – 惡意玩家可能會在未來的某個時候找到利用它們的方法。
- 過時和停產的軟體：不再受支持或已停產的軟體包可能會使整個產品的安全性面臨風險。選擇使用它們時需要仔細考慮。
做對了
任何已經開始 SBOM 之旅的人都知道這並不像聽起來那麼容易。
當涉及到連接的產品和設備時，任務變得更加複雜。
僅手動生成 SBOM 在理論上是可行的，但如果您有數千個組件、一直添加新軟體、軟體更新，這種做法就很笨重——這只是跟踪日益複雜和分層的連接設備所面臨的一些挑戰。這很快就會成為一項不可能完成的任務。為了正確地做到這一點，您需要自動化流程並構建它以實現規模化。
利用 SBOM 實現持續的網絡安全和合規性
隨著我們連接設備背後的軟體變得越來越複雜和分佈式，保護您的整個產品組合的第一步是了解它包含的內容。SBOM可以提供強大的可見性框架，幫助團隊啟動漏洞檢測和修復過程。
然而，歸根結底，SBOM 是一個軟體組件列表，許多企業都急於根據當前的監管指南生成 SBOM。如果企業希望隨著監管在各個行業和全球市場的不斷發展而確保其網絡安全合規性 – 基本的 SBOM 只是第一步。
標準 SBOM 不包括網絡安全和合規性的許多方面，例如 API 調用、密碼、控制流、PII、密碼學、硬件物料清單、許可證和操作系統配置 – 僅舉幾例。
對於數量不斷增加的軟體組件，持續的網絡安全合規性必須超越包含軟體庫和版本詳細列表的基本 SBOM。合規性需要超越檢測的漏洞管理，包括漏洞的優先級排序和緩解 – 包括 CVE 和零日漏洞，在開發期間以及產品和設備投放市場後，通過持續監控和事件響應。
重要的是，這些流程可以輕鬆集成到已在使用的工具和流程中，這樣您的團隊就可以導入已經生成或在別處手動創建的 SBOM。
在一個設備越來越依賴於軟體、供應鏈威脅和法規成為頭條新聞的世界裡，這些基本的網絡安全實踐不能單獨進行。產品和設備開發團隊需要一個統一的產品安全流程，利用 SBOM 快速有效地滿足所有網絡安全合規性要求。
使用 Cybellum 最大化您的 SBOM 投資
Cybellum 為產品安全團隊提供了他們獲得對產品組件的完全可見性和控制所需的平台，因此他們可以確保整個產品組合的安全性和合規性。
在Cyber Digital Twins™ 技術的支持下，Cybellum 的產品安全平台為團隊提供了其產品組件的精確藍圖——包括構成、特性和它們運行的環境。Cybellum 的 Cyber Digital Twins 使團隊能夠實時檢測、確定優先級並減輕許可、合規性和安全風險。
Cybellum 幫助組織釋放 SBOM 的全部潛力，並利用這項投資創建強大的產品安全流程，該流程超越了基本的軟體物料清單。