SBOM：软件供应链的未来还是幻影？
距离软件物料清单（SBOM）要求发布已经过去了两年时间，但业界还远未达到这一要求。SBOM到底是能够实现的梦想，还是虚无缥缈的幻想呢？
美国总统拜登于2021年5月发布的网络安全行政令引入了强制软件物料清单（SBOM）的概念。其意图总结起来非常简单：提供对新软件所用组件的透明度和可见性，以此提升软件供应链安全。
18个月后的2022年12月，代表亚马逊、苹果、思科、谷歌、IBM、英特尔、万事达、Meta、微软、三星、西门子、威瑞信（Verisign）等科技巨头的游说团体联系美国行政管理和预算局（OMB）：“我们请求OMB阻止各机构要求提供[SBOM]，除非已深入了解应如何提供这些清单，且机构已准备好使用提交的清单。”
如果过了18个月还在原地踏步，没发挥出SBOM的功效，那就得问问还需要做些什么才能实现拜登的网络安全行政令了。
SBOM的作用
SBOM旨在提供对应用隐藏区域的可见性，从而提高软件供应链的安全性，SBOM详细呈现应用中用到的每个代码组件。美国网络安全公司Tanium安全总监Matt Psencik解释称：“SBOM构建的列表包含了每个应用程序使用到的所有包和共享库，还有它们的版本号。”
“如果某个包里混进了漏洞，你可以更新、删除那个包，或者联系供应商问问有没有新补丁可以修复漏洞。”他补充道。
SBOM旨在提供应用所含每个代码组件的详细信息，无论是商业软件组件、开源软件（OSS）库和依赖项，还是什么内部开发的库。Tigera安全工程经理Anthony Tam表示：“可以使用这一信息来确定安全修复和更新的优先级，跟踪和管理漏洞，以及监测相关规定和标准的合规情况。”
SBOM通常可以类比为食品的成分表。知道成分，购买者才能检查消费该产品是否涉及什么风险。但相比食品成分表，SBOM要深入得多，提供的数据更多更详细。
尽管列出了所有来源的每个组件，但软件供应链的首要目标和最大问题是开源软件。开源软件也是SBOM项目的最大问题和阻碍。
开源软件问题
开源软件遍布各处，任何新应用似乎都无可避免地要用到开源软件组件，开源软件就在那里，随时随地免费取用，可以帮助开发人员加快其新应用的开发速度。
问题在于，开源软件实在是太多了，往往由个人或小型协作团队开发（通常都没报酬），而且每个开源软件库往往都进一步依赖其他库或组件，其他库或组件又有自己的依赖项。在自由市场对速度经济的需求下，期望应用开发人员知道自己的应用用到了哪些依赖项，或者知道其应用使用或未使用某个开源软件库的哪些部分是不可能的。
看看下面这些数字。GitHub 2022年Octoverse报告表明，2022年GitHub上有5200万个新的开源项目，GitHub开发者全年对开源项目做出了4.13亿次贡献。SourceForge托管着50万个开源软件项目，Apache则托管着另外350个。此外还有别的开源软件源。
这些开源项目的开发人员大多是程序员而非安全专业人士。理论上，这些代码的开放性质就给第三方研究人员留下了检查代码找出缺陷、漏洞和恶意软件的空间。但很遗憾，这相同的开放性也让攻击者能够找到这些漏洞，有时候还能插入他们自己的恶意软件。
SBOM旨在让商业软件应用开发人员、应用购买者和用户更能看到这些开源软件问题。但开源软件市场的巨大规模导致了诸多困难。这也是SBOM项目进展缓慢的主要原因。
SBOM现状
SBOM发展进程中的一个明显问题是，既没有明确规定SBOM应该提供什么、以何种格式提供，也没有具体说明应如何解释和使用SBOM。类似规范就是美国国家电信和信息管理局（NTIA）于2021年7月发布的《软件物料清单最小必要元素》了。但正如该文档所断言的，“SBOM的最小必要元素只是个起点，联邦政府应鼓励或开发关于如何实现SBOM的资源。”
美国网络安全与基础设施安全局（CISA）是SBOM项目的焦点，将其作用描述为“促进社区参与、发展和进步，重在扩展 和可操作化，以及工具、新技术和新用例。”
2023年4月，CISA发布了三份SBOM相关文档。第一份题为《共享生命周期报告》，展示了SBOM如何从编制者流向消费者，以及SBOM如何在此过程中充实产品。
但该文档并没有指明应怎样创建SBOM和如何共享SBOM，也没有说明应如何解释SBOM。
另外两份在4月份发布的文档题为《软件物料清单（SBOM）文件类型》和《漏洞可利用性数据交换（VEX）最低要求》。“类型”文档列出了六种不同SBOM类型及其优势与限制。该文档结语写道，“这些定义仅作为起点……”
“VEX”文档（VEX概念是在NTIA最低要求文档中提出的）中写道，“本文档规定了创建VEX文档所需的最少元素。如第4.1节所述，这些元素源自现有VEX文档和实现，但可能不完全符合。本文档也规定了一些可选VEX元素。”
这些文档中列出了软件作者可以在SBOM生产和消费中使用的一些选项，但并未说明作者应该或必须做什么。或许这种缺乏指导和允许市场力量表述和解决问题的情况才是SBOM项目当前最大的阻碍。
不同安全供应商开发不同产品帮助自动化这一过程：首先要能够生成SBOM，然后要能够接收、处理和修复，通过SBOM找出或凸显的任何问题。自动化是这类项目的基础，但随意的自动化不能解决问题。
Phylum联合创始人兼首席安全官Pete Morgan解释了这个问题。“我在家弄了个小型测试实验室，有六到七种工具可以用来分析代码并生成SBOM。然后，我还有五到六种其他工具可以接收生成的SBOM，尝试解释这些SBOM并做点什么。我用相同的代码库进行测试，每种工具都产生了不一样的SBOM，而且无一能被其他工具解释。”
VEX
尽管严格意义上不是SBOM本身的一部分，但VEX文档是SBOM项目的重要一环。SBOM可帮助购买者了解所用软件中存在的漏洞。但这些漏洞必须为人所知，通过软件开发人员（或者别的渠道）提供的VEX通知他们。
该流程的基础是开源软件开发人员，而这就是个问题。从技术上讲，开源软件开发人员必须将代码中发现的任何漏洞告知用户。Morgan是这么描述这个问题的：“这些开发人员是几乎所有软件产品的基础，但他们没有高级产品安全团队支持。期待他们向我们提供关于自身代码的准确漏洞信息是有点痴心妄想了。这跟让盲人观察员告诉我们有没有人过来没什么两样。”
尽管如此，VEX（以及正在研讨的其他几个扩展）也是“有意思的想法，只是我们现在缺乏有效使用的流程或对流程的了解。”
WithSecure高级威胁情报分析师Stephen Robinson认为，维护SBOM和VEX文档是关键。“更新SBOM并向消费者传达这些更新是一个关键问题。安全形势随着CVE被发现和补丁的发布而不断变动，SBOM也会随之变更。”
美国国家网络安全战略
SBOM项目的价值和问题都根植于开源软件这一无定形的存在。期望单个开发人员和合作小组能够及时准确地生成SBOM文档根本就是不现实的。
2023年3月1日发布的《国家网络安全战略》战略目标3.3谈到了将安全责任从用户身上转移到软件开发商身上。具体讲，“责任必须放在最有能力采取措施防止不良结果的利益相关者身上，而不是通常要承担不安全软件后果的最终用户身上，也不是组件的开源开发者身上……”。
这么做可以将SBOM和VEX文档的责任集中在出品商业软件的供应商公司身上，而不是开源软件库的开发者身上。但问题在于，没有具体的指南或指示说明该如何实现这一目标。缺乏这类指南，急于向市场推出新产品的中小企业或初创公司就很容易漏掉隐藏在其所用开源软件库子依赖项中的漏洞。
Psencik评论道：“只有在积极跟进软件包漏洞相关情报源搜索漏洞，并在发现带漏洞软件包时切实进行修复的情况下，SBOM对企业而言才有价值。当前的大多数SBOM都是给你提供更多信息的一种工具，但如果不根据这些信息采取行动，那SBOM也不过是安全团队工具箱中的又一款积灰工具。”
还需要做些什么？
SBOM项目进展缓慢不假，待解决的问题很多也是真的，但几乎没有哪个网络安全专家会质疑这个项目。业界普遍认为，这是软件供应链安全的重要发展，一旦实施，将惠及所有人。
Viakoo首席执行官Bud Broomhead评论道：“加强使用和标准化可以改善SBOM的现状，尤其是在为企业提供经验证的SBOM自动化使用方法来改善安全方面。”
其中存在的主要问题可能更多是政治性的，而非组织性的。根据《国家网络安全战略》，美国当局将寻求“塑造市场力量”，并“通过联邦购买力和拨款”来实现这一目标。但对所有网络安全供应商强制执行联邦要求是不可行的。
这就变成了联邦政府能否切实塑造市场力量的问题。Morgan警告道：“事实上，如果只是让市场自行调节，我认为我们永远实现不了这一目标。我确实觉得监管不可或缺。”但政府只能监管联邦机构的采购。销售领域不包含联邦市场的小型软件开发商就可以无视此类监管。
Morgan指出，某些行业，比如高度安全敏感的关键行业，已经有了严格的软件安全控制机制。“但对于参与市场力量的其他软件产品来说，速度就是驱动力：我们能以多快的速度推出产品？我添加新功能的速度有多快？多快能发布出来？涉及到了解这些组件的相互关联深度并加以记录和更新的时候，这就很成问题了。所以，我确实认为监管很有必要。”
Teleport安全副总裁Reed Loden提出了两点具体建议。“首先，要求通用CI/CD方法默认生成SBOM；其次，要求在一些合规或法律义务中纳入SBOM。基本上，你要么需要让SBOM成为毫不费力就能提供的‘一键生成’产物，要么明确要求SBOM落地（这会触发实现第一点建议，因为大家会希望能默认生成）。”
Jscrambler联合创始人兼首席技术官Pedro Fortuna给出了一个解决办法。他说：“想要尽可能地提升SBOM的有效率，就必须解决两个问题。首先，必须及时更新SBOM并推送给消费者。这一点可以通过独立第三方运行时监测解决方案实现（不需要软件作者配合），这种解决方案能够持续动态识别所有软件组件。”
其次是必须验证供应链完整性。该运行时监测解决方案应验证所有子组件的完整性未受损，而且其中未运行任何恶意代码。此处的问题在于，如果监测解决方案是由独立第三方开发的，那就可能会有很多种，且Morgan提出的SBOM不一致的问题会继续存在。但如果解决方案是由CISA开发或其委托开发的，那就是强制性的，且不参与‘塑造市场力量’。
Endor Labs联合创始人兼首席执行官Varun Badhwar认为，某种形式的更为激进的指导对于打破困境僵局是必要的。他表示：“我希望看到CISA提供更多的监管指导，因为他们可以与其他监管机构合作制定并发布指导方针，鼓励或要求在特定行业使用SBOM，例如关键基础设施、政府合约和软件采购流程。”
“CISA还可以倡导财政激励措施，鼓励各企业采取SBOM实践，比如为投资实现SBOM的公司提供税收减免、补助或其他形式的财政支持。CISA可以采取类似开源安全基金会（OpenSSF）的做法，与构建SBOM技术的供应商合作，从而彰显最佳实践，为企业广泛采用SBOM做好准备。”
建立行业联盟来促成SBOM解决方案一致性确实可以平衡强制监管和市场力量。这里面唯一的弊端在于，委员会在培育赛马时往往会搞出一匹骆驼。
终极梦想
批评CISA明显没有强力推进SBOM可能有失偏颇。该机构之前可是很有耐心地在把一个好主意打造成一项有价值的服务。想想KEV（已知被利用漏洞）列表。在早期的时候这东西可没什么明显价值。但KEV一直在增长，现在常被用作现成的漏洞分类源——如果漏洞出现在KEV列表中，你会自动知道应该紧急加以修复。
SBOM项目也在缓慢推进。只是我们不清楚这是因为CISA是在黑暗中摸索，还是因为这就是预想计划的一部分。不过，即使实现了SBOM，也很可能无法完全解决问题。JupiterOne代理首席信息安全官Guillaume Ross评论道：“我觉得，提高透明度终归是件好事。但供应链安全领域没有万能药，网络安全领域的任何一部分都没有。”
所以，回到我们最初的问题，我们可能未来十年内都不知道SBOM是会成功还是仍旧是个幻想。我们所知道的是，在此期间需要投入大量工作。
