SCA技术进阶系列（四）：DSDX SBOM供应链安全应用实践

一、SBOM的发展趋势

数字时代，软件已经成为维持生产生活正常运行的必备要素之一。随着容器、中间件、微服务、 DevOps等技术理念的演进，软件行业快速发展，但同时带来软件设计开发复杂度不断提升，软件供应链愈发复杂，软件整体透明度下降，软件供应链安全防护难度不断加大。

由于缺少对软件资产的最小要素管理，每当环境中出现新的漏洞时，我们通常需要花费大量时间和精力来检测环境中运行的应用程序和服务的真正影响。如果我们可以枚举我们使用和生产的所有软件组件，并且轻松地分发和使用它，那么就可以极大地提高对软件资产的精细管理，以及对突发漏洞的影响面快速定位分析。

SBOM可以帮助我们解决以上问题。

开源社区十多年前开源社区就注意到创建SBOM的必要性，2010年SPDX开放标准开始作为解决该问题的初步方案。

图一 数字供应链下愈发复杂的应用资产构成

SBOM是为了提升供应链透明度而记录其软件组成等信息的工程文件，对降低供应链维护和保障的工作量及难度意义重大。随着软件供应链安全成为关注焦点，特别是2021年美行政令EO14028要求包括NIST在内的多个机构通过与软件供应链的安全性和完整性相关的各种举措来增强网络安全，SBOM的推广和落地也变得尤为迫切。

理想情况下，产品的供应商应该告诉我们每个组件，并以数字签名文档的形式提供，以防止篡改或修改。但是SBOM在使用推广过程中并不顺利，特别是在国内没有自主协议框架的情况下。多数情况下，上游每个组件生成 SBOM 的最佳方法仍然不统一，这会导致SBOM不完整或不准确；更不用说不同的现有格式（CycloneDX、SPDX、SWID）和缺乏标准化的分发机制，这使得 SBOM 的消费变得相当困难。

除了SBOM协议不统一、数据字段不一致以外，大多厂商只有在生产环节生成SBOM，没有分发和使用，更无法在供应链中形成链接的链条。SBOM未来的方向是分发、验证、集中数据和使用数据。

二、SBOM主流协议的风险

SBOM应该是机器可读的格式，同时也是易于人类可读，国外主流的SBOM格式有三种：

1. Software Package Data Exchange（SPDX）

• Linux基金会主推的格式；许可证：cc–by-3.0

• 已经完成标准化工作，标准号：ISO/IEC 5962。

2. CycloneDX

• OWASP基金会主推的格式；许可证：apache-2.0

• 尚未完成标准化工作。

3. Software Identification（SWID）

• NIST主推的格式；

• 已经完成标准化工作，标准号：ISO/IEC 19770。

图二  linux和owasp基金会部分条款

当下看主流协议的许可证似乎并无断供风险;但是作为Linux、OWASP基金会下的项目，如果违反了基金会的条款，基金会有可能会阻止访问项目。

目前我国在软件供应链安全物料清单管理方面的基础比较薄弱，缺乏统一标准规范，限制了软件物料信息的共享和数据交换。随着国内外软件供应链安全法规和实践标准的逐步落地，自有SBOM的推广应用将有效提升软件供应链透明度，极大地便利软件组件溯源、软件产品依赖关系梳理、已知漏洞的影响范围判断、及时发现恶意软件渗透等，从而有力支撑软件供应链相关监管政策规则的落地实施。

三、DSDX协议的组成要素

DSDX（Digital Supply–chain Data Exchange）SBOM格式由OpenSCA社区主导发起，汇聚开源中国、电信研究院、中兴通讯等权威研究机构、甲方用户、安全厂商多方力量，共同适配中国企业实战化应用实践场景。作为国内首个数字供应链安全SBOM格式，DSDX目标是成为数字供应链安全治理与运营的核心技术抓手，以助力行业及产业从软件供应链安全向数字供应链安全过渡升级，使每个软件公司都可以将SBOM 附加到每个可交付成果，并且每个人都可以完全了解软件中使用的组件，并确切地知道哪些漏洞正在影响该软件。

DSDX规范文档由基本信息、项目信息、对象信息、代码片段信息及依赖信息这几部分构成。

1)SBOM 清单信息：清单名称、ID、创建者、清单版本、创建阶段、创建时间等

2)项目基本信息：项目名称、宿主环境信息、运行时环境信息、EAR 信息等

3)组件信息：组件名称、ID、厂商、组件来源、组件类型、置信度、校验码、语言、依赖关系、依赖数量、依赖路径等

