大家好，这里是安势信息。
如果您是关注我们有一段时间的朋友，那么SBOM对于您来说应该并不陌生：
关于SBOM是什么，SBOM应用指南，与SBOM与FDA相关政策的解读...诸如此类种种关于SBOM的信息越来越多的涌入到我们面前，尽管SBOM在我国的应用目前仍不普遍，一方面是因为SBOM投入使用涉及到的成本、技术、人才等各种问题，而在此之外，对SBOM的效果和定位没有正确的认知也是影响SBOM普及的一大原因之一。
基于此，今天为大家带来关于SBOM的十二大误区及对应事实，希望能给正在使用SBOM或推动SBOM使用的您带来帮助！
误区1：
SBOM的存在会为攻击者提供帮助
事实：虽然SBOM可能被用于攻击，但是通过SBOM的使用为我们带来的软件供应链透明度，会为企业以及其他类型的SBOM使用者带来更多的好处。因为对持有不轨目的的攻击者来说，关于透明度的相关信息所为其带来的效果十分有限，并且大部分情况下攻击者并不需要SBOM，攻击的“恶意”并不依附于SBOM。例如，WannaCry这一勒索软件的攻击并不需要SBOM作为攻击的前提条件。
误区2：
只通过SBOM是无法获得有效、实用的信息的
事实：软件的供应商、运营者、和使用者都可以使用SBOM。例如，用户可以通过SBOM很容易地判断是否受到了攻击的影响，以及攻击的影响范围在哪里。另外，SBOM所提供的组件信息提高了软件的透明度，同样的软件供应链的透明度又能反哺于组件本身的可用性，SBOM能让两者之间互相促进，且易于管理。
误区3：
SBOM必须公开
事实：不需要公开SBOM。本质上这是一个SBOM的共享方式的问题，诚然SBOM所提供的好处是需要共享来实现的，但事实上，SBOM的共享方式和时间可以由创建者或供应商来自行判断。美国总统令中也明确规定，SBOM的公开是SBOM创建方的决定，而这并不是必须的。
误区4：
SBOM会导致企业知识产权和核心技术的泄露
事实：SBOM是软件中包含的组件的列表,不包含专利和算法,并且不会公开知识产权。类比来看，SBOM更像是【材料列表】或配料表，而专利或算法等更像是【菜谱】，会将材料使用的时间、重量、方式等细节都表述出来。更直接的原因则是，SBOM中不包括软件的源代码，所以则更不用担心企业核心技术的泄露。同时，第三方组件的专利和算法等知识产权属于开发者或著作权所有者。
误区5：
SBOM的相关配套工具及体系尚不成熟
事实：软件成分分析工具（SCA）作为自动化生成SBOM的主要工具在一些领域的企业中已经使用了10年以上。同时在在软件透明度方面, NTIA、美国行政命令、SBOM标准化等都已经在进行了，包括就在去年出台的欧盟弹性法案，也提到了SBOM的使用及要求。虽然SBOM的大规模普及还未到来，但相关配套工具及体系能够完全支持现阶段企业的使用。
误区6：
只将目标软件中直接使用的组件纳入到SBOM中即可
事实：如果只了解目标软件中直接利用的组件，但不了解组件间的依赖关系及漏洞的传递路径，那么是无法准确判断软件是否易受攻击的。而关于将SBOM中的信息具象到什么程度，或者说软件的“SBOM深度“的相关讨论，业界的专家们对此有不同的看法。但不可否认的是，SBOM中需要包含的信息是根据使用者的需求而延展的，同时NITA也就关于SBOM中最基础元素做出了要求。
误区7：
无需SBOM生成工具的选择上花费太多心思
事实：目前市面上能够生成SBOM的工具其实并不少，有开源工具，也有商业的工具。对于有相关需求的企业来说，通过开源的SBOM生成工具，可以不花费成本地生成SBOM，但同时有一定的限制，比如其提供的相关支持、工具的使用说明及灵活性，都有较大的限制，学习该工具也能会花费不小的时间成本和人力成本，可能无法有效实现SBOM的创建及分发，同时，免费的SBOM生成工具也在范围和性能上比较局限。
所以具体选用什么工具来生成SBOM需要根据企业对于SBOM的多维度考量来决定。
误区8：
通过SBOM可以完全识别出包含在目标软件中的组件
事实：SBOM工具可以生成SBOM，但是有时会发生由于对目标软件中的组件的误报或漏报，导致无法生成正确的SBOM的情况。因此，通过SBOM工具对输出的SBOM进行复核等措施是必要的。此外，在运行时动态链接的库，应该由SBOM工具进行识别，在这种情况下，需要通过包管理器的方式来进行相关信息和执行环境的配置，并通过SBOM工具对其进行识别，从而确定软件所依赖组件。
误区9：
SBOM中显示的所有漏洞都需要一一处理
事实：当通过SBOM来评估软件中的漏洞的风险时，需要注意的是，并非所有的漏洞都是可利用的，因为确实存在不受利用的漏洞。因此，基于漏洞的影响范围、风险的评估结果、应对所需的成本等因素的考量，需要基于漏洞的优先级来做出应对。另外，在手动进行SBOM管理的情况下，除了需要利用漏洞库手动识别是否存在可利用性之外，还需要单独评估漏洞本身，并进一步单独讨论对应方针，这需要投入庞大的管理成本。
误区10：
生成的SBOM中的组件信息颗粒度应该在整个供应链中都是通用的，并且只保留必要的组件信息
事实：目前，在诸如美国（NVD）、日本的漏洞库（JVD）中，对于【受漏洞影响的组件】的颗粒度并没有达成统一的标准，也没有完全的体系化。所以如果限定组件的颗粒度的话，在漏洞的检测上可能会出现漏报的情况。因此，SBOM中包含开源软件以及本公司产品的组件信息是很有必要的。
误区11：
SBOM仅仅针对于软件包和嵌入式软件
事实：不仅是软件，IT系统都可以有对应的SBOM。容器镜像的SBOM、SaaS软件的SBOM、云服务的SBOM等诸如此类的在线应用的SBOM也是存在且必要存在的。目前在美国，相关机构在讨论SBOM的适用范围。
误区12：
目前只有SPDX、CycloneDX、SWID标签这三种SBOM的格式是被认可的，基于专有格式的SBOM不被认可
事实：根据美国NTIA的定义，SBOM是“包括软件组件及其依赖关系的信息在内的可机器处理的列表“，所以无论是什么格式，只要符合该定义，都可以视为SBOM。
同时，基于NTIA提出的SBOM中最基础元素的要求，其本质是为了达到【机器自动化处理】这一目的，从而大大提升SBOM的处理效率，而上述三种SBOM格式都是能够支持机器自动化处理的，从而被大家所推广使用。
随着全球范围内对软件供应链安全的重视，SBOM作为企业进行风险管理以及漏洞管理的重要依托，越来越被大家所重视。但是由于国内起步较晚，所以相比国外对于SBOM的一些认知稍显滞后，希望本文对于SBOM的十二大误区能够帮助到您进一步了解SBOM、使用SBOM！
Sectrend
清源CleanSource SCA工具：
一键生成高质量SBOM，为您的代码“正本清源”！
清源SCA针对开源组件安全漏洞、开源许可证合规风险、容器镜像安全、软件出口合规等场景，基于代码片段识别、文件识别、组件识别、依赖识别、容器镜像等多种探测技术以及强大的数据库，能够快速、准确、全面的帮助企业降低和管理其应用或容器中因使用开源软件和第三方代码（软件）引入的安全、质量和许可证合规性风险并帮助企业快速构建准确的SBOM，提供清晰的软件成分可视性分析，降低软件供应链风险，助力企业在软件开发全生命周期对其进行管理。
基于上文中所提及的SBOM相关问题，清源SCA可以帮助您：
一键快速生成高质量SBOM（支持SPDX、CycloneDX等多种格式）
支持生成基于SBOM的漏洞可达信息报告，让您对漏洞处理优先级一目了然
-
SBOM信息全面，细致到代码片段级别的扫描，组件间依赖关系一览无余，安全与合规问题无忧！
Reference:
本文参考材料来源于日本经济产业部及商务情报局联合发布的：
ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0
关于安势信息
上海安势信息技术有限公司是国内先进的软件供应链安全治理解决方案提供商，核心团队来自Synopsys、华为、阿里巴巴、腾讯、中兴等国内外企业。安势信息始终坚持DevSecOps的理念和实践，以多维探测和底层引擎开发等技术为核心，提供包括清源CleanSource SCA（软件成分分析）、清本CleanCode SAST（企业级白盒静态代码扫描）、清正CleanBinary (二进制代码扫描)、安全服务等产品和解决方案，覆盖互联网、汽车、医疗、通信、金融等多元化场景的软件供应链安全治理最佳实践。
欢迎访问安势信息官www.sectrend.com.cn或发送邮件至 info@sectrend.com.cn垂询。
点击蓝字 关注我们