隨著散布全球的工作場所無一倖免淪為經供應鏈傳播之網路攻擊的受害者，各國政府、企業和網路安全專家重新聚焦起供應鏈安全問題。軟體物料清單(SBOM)是近來被廣泛關注的資安工具，被視為抵禦供應鏈攻擊的潛在屏障，美國總統拜登的第14208號行政命令「改善國家資通安全」中亦提到此。預期當SBOM技術已臻成熟，能全面使用和標準化時，將可徹底改變供應鏈安全性。與此同時，製藥、能源、航太和半導體等垂直產業之組織一直所使用的Trend Micro Portable Security 3，可用以掃描確認所有入庫和出庫資產，創建OT健康檢查作為數位健康證明。透過資產屏蔽，原本難以追蹤的漏洞可以在不中斷營運的情況下快速輕鬆地解決。
軟體物料清單有利於評估風險
一份軟體物料清單描述著軟體內含的元件，在2021年Colonial Pipeline公司遭受勒索攻擊事件後，美國政府於2021年5月發布14208號行政命令，提出了此應對方式，使軟體開發者可以驗證其產品中包含的開源軟體和第三方軟體是否為最新版本且沒有漏洞。除了其他眾多益處外，軟體購買者可使用SBOM執行漏洞或軟體授權分析，其亦有利於風險評估，而另一方面軟體營運商能快速簡易地鑑別新發現的漏洞是否會令其面臨風險。
為了實現這些效益，需要一種可普遍使用的、機器可讀的SBOM格式以及一個可被其他應用程式和系統查詢SBOM的儲存庫。既為此生態系統的一環，SBOM可幫助資安團隊了解何時會受到不可預測但高風險威脅之影響，例如零時差攻擊。未來，會有自動化系統搜尋企業的庫存，並在出現新威脅時通知企業用戶，系統會將企業軟體內所使用之元件與存在漏洞之元件加以比較，並提出建議採取的行動方案。與此同時，針對全球基礎設施和企業資安的需求，提出一種不同的方法來解決類似的隱患，直到SBOM完全成熟，適合全面採用。
雖然Linux基金會和其他多方已建立並持續開發必要的開源標準，但在SBOM可完全實際使用前，可能尚有許多工作要完成。軟體元件清單可以採用主流的程式語言提供，且有針對國內SBOM和國際SBOM兩種標準。
軟體元件清單強化程式控制
營運技術(OT)軟體可自動控制數位設備，一個簡單的軟體程式便可操控一個開關。為了操控更多的開關、運作機械、控制伺服系統等等，軟體模組被連接在一起建構成越來越強大的程式。因為下游模組依賴於上游模組，即形成了一個相依樹(圖1)。
程式語言有賴開發人員在需求文件中包含所有建構應用程式所需的相依項的明細。理論上，這個相依明細列表就是SBOM。但在實務上，由於缺乏細節、其他要求清單的引用、以及格式不一致，致使需求文件有時難以解析(圖2~5)。軟體授權也是考量問題之一，由於缺乏通用名稱約定，使得要識別軟體模組變得複雜。軟體開發人員和供應商通常以組裝現有的開源和商業軟體元件來新創產品，造成不同元件難以追蹤和驗證是否安全的情況。
開源標準助力SBOM自動化
SPDX和CycloneDX是兩個目前正進行的開源標準項目，旨在建立自動化SBOM所需的標準。SPDX由Linux基金會主導，CycloneDX的工作團隊則來自線上社群OWASP。這兩個項目都解決了這些最低限度的元件，卻又保持了靈活性和一致性，包含驗證資料真實性的數學方法hash、軟體的成熟度開發過程階段、與其他軟體依存的關係、軟體授權許可、SBOM之完整性和真實性、與SBOM相關的漏洞、相關漏洞的嚴重性、有關舊版軟體之資訊、以雲端或軟體即服務為基礎的相關考量。
最小可行的SBOM
為了說明最小可行SBOM的要求，以「設備A」為例。設備A是由韌體控制的智慧逆變器。於此範例，假設此逆變器透過雲端通訊。如圖6所示，韌體、軟體和資料根據已知風險加以分色編碼。顏色最深代表安全的，顏色最淺代表低風險，顏色深度居中為中等風險，標示底線為高風險。韌體和軟體都是從人類可讀的程式腳本(原始碼)編譯成只有機器可讀取之目的碼。這是很重要的步驟，因為若在開發生命週期中未做好管理配置，原始碼和目的碼可能會在開發過程中不同步。
設備A的軟體物料清單以Json顯示。Json是一種常用於自動化的主流編碼格式。可看到在SBOM的每個元件旁都以Json編碼其風險(圖7)。
建立功能齊全的Json碼是為了展示SBOM的目的，也就是為每個軟體元件編寫一個安全等級。上述範例是缺少關鍵資訊，並假設評估漏洞風險完全符合低、中和高風險類別。在實務使用上，最小可行的SBOM必須考量架構、使用案例和資料格式，以便建立包含詳細資料的詮釋資料(Metadata)，例如SBOM生成頻率、軟體相依樹的深度、已知差距、已知錯誤，以及如何存取SBOM資料。
SPDX範例
軟體套件資料交換(Software Package Data Exchange, SPDX)為一開源標準的SBOM。此範例資料取自SPDX的GitHub，其顯示了一個帶有簡單「hello world」程式的C語言源碼檔，經Makefile編譯成無相依性的單個二進制物件。作業系統核心、C語言標準程式庫等相依性並未處理。Makefile、源碼檔和二進制物件全部包含一起進行。相依樹看似很簡單，但此SBOM已包含最少的元件(表1)。
SBOM概念驗證
美國國家電信暨資訊管理局(NTIA)和愛達荷國家實驗室已經使用開源標準對醫療保健、汽車和能源產業的SBOM執行了SBOM概念驗證。表2為能源產業的SPDX、SWID和CycloneDX格式的SBOM字段對照表。
SBOM面臨三大挑戰
首先是軟體命名標準，軟體開發中最困難的任務之一便是軟體命名。如果沒有統一的命名標準，便難以比較相依性，而相依性如何反映到CVE和NVD等漏洞資料庫？軟體標準太多所造成的問題，必須取得共識建立一個統一的標準。其次是軟體相依性，探索軟體相依性無疑會遭遇許多潛在挑戰。開源軟體發布在公共儲存庫，且針對不同的程式語言有不同的儲存庫。專用軟體通常並不公開提供給大眾，某些代碼是動態生成的。SaaS和基於雲端的軟體則有賴API來提取和共享數據。SBOM的第三個挑戰在於反SBOM威脅，另也存在SBOM無法阻止的威脅模型。例如，破壞原始碼儲存庫的攻擊者，如2020年的SolarWinds攻擊事件所見，會製造損壞的SBOM。即使使用SBOM，OT原生防禦功能也可防止未經核准的更新和掃描現場設備，這也是安全設施的最低要求。
營運技術健康檢查
從半導體產業的新E187等標準來看，OT驗證等實務已在許多營運環境中成功的施行。對半導體、鐵路運輸、航空等垂直領域的產業領導者來說，OT健康檢查已成為保障供應鏈安全的標準。對於任何生產性的OT設備，尤其是對關鍵基礎設施而言，安全檢查都是生活中的必要。定期執行資產安全檢查便能建立一個OT健康體檢，這些作業可根據需要加以儲存、引用和共享，便可建置值得信賴的資產安全記錄。
進行資產的第一次OT健康檢查始於其第一次掃描記錄，也就是入庫前掃描新資產，然後將其新增至資產盤點清單。接著是掃描出庫資產，在發貨前確認所有出庫資產都沒有惡意軟體，保留記錄以備將來需要。同時需要集中儲存和審查記錄，將所有掃描記錄都以單一控制台集中儲存和管理，以方便在必要時搜索和參考引用。收集的詳細資產資料包括：主機ID、主機名稱、網域名稱、登錄帳號和網域、MAC地址、IP、作業系統描述和類型(包括版本、構建、服務包、產品ID、語言、安裝日期/時間，以及之前安裝過的更新檔)、Windows和系統目錄、IE版本/構建/服務包/更新版本、供應商、硬體型號和序列號、BIOS版本/日期/類型、安全啟動狀態、CPU/CPU架構、處理器/內核、記憶體及其可用性、系統硬碟大小/可用空間和啟動硬碟、時區/系統日期/時間。
例如企業可以透過TXOne的Trend Micro Portable Security 3的資產庫存和掃描報告防護企業的供應鏈、儲存數位健康記錄，並維護詳細的資產知識。雖然SBOM和類似的系統將是OT網路防禦的浩瀚福音，但了解所使用的哪些軟體只是成功的一半。廠商如TXOne Networks的OT零信任方法將軟體清單結合OT健康檢查或SBOM(如果可用)，以保護資產中的高風險漏洞。在SBOM技術完全準備好可廣泛使用之前，保留企業內部詳細且易於參考的OT健康檢查記錄可維持客戶的信任、監控網路風險並更簡易地追蹤資產資料。
(本文由TXOne提供)
