他也引用美國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 和 SWIDX 三種。其中，SPDX由Linux基金會推動，也是ISO 5962的標準，是目前最多人使用的格式，並且支援多種資料格式，包含Tag/value、RDF/XML、JSON、yml、xls等。其次是由OWASP力擁的CycloneDX的格式。他也列出這三大SBOM格式　對應到美國NTIA的SBOM表的名稱。

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