4)代码文件信息：名称、ID、校验码、路径、相似文件来源、相似度

5)代码片段信息：ID、来源文件 ID、校验码、代码片段位置、相似代码片段来源、相似度

6）依赖树信息：以 K-V 形式保存的项目完整依赖关系图（在任何情况下，SBOM 都应该捕获多级依赖关系）

7）备注信息：其他备注信息

DSDX兼容SPDX、CycloneDX、SWID国际标准和国内标准，但不止于主流规范，在最小元素集基础上扩展其他元素。DSDX重点引入了运行环境信息、创建阶段和供应链流转信息，加强了清单间的互相引用，并实现最小集/扩展集的灵活应用，深度支持代码片段信息的存储及追踪，为企业用户提供整个数字供应链基础设施视角的落地治理实践。

四、DSDX协议支持的生命周期

悬镜DSDX覆盖数字供应链全场景（CreateStage），涵盖源码、二进制、镜像、预发布、发布等不同阶段的物料清单，对组件、漏洞、许可证风险全面覆盖，提供更加透明化的SBOM管理。

同样重要的是，每次资产发生变化时，例如在产品的每个版本甚至每次构建时，都应该创建一个新的 SBOM以匹配该版本的更改。

如下图所示，在应用不同的构建以及不同的阶段，都应该生成对应的SBOM清单来记录不同的清单信息。同时，在应用上线分发时，需要合并不同阶段的清单信息，包括在采购阶段引入的供应商产品的清单融合开发的情况。

在上线后，应用的运营阶段，如果有识别到新的漏洞风险，则需要出新版本更新或者打补丁，那么应用的清单信息，也需要同步更新补丁的成分信息并同步更新版本信息。

图三  应用生成SBOM的生命周期

老旧的SBOM数据可能产生反作用，做无用功的同时让研发团队产生抱怨，因此SBOM应该是跟随代码、制品动态变化的实时数据。

用户可以通过将SBOM更新的逻辑嵌入到每一次代码的变更，与代码仓库集成在代码提交或合并时重新生成；对于没有代码或者项目中存在二进制依赖的情况，CI/CD环节则更为关键，通过与jenkins等软件的集成可以实现代码发布前的审查。

五、DSDX协议价值

1. SBOM自身安全可信

软件物料清单创建者应通过加密或数字签名的方式对软件物料清单的真实性和完整性进行保证。

即使在构建阶段拥有完美的工具链和完美的SBOM 信息，攻击者也可以篡改SBOM清单的内容以隐藏它包含易受攻击或恶意组件的事实。然后，消费者检索SBOM的被篡改版本并跟丢这些危险组件。

DSDX支持向SBOM工件添加数字签名，以确保消费者可以验证其真实性和完整性。

但更糟糕的是，攻击者可能会破坏构建管道，从而能够修改创建SBOM的过程，这将导致生成了经过数字签名但被篡改的组件列表。

从“扫描”工具的角度来看，软件组件通常是一个黑匣子，可以从供应商的交付制品中分析获得的信息量可能非常有限，因为其中大部分（如 pom.xml或go.mod 文件）是在构建期间可用，但在最终交付件中删除。

悬镜源鉴SCA支持进行SBOM和交付制品的深度检测结果比较，分析成分数据与提供的SBOM数据差异，并且给出对比报告，最大限度的降低引入质量低劣的SBOM清单或管道被攻击的风险SBOM清单的可能性。

2. SBOM深度和有效性

DSDX支持描述组件的全部依赖关系，SBOM将提供这些传递依赖项的可见性。

图四  组件依赖1层和多层对比

例如如果包libfoobar-1.5.3-r3-u8是SBOM的一部分，它还应该包括用于组装libfoobar-1.5.3-r3-u8 的每个包名称、版本、许可证等，以及每个节点的组件，从而形成一个多级树，其中每个节点都分解为其依赖项。

支持记录组件包的hash指，相似文件的路径和片段以及文件hash。这些可以可以在悬镜的XSBOM知识库中进行对比关联，确认成分的分析准确有效。

有了依赖树，就可以分析组件的风险传递，一个产品中的组件依赖关系是复杂的，这导致漏洞传递的路径也是复杂的。所以准确的解析组件间依赖关系并进行SBOM传递非常重要，这是供应链上下游分析组件的真实依赖调用，漏洞的可达性分析的基石。

3. SBOM与漏洞关联

漏洞是攻击者可以利用来绕过安全边界、访问系统等的弱点或缺陷，它们是攻击或破坏软件供应链的典型方式。要查找软件（或正在运行的主机、容器镜像等）中的漏洞，需要将已知漏洞与软件中的组件信息相匹配。这就是 SBOM 发挥作用的地方，因为它包含构成软件的软件包和版本的完整列表。

