他也引用美国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内容的完整性和及时性，防止恶意篡改。