专栏特辑丨悬镜浅谈开源风险治理之SBOM与SCA
随着容器、微服务等新技术日新月异，开源软件成为业界主流形态，软件行业快速发展。但同时，软件供应链也越来越趋于复杂化和多样化，软件供应链安全风险不断加剧。
软件供应链安全主要包括软件开发生命周期和软件生存运营周期，且与软件开发过程中的开发人员、环境、工具等因素密切相关。推进针对软件生命周期进行全流程安全管控的落地实践，有助于从软件生命周期的源头保障软件供应链安全。
一、战略抉择驱动：始于对关键环节可见性的持续构建
软件供应链安全始于对关键环节的可见性，企业需要为每个应用程序持续构建详细的SBOM（软件物料清单），从而全面洞察每个应用软件的组件情况。SBOM是描述软件包依赖树的一系列元数据，包括供应商、版本号和组件名称等多项关键信息，这些信息在分析软件安全漏洞时发挥着重要作用。
表1是一份软件物料清单示例，其中SPDX（软件包数据交换）和SWID（软件标识）是两种国际通用的SBOM字段标准。
SPDX用于交流软件物料清单信息，包括组件、许可证、版权等信息，通过为公司和社区共享重要数据提供通用格式来减少冗余工作，从而简化流程并提高合规性。
SWID标签旨在为组织提供一种透明的方式来跟踪在他们的托管设备商安装的软件，该标签文件包含有关软件产品特定版本详尽的描述性信息。除表格中的两种应用最为广泛的SBOM字段标准外，还有CycloneDX、CoSWID、CPE、Grafeas等其他较为常见的标准，各标准应用场景存在一定区别。
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重点引入了运行环境信息、创建阶段和供应链流转信息，加强了清单间的互相引用，并实现最小集/扩展集的灵活应用，深度支持代码片段信息的存储及追踪，为企业用户提供整个数字供应链基础设施视角的落地治理实践。
构建软件的企业需要维护准确、最新的 SBOM，其中包括第三方和开源组件的清单，以确保其代码质量高、合规且安全。企业通过要求软件供应商提供 SBOM，以发现潜在的安全和许可证问题，或者应用程序是否使用过时的库版本。
当发现此类问题时，管理员可以要求供应商使用较新版本重建应用程序，在等待更新的软件期间，安全人员有机会采取临时缓解措施来保护应用程序免受攻击者利用该漏洞进行攻击，还可以帮助安全人员在漏洞被披露或核心库发布新版本时，对应用程序和代码进行抽查以避免出现安全问题。
二、速度创造价值：SBOM对漏洞风险治理实践的影响
SBOM的使用可以为软件供应链的漏洞治理节省大量时间。以往，企业在修复已部署系统的漏洞缺陷时往往需要几个月甚至是数年的时间，其重要原因是企业无法在漏洞出现的第一时间知晓该信息。软件供应链下游的企业需要等待上游软件供应商完成软件补丁，才可以进行漏洞修复，在等待的时间内，下游企业往往会面临无法预知的安全风险。而构建详细准确的SBOM则可以避免这一现象的发生，允许所有利益相关者在漏洞发现时立即开始评估漏洞，并开始制定相关的补救措施。
受感染的开源组件在软件中未被修复的每一分钟都会增加潜在被利用的风险，SBOM 有助于企业在漏洞披露的早期对漏洞进行识别，通过提供受感染开源组件和依赖项的准确位置，为企业在风险分析、漏洞管理和补救过程中节省数百小时至数月的时间。SBOM 有助于揭示整个软件供应链中的漏洞与弱点，提高软件供应链的透明度，减轻软件供应链攻击的威胁，还可以帮助企业进行漏洞管理、应急响应、资产管理、许可证和授权管理、知识产权管理、合规性管理、基线建立和配置管理等。
三、勤于思、敏于行：基于SCA技术工具及时响应
企业需要谨慎、合理地选择、获取和使用第三方闭源组件和开源组件。软件安全团队或研发团队通过必要的技术手段确保所使用的第三方组件的安全性，及时获取所使用第三方组件和开源组件的漏洞情报，并适时做出响应。
软件成分分析（SCA）是一种对二进制软件的组成部分进行识别、分析和追踪的技术。SCA可以生成完整的SBOM，分析开发人员所使用的各种源码、模块、框架和库，以识别和清点开源软件的组件及其构成和依赖关系，并精准识别系统中存在的已知安全漏洞或者潜在的许可证授权问题，把这些安全风险排除在软件的发布上线之前，也适用于软件运行中的诊断分析。
SCA分为静态和动态两种模式。静态模式是使用工具对目标工程文件进行解压，识别和分析各个组件的关系；动态模式则是依赖于执行过程，在程序执行的同时收集必要的活动元数据信息，通过数据流跟踪的方式对目标组件的各个部分之间的关系进行标定。
使用基于多源SCA开源应用安全缺陷检测技术的安全审查工具，可以精准识别应用开发过程中软件开发人员有意或违规引用的开源第三方组件，并通过对应用组成进行分析，多维度提取开源组件特征，计算组件指纹信息，深度挖掘组件中潜藏的各类安全漏洞及开源协议风险。
Apache log4j 2漏洞，因其严重性和广泛性的影响而被业界称为“核弹级”漏洞，同时也使得开源安全及软件供应链安全治理相关话题再次成为热点。
开源安全作为软件供应链安全的重要环节以及面临的已知或未知的安全风险，更让业界意识到开源安全治理已是迫在眉睫。通过引入SCA工具以保证软件供应链安全，在软件开发的需求阶段、编码阶段、构建集成、软件测试等相应阶段使用SCA，将开源组件安全检测和合规检测融入到企业开发测试流程中，可以帮助企业以最小代价落地开源安全保障体系，降低软件安全问题的修复成本，保障开源软件供应链安全。
悬镜安全率先在源鉴SCA商业化产品中集成了DSDX、SPDX、CycloneDX、SWID四种SBOM标准格式的自动化生成能力。在商业化的同时，悬镜安全更不忘为开源社区、广大开发者和中小企业赋能，旗下开源数字供应链安全社区OpenSCA是目前国内能够完全自主化、自动化生成DSDX、SPDX格式SBOM清单的开源SCA工具。