企業導入SBOM軟體物料清單有六大常見迷思的考驗

近年來，國外許多政府開始要求軟體供應商建立SBOM（Software Bill of Materials，軟體物料清單）。例如美國白宮在2021年發布行政命令，為了強化國家網路安全，要求其供應商都要提供SBOM。歐盟在幾個月前通過《網路韌性法案》（EU Cyber Resilience Act, CRA），同樣要求2027年前軟體供應商必須提供SBOM，不提供的話，將面臨至少1,500萬歐元的罰款。另外還有醫療相關產品，包括在美國FDA和歐盟MDR醫療法規中都有要求SBOM，臺灣食藥署也有相關要求。

林上智是國際自動化協會臺灣分會會長，在今年的臺灣資安大會上，他歸納了企業SBOM當前應用和實務上常見的六大挑戰和迷思，並提出應對的建議。

SBOM指的是軟體物料清單，類似於企業生產管理中常見的BOM表（物料清單）。林上智表示，不同於BOM記載產品本身各項成本、組成件、加工流程及供應商，SBOM軟體物料清單主要記錄軟體構成元件及其關聯表。

他表示，企業採用SBOM有四大好處，首先可以用來加強安全管理，透過獲取軟體元件的版本、名稱來進行CVE或弱點追蹤；其次，它可以掃描授權，確保軟體商業授權和開源軟體授權規範都得到遵守。最重要的是透明度，SBOM表提供了一個透明且共享的平臺，能夠減少資源浪費。最後，SBOM還能降低人力和資源成本。

他舉例說明，一間公司通常會有很多產品線和產品單位，各個不同BU部門可能會使用相似的工具，例如OpenSSL軟體套件，但彼此並不知道對方有使用，版本也各有不同。一旦出現漏洞，可能得花更多人力和時間來修復。有了SBOM表，這種情況就可以避免。

迷思1: SBOM 表可以用各種格式和方法產生

林上智歸納了 SBOM 在應用和實務上的六大挑戰和迷思。第一個誤區是不少人誤以為SBOM表可以用各種格式和方法產生。他引用美國NITA的定義表示，SBOM的內容必須符合一定的格式，且必須是機器可讀的，也就是說不能使用紙本文件來提供。

迷思2: SBOM中只需列出自行開發的軟體，對於使用的開源軟體或商用套裝軟體則不需列入

第二個迷思是認為SBOM中只需列出自行開發的軟體，而對於使用的開源軟體或商用套裝軟體則不需列入其中。他表示，實際上，SBOM應包括產品中所有的軟體元件，不論是自行開發的、開源的還是商用的軟體，只要用在自己的產品中，就應該被列入SBOM，因為這些元件都是產品的一部分。這樣才能提供完整的軟體物料清單，有效管理安全風險和相依性。

迷思3: SBOM表只要購買商業軟體或掃描工具就可以自動建立，不需要人為介入

他提到的第三個常見迷思是認為SBOM表的建立，只要購買商業軟體或掃描工具就可以自動建立，不需要人為介入。但他表示，不同SBOM的格式，有各自支援的工具，包含商業軟體、開源軟體，這些工具都有可能存在誤判或漏判的情況，因此仍然需要人工確認，確保SBOM的準確性和完整性。

迷思4:SBOM表產生後，就意謂完成所有工作

許多企業認為SBOM表產生後，就意謂完成所有工作是第四個常見迷思。林上智強調，「千萬不要以為只要有SBOM表就行，重點是要拿它來做什麼事」。他指出，有些企業會使用SBOM來進行資產盤點和組態管理，也有的會與資安管理和資安開發流程結合，用於管理產品的弱點和檢測潛在的安全與授權問題，這些都是可以應用SBOM的地方。

他也引用美國NTIA對於軟體物料清單的工具分類，分為三大類，第一類是SBOM 表產生工具，這類工具可以透過分析原始碼或執行檔來產生軟體物料清單；第二類是軟體物料清單接受格式的工具，如SW360，這類工具可以用來管理SBOM 表的內容和版本等；第三類是軟體物料清單格式轉換工具，可以在不同格式的SBOM 表之間進行轉換，確保SBOM內容格式的一致性。

迷思5:SBOM產生需要掃描程式碼，沒有程式碼就無法生成

許多人認為產生SBOM一定需要掃描程式碼，沒有程式碼就無法生成SBOM。這是第5個常見迷思。他表示，事實上，SBOM表可以在軟體開發的不同階段生成，包括設計、程式碼、建置、分析、部署環境和Runtime階段。每個階段都可以生成SBOM表，以反映該階段的軟體元件和依賴關係。

他指出，在軟體開發的這六個階段中，通過程式碼生成或分析執行檔產生SBOM是最常見的做法。相比之下， runtime階段產生的SBOM較為少見，但該階段的SBOM内容是最準確的，但也最具挑戰性。他也說，目前法令或法規都只要求要有SBOM，但沒有要求要多準確，一定要在runtime階段做分析。但他認為這是會未來長遠的發展趨勢。

迷思6:使用SBOM表掃描已知漏洞，沒有掃描到代表就很安全

最後一個迷思是使用SBOM表掃描已知漏洞，沒有掃描到代表就很安全。他引用CVE背後的NVD資料庫的說明，有時可能出現可能有弱點，但沒有掃到的情況，例如弱點發布時間差或資料庫還沒更新等。

面對SBOM在實務上的種種挑戰，他建議，企業在開發產品一定要考慮到模組化，這樣在SBOM表管理上會比較容易，他舉例，過去很常看到一體式產品，把所有東西都打包，但這樣的情況下，產品就只會有一個SBOM，就沒辦法看到產品更細步的清單內容，且一旦遇到其中使用的開源軟體有問題需要修正時，就必須整個SBOM表一起修正，沒辦法僅就開源軟體的SBOM表來修改。

再者，他強調，SBOM表的格式選擇很重要。他指出，目前SBOM常用的軟體資料交換格式包括SPDX、CycloneDX和SWID三種。其中，SPDX由Linux基金會推動，也是ISO 5962的標準，是目前最多人使用的格式，並且支援多種資料格式，包含Tag/value、RDF/XML、JSON、yml、xls等。其次是由OWASP力擁的CycloneDX的格式。他也列出這三大SBOM格式　對應到美國NTIA的SBOM表的名稱。

對於企業是否需要將產品的SBOM表公開？他表示，企業不需要公開其產品的 SBOM，而是依法提供給監管機構或特定客戶的要求提供。此外，在SBOM 的保護方面，應涵蓋整個生命周期，包括SBOM 的派送、接受／驗證、資料擷取和管理、ETL（擷取、轉換及載入）過程以及映射和評估管理，以確保SBOM內容的完整性和及時性，防止惡意篡改。