但是软件生产者和消费者都注意到，并不是所有漏洞产生的威胁都是相同的，在一个上下文环境中容易受到攻击的代码在另一个上下文中可能不会受到攻击。如果上游供应商确定来自漏洞的潜在风险不可利用，他们允许将该风险信息传递给下游的其他用户，以帮助他们做出基于风险的决策。

基于此，SBOM的另一个关键元素是VEX，它作为SBOM的机器可读“辅助工件”,允许制造商将在SBOM中列出的某个软件组件中发现的漏洞的当前状态进行交流。

DSDX同样支持对VEX漏洞的兼容，因此可以消除大部分误报，解决由于实现或其他控制措施而漏洞无法利用的实例，传达制造商在缓解漏洞方面的进展情况。

通过漏洞关联和漏洞交流，供应商可以轻松地传达客户因漏洞而面临的风险或不存在风险，减少了供应商和最终用户的工作量。

4. SBOM结合风险策略排查

SBOM数据还应该可以构建完整的资产图谱，并基于谱图进行高级检索。

例如“我是否容易受到 CVE-2022-22965 ( Spring4Shell ) 漏洞的攻击？”利用此漏洞需要在运行可利用Java包的主机或容器中同时发生一组条件：

使用SpringCore版本 5.3.0 到 5.3.17、5.2.0 到 5.2.19 或更早版本，使用JDK 9 或更高版本；

使用 spring–webmvc或spring–webflux 依赖。

大多数这些情况都可以在SBOM的内容中进行检查，轻松地评估环境中的风险。

图五  SBOM消费场景–策略合规

同样的，我们可以结合企业的合规要求和安全策略配置，对SBOM进行专项和定期检查，因为SBOM本身也是动态实时变化的数据，所以我们可以在分析出不满足合规和策略时，能够基于项目、资产等不同维度对总体风险进行梳理，并触发对应的预警或者阻断等操作，使数据的消费更及时更左移。对于企业的内部治理而言，单点的工具是不够的，还需要有全局的风险视图，出现问题时帮助企业及时止损。

六、DSDX行业实践

作为国内领先的数字供应链安全专业厂商，悬镜安全为用户提供完整的基于SBOM清单管理的数字供应链安全管理解决方案，并已在大量标杆用户成功实践落地。SBOM作为数字供应链安全治理的基础性工具之一，悬镜安全是其国内最早的实践者和布道者。

悬镜安全率先在源鉴SCA商业化产品中集成了DSDX、SPDX、CycloneDX、SWID四种SBOM标准格式的自动化生成能力。在商业化的同时，悬镜安全更不忘为开源社区、广大开发者和中小企业赋能，旗下开源数字供应链安全社区OpenSCA是目前国内唯一能够完全自主化、自动化生成DSDX、SPDX格式SBOM清单的开源SCA工具。

1. SBOM清单文件生成

SBOM 的质量取决于构建 SBOM 的过程的质量和自动化程度。

生成根级别很容易，如直接构建的软件的版本和详细信息，以及直接依赖项（包和第三方库）。当在依赖树中更深入地构建时，传递依赖关系解析变得困难，因为许多组件不提供自己的SBOM，并且检测依赖关系可能很复杂，例如带有剥离信息的静态链接二进制文件。

悬镜源鉴SCA最佳实践，软件物料清单生成包括人工生成和自动化生成两种方式：

• 构建过程完全自动化并且SBOM创建被集成为构建管道的一部分;
• 人工生成，则可以灵活选择在不同节点不同的维度进行生成。
• 另外当软件组件以新版本或发布的形式更新，会自动对SBOM进行更新/追加。

支持生成SBOM阶段：应用包检测，源码仓库检测，同源溯源分析，二进制制品检测，镜像检测。

软件清单生成内容包括：

• 组件信息：组件名称、ID、厂商、组件来源、组件类型、置信度、校验码、语言、依赖关系、依赖数量、依赖路径等。
• 代码文件信息：名称、ID、校验码、路径、相似文件来源、相似度。
• 代码片段信息：来源文件ID、校验码、代码片段位置、相似代码片段来源、相似度。

软件物料清单生成深度包括：记录从根节点到叶子节点全部深度的清单，以 K-V 形式保存的项目完整依赖关系图。

软件物料清单进行软件漏洞管理：从安全漏洞出发，溯源哪些组件被影响，从应用维度出发，查看应用的SBOM的安全漏洞信息。

