「势说新语」SBOM 在企业软件供应链管理中的重要性—安全漏洞篇

引言：在信息安全界，近期爆出的最大的“雷”便是 2021 年 12 月发生的 Log4Shell 漏洞（CVE-2021-44228）。我们相信，类似 Log4Shell 的漏洞绝不是最后一次出现，那么下一次面临类似的问题的时候我们该怎样及早发现、及早修复呢？

在数字时代，软件安全已经成为政府、企业、组织等各个层面关注的重要问题。虽然软件是一种无形资产，但是由于忽视软件安全所带来的国家安全、企业安全、个人隐私等各个方面的严重问题却是“有形”的。CISQ(Consortium for Information & Software Quality) 发布的一个数字表明美国 2020 年由于软件质量付出的代价达到了 2.08 万亿美元。

更进一步，混源开发模式已成为常态，开源软件的使用比例越来越高。OSSRA 报告中显示，该机构调研的分布于各行业的组织中的 2409 个代码库中，有 97%的代码库包含开源组件。开源代码的使用对企业和开源社区甚至整个 IT 行业的发展都具有非常积极的意义，但是制定混源策略、管理这些日益增长的第三方代码、保证代码不受安全漏洞的威胁成为了一个迫切需要关注的问题。

在信息安全界，近期爆出的最大的“雷”便是 2021 年 12 月发生的 Log4Shell 漏洞（CVE-2021-44228）。该漏洞被广泛认为是史上最严重的信息安全漏洞。美国网络安全和基础设施安全局局长 Jen Easterly 把这个漏洞视为她职业生涯所经历的最严重的漏洞。接下来，我们就以该事件为例，与大家讨论如何在企业的软件供应链管理中及早发现、及早处理此类安全漏洞。

什么是 Log4Shell 漏洞

Log4Shell 是一个 Log4j 产生的零日漏洞，主要涉及任意代码执行，允许攻击者在服务器或其他计算机上执行任意 Java 代码，或泄露敏感信息。Log4j 是 Apache 基金会贡献的开源项目，于 2001 年首次发布，它是一个基于 Java 的日志框架，受影响的 Log4j 版本包含 JNDI 功能（如消息查找替换），这些功能无法防止对手控制的 LDAP 和其他与 JNDI 相关的端点。

Log4Shell 发现的时间线

• 2021 年 11 月 24 日 阿里云安全团队的陈兆军首先发现问题并报告给 Apache 基金会

• 2021 年 12 月 1 日 CloudFlare 报告了首次对该漏洞的利用

• 2021 年 12 月 10 日 CVE-2021-44228 编号分配，全世界范围内开始意识到问题的严重性

之后的一个月之内，围绕 CVE-2021-44228，Apache Log4j 总计爆发 8 个漏洞，其中 7 个高危以上漏洞。

Log4Shell 漏洞波及范围

Apache 给 Log4Shell 确定的 CVSS 分数为 10，这是严重性的最高等级，被誉为“接近于世界末日”的安全漏洞。

• 地理范围：此次影响的范围为全世界数亿台设备。

• 国家安全层面：加拿大、比利时等国因此关闭了政府的部分网络和在线服务。

• 企业层面：93%的企业云环境受到了影响。

• 版本层面：仅仅是 CVE-2021-44228，就影响了从 Log4j 2.0-beta9 到 2.14.1 的所有版本。

怎样及早发现及早处理这一类型的漏洞

我们相信，类似 Log4Shell 的漏洞绝不是最后一次出现，那么下一次面临类似的问题的时候我们该怎样及早发现、及早修复呢？

首先，在很多企业和组织中，建立起“开源有益，但需要加以管理和治理”的思维模式是非常重要的。我们要意识到使用开源是一把双刃剑，开源社区和基金会贡献了大量的开源项目，但其使用的安全性需要被重视。如果一味奉行拿来主义，那么再次出现 Log4Shell 这类的重大安全事件，会毫无招架之力，最终给企业造成很严重的经济和商誉的损失。

其次，企业需要对自身使用的开源组件有一个清晰的了解，随着开源组件使用的比例越来越高，我们很难通过维护 Excel 表格的形式去做统一的管理，不仅会浪费大量的人力，这种方式的准确性、有效性也值得商榷。那么一个更为有效的方式是通过建立标准化格式的软件物料清单（SBOM）来进行开源组件的管理。我们稍后会跟大家详细探讨这一话题。

接下来，掌握了企业和组织自身的软件物料清单后，就需要一个实效性和准确性并存的漏洞信息来源，将诸如 Log4Shell 这类的 0-day 漏洞准确地匹配到内部使用的开源组件中并及时告警、给出修复建议。

更重要的是，建立整个流程并保证其顺畅执行实施才是处理此类问题的核心。国内互联网企业大多已经采用 DevOps 的研发流程，那么把开源漏洞扫描融入到 DevOps 的工具链中，才能实现漏洞的早发现、早跟踪、早处理。在流程中的 SCA、SAST、DAST、IAST 等等测试就组成了 DevSecOps。当然，根据企业行业、规模和迭代周期等因素，DevOps 未必是针对部分企业的最佳实践，那么企业可以周期性的进行扫描代码中的开源漏洞。

