天天要闻：莫被软件物料清单 (SBOM) 一叶障目

很多安全从业人员都在权衡软件物料清单（SBOM）可能给软件质量和安全带来何种好处。了解和评估软件风险需要SBOM，因为安全人员应能通过SBOM了解给定软件系统的软件构建过程。在某种程度上，某些产品和软件系统已经包含了SBOM；然而，按照美国第14028号行政令《改善国家网络安全》的明确要求，以及美国管理与预算办公室、国家标准与技术研究所（NIST）和网络安全与基础设施安全局 （CISA）最近的联邦指导意见，将SBOM应用到软件质量与安全的评估上，却还是相当新鲜的操作，并未经过广泛验证。

从未通过的罗伊斯法案

(资料图片仅供参考)

大约在2013年，SBOM立法H.R.5793——《网络供应链管理与透明度法案》（通称“罗伊斯法案”）被提出，但从未得到足够的推动力作为强制命令、法案或要求而获得通过。当时业界没兴趣通过要求透明度来管理软件供应链风险。

《国会记录——评论扩展》中概述了这项立法要解决的问题。有鉴于现代软件开发的极端复杂性和不断增长的规模，以及开源软件攻击日趋严重的形势，这些问题如今已然加剧。随着现代软件开发中开源软件消费率的不断提升，若想更好地管控软件风险，消费者就必须警惕开源软件项目中日渐积累的技术债务。软件复杂性提高、软件系统规模增大，以及技术债务不断累积，对政府想要通过软件供应链追求软件完整性和可靠性的愿望来说可不是什么好兆头。

“罗伊斯法案”未获通过的事实可以看做是错失了解决当时不断增长的软件安全威胁与风险的机会。十年后的今天，安全界仍在苦苦追寻恰到好处的SBOM实现方式，希望SBOM既有用，又不会沦为遭对手利用的目标。考虑到当下对联邦指南中概述的要求的疑虑，业界难免担忧SBOM是否已准备就绪。

SBOM必须提示未知风险

SBOM面临的挑战之一是了解如何确定风险软件并加以推进。用“风险”这个词是因为所有软件都有漏洞，而SBOM必须能够区分软件组件的风险级别或提供与之相关的上下文，无论组件是独立的还是已经集成到了软件系统中。简单粗暴地认为软件组件存在相关通用漏洞与暴露（CVE）就不能用是毫无意义的，因为所有软件都可能存在漏洞。考虑到软件实现和使用的上下文——组件功能（登录、加密、访问控制、授权）、运行环境，以及是否能够加以强化来减少特定攻击面，SBOM必须能够简洁明了地确定哪些CVE是最危险和可利用的。软件组件集成到系统的方式很重要，因为软件组件可能实现得很糟糕或者压根儿就不正确，导致暴露出软件系统中的漏洞。

用CVE建立起开源软件消费的安全基准很合理；然而，统计一堆CVE来确定哪些软件风险较小或较高，却只会将视线绑定到“已知的已知”（我们知道并能理解的事物，如下图所示）上，几乎无法帮助企业了解潜在哪些弱点可能会暴露漏洞并（在一段时间里）影响该软件组件的整体安全。此外，SBOM相关实践的当前状态也不会激励软件供应链商去了解软件的缺陷倾向或攻击倾向率。这一点很重要，因为一些软件组件由于固有的技术债务、低代码质量和可能暴露漏洞的安全问题而经常遭到攻击，需要大量修复。修复量大就意味着开发人员和工程团队没多少时间用在为客户创建和交付新功能上。

缺陷倾向是指软件产品发布后其中组件出现缺陷的可能性。各种各样的社会技术因素都会导致诸如低代码质量和设计缺陷等缺陷倾向。攻击倾向指的是软件组件遭到成功漏洞利用的比率，或者软件组件含有可利用弱点（错误、缺陷或瑕疵）或漏洞的概率。

SBOM解决方案必须能够让企业了解给定软件组件的潜在风险（如上图所示），帮助企业在选用和规避哪些软件组件方面做出明智的决定。举个例子，美国国家安全局（NSA）网络安全信息表中就有建议劝告开发人员规避用C和C++开发的软件，因为这两种编程语言不会执行良好的内存管理检查。这条建议将会如何影响软件供应链，尤其是嵌入式安全关键系统，以及供应商会不会转向Rust和Go等内存安全的编程语言，我们拭目以待。

深入探索

SBOM不会消失，我们有必要携手共同改善软件安全。这就可能需要开发出一系列工具和标准来丰富SBOM，提供对软件特性更深入的分析和洞察，帮助了解软件风险。企业可藉此有效评估和验证软件完整性及其他软件保障属性。最后，考虑到及时修复软件漏洞的行业挑战，软件供应链商不仅要了解给定软件组件的相关风险，还需要知晓在一段时间内使用该软件组件的相关维护措施。使用缺陷倾向和攻击倾向率能够提供可行情报，帮助降低风险软件的使用，指导软件供应链商构建更能抵御网络攻击的软件系统。

理论上，应规避具有高缺陷倾向和攻击倾向率的软件组件，从而刺激和鼓励使用安全性更好的替代品。SBOM并不能直接提升代码质量和安全性，但可以使软件供应链商更加了解软件构建过程中的风险。鉴于众人纠错并不能让所有漏洞都浮出水面，提高开源软件的代码质量和安全性尚需文化转变。

标签： 软件系统 软件风险 网络安全