摄影/余至浩
近年来，国外许多政府开始要求企业建立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来进行资产盘点和组态管理，也有的会与资安管理和资安开发流程结合，用于管理产品的弱点和检测潜在的安全与授权问题。
他也引用美国NITA对于软体物料清单的工具分类，分为三大类，第一类是 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内容的完整性和及时性，防止恶意篡改。