综上，我们涉及了人（开发者，测试人员、安全团队）、工具（开源或商业化的 SBOM 生成和管理工具、漏洞库等等）和流程。这些要素有任何的断点，都会造成企业和组织对于重大安全漏洞的管理失能。

SBOM 是什么？怎样通过 SBOM 来建立企业的软件物料清单

首先，SBOM 的全称是 Software Bill of Materials，中文译为软件物料清单，它不是一种特定的文件格式。BOM 这个定义广泛存在于传统制造业，用以跟踪和记录产品的部件，当部件产生缺陷的时候，可以准确清晰快速地定位到缺陷影响的部件。那么同理，在软件领域，它的作用是能够实时跟踪软件中使用的第三方组件来管理整个软件供应链。

SBOM 有不同的格式，但是其实质都是对于组件、依赖、漏洞、许可证、版权等信息的展示。

SBOM 常见的格式有：

1. 工具本身生成的文件，其特点是需要借助于工具本身，进行不同工具之间的数据交换会需要二次处理；但是优点是可以根据工具的特点和功能进行信息内容的定制，进而展示到前端页面，可读性更强。如下是某工具生成的 JSON 文件截取，我们可以看到 Log4j 这个漏洞是如何在 Vulnerabilities 字段中展示出来的。

图 1：扫描工具生成的的 SBOM JSON 文件

通过工具的处理和渲染，该漏洞的信息会展示在客户端页面

图 2：扫描工具展示的前端页面

图 3：扫描工具漏洞信息的展示

我们可以看到其中展示了该漏洞各种相关的信息，包括严重程度、影响版本和修复建议等信息。

2. SPDX（Software Package Data Exchange）格式，SPDX 是由 Linux 基金会发起的，由 Intel, Google, Microsoft 等组织支持的格式，它包括了项目使用组件的信息、许可证信息、版权信息、安全性数据等其他元数据以提供软件供应链的透明度和安全性。SPDX 最初是作为组件许可证信息管理的需求而应运而生的。

3. CyclonDX 格式，CyclonDX 是由 OWASP 社区发起的，由 Sonatype, Lockheed Martin, Contrast 等组织支持的格式，CyclonDX 是一种轻量级的 SBOM 格式，最初是作为组件漏洞管理的需求而产生的。

SPDX 和 CyclonDX 可以作为一种跨工具跨平台使用的报告格式，而且他们的版本均在不断地更新迭代中。

4. SWID 格式也是一种，但是因其比较小众，暂不做过多讨论。

其实，无论使用哪种格式，无论是在每次代码更改时候进行增量扫描还是上线前的集中式扫描，只要我们建立适合企业自身的 SBOM 信息展示能力，就达到了开源组件漏洞管理目标第一步。

那么精准地掌握企业 SBOM 进而进行高效的漏洞扫描需要哪些能力？

快速：无论是使用开源还是商业的扫描工具，要求我们必须要快速实现扫描，特别是对于大型公司或者大型项目。比如 openEuler 社区，包含 200 个自研项目和 8000 个镜像，如此规模的社区需要一个快速的扫描工具，来满足单个文件的扫描速度快和增量扫描这些特点。

准确：SBOM 的准确性也体现在工具对各种颗粒度扫描的支持，比如代码片段扫描，那么一个准确并及时更新的数据库是至关重要的，一款领先的 SCA 工具可以做到在 0-day 漏洞暴露出来数小时之内推送到数据库中。准确这一特点也包括扫描引擎内部匹配算法的准确识别能力。

全面：全面与准确也是息息相关的，纵向来说，开源项目无时无刻都在更新，漏洞信息也是如此，那么需要数据库背后的数据挖掘机制足够强大来把源源不断的数据更新到数据库中。横向来说，支持例如 NVD、CNNVD、CNVD 等各种漏洞数据源也是体现全面性的一部分。

开源代码的大量使用所带来的问题不仅仅与安全相关，对于涉及知识产权的许可证合规方面的风险管理能力也是企业亟须建立或不断提高的，安势信息后续会与大家分享这方面的内容。我们下篇文章见！

参考资料：

[1]https://www.it-cisq.org/cost-of-poor-software-quality-in-the-us/index.htm

[2]https://www.synopsys.com/blogs/software-security/open-source-trends-ossra-report/

关于「势说新语」

安势信息推出全新栏目「势说新语」，旨在为开源软件供应链安全行业人士提供一个互相交流、互相学习的平台。欢迎各位大咖加入，共同探讨开源软件供应链安全行业现状及未来发展趋势、行业热点等话题，分享观点，碰撞思想火花。

欢迎大家踊跃投稿，可以谈谈你对开源软件供应链安全与行业发展趋势的见解，投稿请发送至邮箱：marketing@sectrend.com.cn