近年来，海外许多政府开始要求软件供应商创建SBOM（Software Bill of Materials，软件物料清单）。例如美国白宫在2021年发布行政命令，为了强化国家网络安全，要求其供应商都要提供SBOM。欧盟在几个月前通过《网络韧性法案》（EU Cyber Resilience Act, CRA），同样要求2027年前软件供应商必须提供SBOM，不提供的话，将面临至少1,500万欧元的罚款。另外还有医疗相关产品，包括在美国FDA和欧盟MDR医疗法规中都有要求SBOM，台湾食药店也有相关要求。

林上智是Bureau Veritas首席安全专家，也是国际自动化协会台湾分会会长。在今年的台湾安全大会上，他归纳了企业SBOM当前应用和实务上常见的六大挑战和偏见，并提出应对的建议。

SBOM指的是软件物料清单，类似于企业生产管理中常见的BOM表（物料清单）。林上智表示，不同于BOM记载产品本身各项成本、组成件、加工流程及供应商，SBOM软件物料清单主要记录软件构成组件及其关联表。

他表示，企业采用SBOM有四大好处，首先可以用来加强安全管理，通过获取软件组件的版本、名称来进行CVE或弱点关注；其次，它可以扫描授权，确保软件商业授权和开源软件授权规范都得到遵守。最重要的是透明度，SBOM表提供了一个透明且共享的平台，能够减少资源浪费。最后，SBOM还能降低人力和资源成本。

他举例说明，一家公司通常会有很多产品线和产品单位，各个不同BU部门可能会使用相似的工具，例如OpenSSL软件组件，但彼此并不知道对方有使用，版本也各有不同。一旦出现漏洞，可能得花更多人力和时间来修复。有了SBOM表，这种情况就可以避免。

偏见1: SBOM表可以用各种格式和方法产生

林上智归纳了SBOM在应用和实务上的六大挑战和偏见。第一个误区是不少人误以为SBOM表可以用各种格式和方法产生。他引用美国FDA的定义表示，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和SWIDX三种。其中，SPDX由Linux基金会推动，也是ISO 5962的标准，是目前最多人使用的格式，并且支持多种数据格式，包含Tag/value、RDF/XML、JSON、yml、xls等。其次是由OWASP力拥的CycloneDX的格式。他也列出这三大SBOM格式对应到美国NTIA的SBOM表的名称。

对于企业是否需要将产品的SBOM表公开？他表示，企业不需要公开其产品的SBOM，而是依法提供给监管机构或特定客户的要求提供。此外，在SBOM的保护方面，应涵盖整个生命周期，包括SBOM的交付、接受／验证、数据截取和管理、ETL（截取、转换及加载）过程以及映射和评估管理，以确保SBOM内容的完整性和及时性，防止恶意篡改。