浅谈SBOM（软件物料清单）

发表于 阅读次数： Waline： 本文字数： 1.8k 阅读时长 ≈ 6 分钟
深入解析SBOM（Software Bill of Materials）概念、作用及实施。探讨软件物料清单如何提升安全性、合规性和效率，以及在软件开发生命周期中的应用。了解SBOM对减少漏洞风险、优化依赖管理的重要性。

SBOM是什么

SBOM全称是Software Bill of Materials, 中文是软件物料清单。

做个类比，可以把SBOM简单地理解为软件的配料清单，就像我们买雀巢的速溶咖啡的时候，外包装上会有的配料清单。

美国电信管理局（NTIA）去年发布了一项规定，其中一个要求是政府采购的软件必须要包含SBOM，也就是说如果你想把你的软件卖给政府，必须附带这个软件的配料清单。可以参考SBOM。 这也就导致了SBOM这个概念一下子在美国变得很热门。

SBOM的作用和好处

根据NTIA的介绍，SBOM主要有以下9个作用

  1. 减少计划外的工作（Reduce unplanned, unscheduled work）
    例如，当发现某一个组件有漏洞的时候，在SBOM的帮助下可以很快了解有哪些软件受到了影响，并且根据漏洞的等级确定修复漏洞这个任务的优先级，减少花在排查和审核上的时间。

  2. 减少代码膨胀（Reduce code bloat）
    一家公司在不同的软件中可能会引用同一个（开源）组件的不同版本，有的时候是可以减少版本数量，尽量引用相同的版本的，减少版本的数量，SBOM可以帮助做这种标准化。

  3. 了解复杂项目中的依赖关系（Adequately understand dependencies within broader complex projects）
    有了SBOM之后，开发人员和管理人员可以根据SBOM report掌握软件的依赖关系，包括开源组件和公司内容组件，也更容易做代码重构，并且可以了解软件在未来的可维护性。

  4. 了解并遵循许可义务（Know and comply with the license obligations）
    SBOM中包含组件的license信息，它可以帮助公司更加便捷地了解组件的license信息，也更容易实自动化合规检查。
    这一点在国内其实不明显，在国外的重要性比较高。

  5. 监控组件的漏洞信息（Monitor components for vulnerabilities）
    这个很好理解，SBOM包含了软件所包含的所有组件，当某一个组件发现有漏洞的时候，只要看一下SBOM里面有没有这个组件就知道我们的软件有没有被影响了，这一步甚至也可以做成自动化的。
    这样可以在很短的时间内就做出反馈，有助于提升客户对公司的信任。

  6. 了解我们所使用的组件是否还有人支持（End-of-life）
    一个软件中使用了那么多的第三方组件，这些组件也许有的已经没有人在维护了，作为一个负责人的组织，应该积极应对这种情况，SBOM在一定程度上可以帮我组织了解这个信息。

  7. 使代码更容易review（Make code easier to review）
    NTIA关于这一点的解释我不太能理解，也没太看得懂，这里贴上原文

    Tracking components and subcomponents can make code easier to review and understand for developers, simplifying builds and reducing obstacles to getting code into production. Much of the initial security testing for avoidable harm can happen at early stages and in-context, as the code is written/assembled, weeks or months earlier than the alternative. Furthermore, this tracking enables situational awareness when an underlying dependency changes. It can also provide a better understanding of the work and time needed to make a change to the codebase.

  8. 帮助设置禁用组件黑名单（A blacklist of banned components ）
    有一些组件出于可靠性、性能、安全、公司的策略等原因不应该被使用，在SBOM的帮助下可以实现这一点，只要检查软件的SBOM 报告中有没有这些组件就好了。

  9. 便于向客户提供SBOM报告（Provide an SBOM to a customer ）
    客户出于安全或者法规的要求需要SBOM报告，在我们有SBOM报告的情况下，就比较容易做了。

以上9点是NTIA提出来的SBOM的作用，但是个人感觉，就我们国内的现状而言，只有5和8这两点是比较实用的。
因为目前国内还没有相关的法律法规的要求，企业没有利益的驱使和法律的要求，就没有太大的动力去实施。

SBOM的实施

虽然目前国内还没有相关的法律法规，但是以后应该还是出台的，尤其是在政府、医疗、金融、车载软件等至关重要的行业。既然SBOM有那么多作用，我们应该怎么在公司内部进行落地呢？

这里记录一点自己的想法。

想要比较好的实施SBOM有两个前提：1. 相对完善的CICD工具和规范； 2. 至少有一个软件成分分析（SCA）工具或者制品代码分析工具。

开头提到过，SBOM其实有点像软件的配料清单，就是收集一个软件使用了哪些第三方组件（其实不止这些，暂且这么认为，其他的以后再写），在整个软件生命周期（SDLC）中，做CICD的时候是比较适合也容易收集这些信息的，而收集这些信息就要依赖于SCA 工具（或者制品代码分析工具，下面就只写SCA工具），因为它可以获得软件当中所引用的第三方组件清单。

其实在一定程度的简化之后，SBOM也可以说成是收集、整理、展示SCA工具扫描之后的结果

在一个相对完善的CICD流程中，一般包含安全扫描、编译、测试、集成、发布这几个步骤，在做安全扫描的时候，如果包含SCA的话，往往就可以得到实施SBOM所需要的信息，接下来要做的就是怎么样到处这些信息按照SBOM的要求去管理和展示这些信息。

从这个角度来说，如果公司已经有了比较完善的CICD工具、规范和至少一个SCA工具，那么只要对SCA工具扫描得到的信息进行一些处理和展示就得到了一个简单的SBOM系统了。

虽然上面说的那样也能算是一个SBOM系统，但是在实际应用中，肯定不会那么简单。以后会单独把SBOM的实施拎出来写。

SBOM的范围

前面提到过，SBOM就是软件所应用的第三方组件的清单，严格来说这是不准确的。

SBOM应包含一下这些信息：

  1. 软件所引用的第三方组件清单（包含License信息）
  2. CICD过程中所使用的的工具、系统等信息
  3. 如果是SaaS产品，应该包含软件运行环境的信息，如操作系统及版本等

因为这些信息对于一个软件来说都是很重要的，以上这些信息中任意一个有安全问题，都有可能导致软件本身也有安全问题。