现代软件都是组装的而非纯自研。随着开源组件在数字化应用中的使用比例越来越高,混源开发已成为当前业内主流开发方式。开源组件的引入虽然加快了软件开发效率,但同时将开源安全问题引入了整个软件供应链。软件组成成分的透明性成为软件供应链安全保障的基础,SBOM(Software Bill of Materials,软件物料清单)作为软件供应链安全治理的重要抓手,其在行业的应用实践速度明显加快。
供应链(Supply Chain)指生产及流通过程中,涉及将产品或服务提供给最终用户活动的上游与下游企业所形成的网链结构,即将产品从商家送到消费者手中整个链条。供应链的活动是指将自然原材料不断组装成消费者需要的成品的过程,描绘了产品供给关系。整个供应链系统涉及到人员、组织、材料、数据等。
软件供应链的定义由传统供应链概念扩展而来,指软件生命周期中从需求、设计、开发、构建、打包、发布、采购、部署、运维、下线到销毁整个链路,通常涉及软件生产者(供应商/上游)、软件使用者(消费者/下游)以及软件运营者(公司或者企业)三个方面。
软件供应链安全则是和针对软件供应链的攻击有关。攻击者通过网络工具、下载投毒、代码污染、漏洞利用、授权流氓等手段在软件供应链各个活动环节中,对企业业务系统进行破坏性操作。近几年比较严重的软件供应链安全事件有SolarWinds(太阳风暴)攻击、Realtek WiFi SDK漏洞、Apache Log4j2漏洞等。
软件供应链过程风险治理,主要包括软件来源管理、软件安全合规性管理、软件资产管理、服务支持及安全应急响应,目的是提升软件供应链可追溯性和透视性。其中重点的治理内容,包括软件资产的第三方组件威胁审查、软件安全合规性管理。
图1 软件供应链治理重点区域
为了帮助企业有效解决软件供应链安全问题,SBOM作为软件供应链安全关键的技术工具之一,能够达到统一描绘软件资产信息格式、协助对采购软件和自研软件风险评估、形成软件供应链活动中传递的软件信息接口标准。
早期SBOM的概念源自制造业,其中物料清单BOM是用来详细说明产品中包含的所有项目的清单。例如在汽车行业,制造商为每辆车提供一份详细的物料清单,列出原始设备制造商制造的部件以及来自第三方供应商的部件。当发现有缺陷的部件时,汽车制造商可以准确地知道哪些车辆受到影响,进而通知车主维修或更换。软件物料清单SBOM则是用来描述软件产品中包含的组件物料信息,示例如下:
图2 SBOM示例
但随着供应链安全事件的升级,2021年7月12日美国在关于改善国家网络安全的行政命令(EO 14028第10节)中将SBOM定义为“包含构建软件中使用的各种组件的详细信息和供应链关系的正式记录”。软件开发商和供应商通常通过组装现有的开源和商业软件组件来创建产品,新的定义将软件供应链关系纳入记录范围。
图3 组件关系图示
图4 NTIA《The Minimum Elements For a Software Bill of Materials (SBOM)》
美国NTIA(National Telecommunications and Information Administration,国家电信和信息管理局)2021年7月发布了SBOM所包含的最小必需元素。这些元素包含以下三类:
SBOM最小必需元素描述了实践过程中需要的元素最小集,相关组织和机构可通过参考以上三类元素,并扩展企业自身需要管理的额外信息,构成适合自身的标准SBOM清单。从国内开源组件管理要求和软件全生命周期风险角度分析,推荐适合扩展数据字段如下:
目前SBOM主要通过三种格式来进行实施:
1.SPDX
SPDX是一种国际开放标准(ISO/IEC 5962:2021)格式,包含与软件包相关的组件、许可证、版权和安全参考信息。SPDX标准由Linux基金会主办的草根开源项目开发,目前维护到最新2.3版本,特点是对许可证的详细信息支持较好,主要输出文件格式包括RDF、XLS、SPDX、YAML、JSON。
SPDX Lite是SPDX的轻量级子集,适用于不需要完整SPDX的场景,旨在让没有开源许可知识或经验的人易于使用,用于平衡SPDX标准与某些行业工作流程实际需求。
2.CycloneDX
CycloneDX专为安全环境和供应链组件分析而构建,是一种轻量级SBOM标准,可用于应用程序安全上下文和供应链组件分析。CycloneDX源于OWASP社区的开源项目,由提供战略方向和标准维护的核心团队指导。目前最新维护到1.4版本,可扩展格式并集成SPDX许可证ID、pURL和其他外部标识符,主要输出格式包括XML、JSON。
3.SWID
SWID是一个标准化的XML格式,可以识别软件产品的组成部分并将其与上下文结合,记录有关软件组件的唯一信息,如产品名称、版本详细信息等。SWID标签在SDLC发布后添加作为软件产品的一部分,在软件安装时将标签信息添加到系统终端,并在产品卸载后自动删除。
1)从广义的分类上看,SBOM有三种不同的使用场景:
〇 软件生产商使用SBOM来协助构建和维护他们提供的软件;
〇 软件采购商使用SBOM来进行采购前参考、协商折扣和制定采购策略;
〇 软件运营商使用SBOM为漏洞管理和资产管理提供信息,管理许可和合规性,并快速识别软件和组件依赖关系以及供应链风险。
2)从企业角色类型来看,对SBOM有不同的使用需求:
〇 项目团队:用于管理软件资产,在开发早期即可评估安全风险,筛选适合的组件/软件,并持续更新SBOM;
〇 安全团队:通过提交的SBOM分析软件风险,并通过统一管理进行持续监控,及时响应安全事件;
〇 法务团队:核查软件授权问题,避免后续公司业务自身权益受到损害。
图5 企业管理角色SBOM使用需求
企业级SBOM为便于统一管理,应该使用一致的格式,如前文所述的SPDX、SWID和OWASP CycloneDX。美国2021发布的行政命令并未强制要求企业使用SBOM的哪种特定格式。到目前为止,并没有对比出这三者中哪一种格式是最好的,也没有确定的行业标准限定一定使用哪种格式。大多数SBOM工具,会捆绑代码安全扫描程序和其他程序,企业需要根据自身需求选型。以下提供对于选择SBOM工具的一些建议。
Gartner建议了生成SBOM的工具应当具有的能力:
〇 可融入构建过程,可自动创建SBOM;
〇 可分析源代码和二进制文件(如容器镜像);
〇 对检测的组件进行SCA检测生成SBOM;
〇 可对生成的SBOM进行编辑;
〇 以可读的格式查看、比较、导入和验证SBOM;
〇 可合并多个SBOM的内容,并可将其从一种格式或文件类型转换为另一种格式或文件类型;
〇 支持通过API和库让其他工具使用SBOM并进行操作。
当SBOM被重新定义后,SBOM具有更高的透明度、具体来源和传播效率,企业机构在一定条件下通过SBOM即可识别和修复漏洞风险。且SBOM还可以指导开发人员或供应商在整个SDLC中进行应用安全软件开发实践。以下说明了SBOM如何在SDLC中完成组装的过程,供实践人员进行参考:
图6 《软件生命周期和物料清单装配线的说明示例》
注:物料(Material)、元数据(Metadata)、引用(Reference)、供应商(Supplier)、使用方(Consumer)、Example Bom fragment(片段示例)
SDLC各阶段SBOM装配内容及方式说明:
SBOM装配过程通过人为维护工作量较为巨大,建立元数据信息库,并借助SCA检测工具将装配融入CI/CD流程中,可大大降低实施难度。
SBOM记录了软件的组件组成信息,供应商或开发者可以通过提供SBOM清单至组件漏洞信息分析平台,获取最新漏洞风险情报从而进行修复和更新SBOM。并且安全运营人员可通过维护SBOM清单库,在有漏洞情报推送或供应链安全事件发生时,快速反向定位存在风险的软件,从而加速了供应链攻击事件应急响应速度。
图7 使用SBOM生成软件风险信息
在确定了SBOM的格式与对应的工具后,可围绕SBOM统一安全评估标准建立软件生命周期威胁卡口。管理流程由企业安全流程管理团队统一制定,并授权软件供应链安全评测团队进行安全评估测试,输出评估结果。其通用管理流程框架如下:
图8 围绕SBOM建立安全管理流程
1.建立基线
根据已清点的资产,进行白名单、黑名单组件基线建立,指导后续组件选用;
2.安全设计评估
在项目进行需求设计时、安全评审阶段,对选用的第三方组件进行风险评估,并依据白名单、黑名单组件基线选用安全组件;
3.应用安全测试
除了对组件风险进行管控外,在应用上线、发布过程中,对应用系统进行应用安全测试,发现存在的应用漏洞威胁;
4.CI/CD缺陷修复&跟踪
将发现的风险接入CI/CD缺陷修复&跟踪平台,如Jira、禅道等,提前修复缺陷并更新SBOM中应用漏洞风险信息;
5.产品制品发布
发布产品制品时,同时生成SBOM。经过安全管理流程对软件和软件SBOM进行安全评测,出具安全测试报告。
随着供应链攻击检测要求加入HW攻击演练评分中,软件供应链安全建设愈发受到重视。当前软件供应链安全治理的落地主要考虑第三方开源组件的治理,主要通过SCA工具及相关治理办法,对软件引入的第三方开源组件进行威胁检测和管理。广义上的软件供应链安全治理则需要扩展治理范围至完整软件生命周期、供营商管理、自动化流程建设,且具备持续运维监控、应急响应能力等。
SBOM主要价值在于帮助企业组织提高软件透明性,并且形成在软件供应链环节中便于交换传递的接口标准,同时能够描绘软件资产信息。在解决软件资产管理“看不清”和“跟不上”的主要痛点上,将SBOM作为软件资产管理能力基础,围绕SBOM建立较为完善的软件供应链治理体系。成熟的SCA工具应当兼容多种SBOM格式,可导入不同供应商提供的不同格式SBOM,并对不同格式SBOM进行转换和集中管理,且便于融入到自动化流程。悬镜源鉴SCA在满足以上SBOM能力需求的基础上,也在开源OpenSCA提供了公开SBOM生成工具,方便软件生产商自动生成SBOM清单。
网络安全的本质是风险与信任的平衡,软件供应链安全治理的本质则是安全可信的持续传递。悬镜安全在“用开源的方式做开源风险治理”理念的指导下,凭借多年沉淀的“All In One”智能代码疫苗技术,为广大数字化应用提供威胁免疫安全基因,并通过旗下全球极客开源安全社区OpenSCA及其商业版源鉴SCA、灵脉IAST等软件供应链安全核心产品,从源头追踪软件供应链在开发、测试、部署、运营等关键环节面临的应用安全风险与未知外部威胁,帮助企业用户逐步构筑一套适应自身业务弹性发展、面向敏捷业务交付并引领未来架构演进的共生积极防御体系。
感谢每一位开源社区成员对OpenSCA的支持和贡献。
OpenSCA的代码会在GitHub和Gitee持续迭代,欢迎Star和PR,成为我们的开源贡献者,也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目,敬请期待更多功能的支持。
GitHub:
https://github.com/XmirrorSecurity/OpenSCA-cli/releases
Gitee:
https://gitee.com/XmirrorSecurity/OpenSCA-cli/releases
OpenSCA官网:
https://opensca.xmirror.cn/