图六  SBOM生成和更新周期

支持导出的维度：项目维度导出，应用维度导出

支持导出的格式：每种标准格式，优先json文件格式支持

DSDX：支持格式text、json、xml

SPDX：支持格式tag:value、rdf、json、xml、yaml

SWID：支持格式cbor、json、xml

CycloneDX：支持格式json、xml

图七  源鉴SCA-SBOM生成

2. SBOM清单文件检测

扫描SBOM是必要的，因为来自供应商的SBOM可能是错误的。供应商的构建过程可能会受到影响，因此供应商SBOM可能会故意省略某些组件。

源鉴SCA支持导入SBOM文件进行机器解析，解析后进行检测，发现清单中的风险问题，并可自动或人工对全局的SBOM进行更新。 并可支持SBOM的清单对比，通过上传的SBOM清单文件解析和供应商产品的检测生成的SBOM进行对比，分析SBOM清单的准确度和风险要素。

图八 源鉴SCA-SBOM检测

3. 基于SBOM清单文件的资产管理

构建和维护SBOM信息数据要素，在满足当前解决已知风险的同时，也是在建立后续排查和梳理的软件资产清单。

源鉴SCA在资产视角上支持树结构和图谱结构，查看全局的资产信息，并进行过滤检测，查看资产之间的依赖关系，帮助企业构建软件物料清单中组件成分体系、组件的依赖关系体系，建立完整的软件与组件链路关系树，实现链路的上下游可达分析架构模型，可以准确判断风险问题引入点和影响面。

图九 源鉴SCA-SBOM资产视角

4. 基于SBOM清单资产的风险分析

要想用于风险的治理，只有基线数据字段的SBOM难以发挥它的价值，SBOM要和知识库进行联动，当SBOM发生变化或者知识库中的数据发生变化时，都应该触发风险识别逻辑。例如，当SBOM中引入了一个新的组件，需要通过知识库评估这个组件是否存在开源许可证约束、是否适合商业使用；当出现一个新漏洞，知识库收录后应该联动SBOM判断有哪些项目受到影响。

企业需要根据风险发生的可能性和严重程度来对风险进行优先级排序。如果不了解漏洞是否被利用，就不可能精确地预估其发生的可能性。

悬镜SCA基于SBOM清单结合组件库，漏洞库数据识别组件安全性和漏洞信息，包括但不限于漏洞名称、编号、描述、风险等级、可利用性、修复方案等。同时项目将VEX和SBOM结合，分析供应商关于其产品中存在的漏洞的可利用性的上下文见解和说明，企业可基于其风险容忍度来识别、分析、评估和解决网络安全威胁。

帮助企业对清单中组件的最小元素进行提取，并且通过信息整合，提供包括但不限于软件清单的组件基准信息、漏洞信息、许可证信息等。

图十 源鉴SCA-SBOM风险信息

5. 基于SBOM清单资产的事件响应

DSDX中包含了详尽的软件组成成分，安全团队可以通过DSDX分析软件风险，并进行持续监控；在有供应链安全事件发生时，安全团队也能根据DSDX快速定位第三方组件中已知漏洞的影响范围，并针对性地对修复措施进行优先级排序，加速供应链攻击事件应急响应速度。追踪漏洞修复的状态，统计时间维度漏洞的产生、修复趋势变化等。

结语：

SBOM是保护软件供应链的关键部分，也是漏洞匹配和管理的基础。

对于企业而言，SBOM是软件供应链治理中很重要的基础数据，能够帮助企业实现依赖治理、漏洞管理和开源许可证合规。SBOM背后靠的是SCA和知识库数据的支撑，想要充分发挥SBOM的作用，应该将生成工具和尽可能多的研发流程打通，做到实时更新SBOM清单，并和全面的知识库订阅数据进行实时动态关联。

随着软件消费者会使用到各类供应商提供的软件产品，这些产品通常以二进制的形式交付，相比源码识别的效果覆盖率会更低，存在的风险更难识别。此时SBOM会作为供应商准入的要求，在采购环节要求提供SBOM，并对SBOM进行审查和统一管理，SBOM变得越来越重要。

我们需要保护供应链，统一标准，并使SBOM成为构建过程的重要组成部分。以DSDX为代表的SBOM格式必将在整个供应链引入、生产、交付等关键环节的开源治理实践中发挥重要作用，悬镜安全全栈产品覆盖DSDX，针对性适配中国企业实战化应用实践场景，为供应链上下游企业用户提供安全新方案与整体建设新思路。

代码007普通

打赏 收藏 海报 链接