在本次技术沙龙上，来自不同领域和企业的安全专家聚焦云原生生态，分享了云原生安全的最佳实践和解决方案。悬镜安全COO董毅应主办方的邀请，发表了题为“以SBOM为基础的云原生应用安全治理”的演讲。

图1 悬镜董毅在KCD 2023云安全技术沙龙上发表主题演讲

以下为演讲实录：

软件物料清单

正如食品行业有配料表，软件行业也有属于自己的配料表，即软件物料清单（Software Bill of Material, SBOM）。简而言之，软件物料清单就是展示软件成分的列表。如今，软件物料清单已成为重要的基础设施，其原因在于云原生时代的应用风险面与IT技术发生了根本性的变革。在新的IT架构下，传统的安全防御手段已经不再适用，以SBOM为代表的新一代安全治理工具便显得尤为不可或缺。

云原生时代，重大的技术变革首先在开发模式上，从瀑布到敏捷到现在以DevOps为主的开发模式，对安全防御手段敏捷化的需求越来越强。第二在云架构上，从大型系统到SOA到微服务为主的销售模式使很多传统的边界防御手段不再适用。因此，基于SBOM的轻量化管理等新手段开始崭露头角。第三在代码实现上，从传统的闭源到开源到现在的混源模式，很多场景中使用开源代码的同时会调用闭源的API接口，在安全方向上需要进行特殊考虑。第四点是服务模式，从物理机到虚拟机到现在容器化为主，随之而来的是以开源组件为主的风险以及API、容器风险。

SBOM的基本定位是云原生时代应用安全风险治理的基础设施；除此之外，它还有以下几项特点：

• 是治理第三方组件风险（开源+闭源）的必备工具
• 可深度融合于DevOps应用生产模式
• 可与多种DevSecOps工具链联动强化效能（SCA、RASP、漏洞情报）
• 在云原生应用的开发端与运营端均发挥作用

SBOM实践现状

根据Anchore《2022软件供应链安全报告》，尽管SBOM在云原生应用可见性方面发挥着基础性作用，只有三分之一的组织正在遵循SBOM最佳实践。

图2 Anchore《2022软件供应链安全报告》

去年悬镜发布的《DevSecOps行业洞察报告》中显示，只有3%的受调者使用了SBOM；可见SBOM作为一种安全管理手段，在应用实践上还有很大的发展空间。

图3 悬镜《2022 DevSecOps行业洞察报告》

一方面，实践侧SBOM的应用度明显不足；另一方面，监管侧目前的准备又如何呢？

云原生时代的底层是依赖于开源世界而发展出来的。剥离了广泛的开源云原生基础设施以及云原生的开源软件应用，很多的云原生应用和场景都将无法实现。开源世界有个很显著的特征就是责任自负。云原生时代，做应用开发或运营时，我们自己是应用安全的第一甚至唯一责任人；这种情况下，安全性并不是开源组件供应方优先考量的方面。

悬镜安全之前发布了自己的开源工具OpenSCA，我们用它扫描了一些云原生开源基础设施，可以看到每个应用基本都有十到几十个不等的漏洞。特别地，功能越强大、应用越广泛的开源组件，漏洞可能就更多，因为强大的功能通常意味着频繁的数据库存取或者第三方API交互的行为，进而产生更多的风险点。

图4 云原生开源应用漏洞概览

Gartner认为，到2025年，全球45%的组织会受到软件供应链攻击；比2021年增长三倍。软件供应链攻击中很大也是最重要的一部分，来源于对第三方组件的应用漏洞的利用，比如第三方投毒等。近几年，重大的软件供应链攻击事件很多都与开源漏洞相关。

图5 云原生时代下的软件供应链攻击

SBOM概述

SBOM是代码中所有开放源代码和第三方组件的清单。

实施 SBOM 有助于揭示整个软件供应链中的漏洞与弱点、提高软件供应链的透明度、减轻软件供应链攻击的威胁，进而增强云原生应用的安全。

通过使用 SBOM 可以帮助企业进行漏洞管理、应急响应、资产管理、许可证和授权管理、知识产权管理、合规性管理、基线建立和配置管理等。

下图为SBOM作用的一个例子。在未使用SBOM的情况下，组件漏洞爆发时，组件上下游厂商因为对自身的组件资产一无所知，对漏洞毫不知情，因此无法在第一时间作出漏洞处置动作，导致该漏洞的治理存在一个非常长的不可控阶段，管理成本和风险相应增加。

而使用SBOM之后，上下游的组件厂商会在第一时间知晓漏洞动态以及其对自身组件的影响范围，从而立刻进行漏洞缓解及后续修复，真正做到第一时间全流程全周期的漏洞管理，有效降低风险。

图6 SBOM作用示意

从广义的分类上看，SBOM有三种不同的使用场景：

• 软件生产商使用SBOM来协助构建和维护他们提供的软件；

• 软件采购商使用SBOM来进行采购前参考、协商折扣和制定采购策略；

• 软件运营商使用SBOM为漏洞管理和资产管理提供信息，管理许可和合规性，并快速识别软件和组件依赖关系以及供应链风险。

从企业角色类型来看，不同团队对SBOM有不同的使用需求：

• 项目团队：用于管理软件资产，在开发早期即可评估安全风险，筛选适合的组件/软件，并持续更新SBOM；

• 安全团队：通过提交的SBOM分析软件风险，并通过统一管理进行持续监控，及时响应安全事件；

• 法务团队：核查软件授权问题，避免后续公司业务自身权益受到损害。

图7 各角色的SBOM使用需求

SBOM实践要点

• SBOM与风险情报关联

SBOM记录了软件的组件组成信息。供应商或开发者可以通过提供SBOM清单至组件漏洞信息分析平台，获取最新漏洞风险情报，安排修复并及时更新SBOM。安全运营人员可通过维护SBOM清单库，在有漏洞情报推送或供应链安全事件发生时，快速反向定位存在风险的软件，加快供应链攻击事件应急响应速度。

图8 SBOM与风险管理实践

• 拥抱自动化

自动化的支持是SBOM的底层要求。SBOM作为一个列表清单，涉及的组件可能成千上万，必须要用自动化的方式来做SBOM的获取管理以及后续的匹配。

• 使用标准化格式

美国国家电信和信息管理局（NTIA）发布的《构建软件组件透明度：建立通用软件物料清单（SBOM）》第二版中提出：SBOM 是一个包含软件组件列表和层次依赖信息且机器可读的规范性清单。只有使用标准化格式才能做到机器可读，并保证足够的规范性。常见的三种国际通用的标准格式分别是SPDX、CycloneDX和SWID。

图9 国际标准SBOM格式

• 围绕SBOM建立管理流程

在确定了SBOM的格式与对应的工具后，可以围绕SBOM统一安全评估标准、建立软件生命周期威胁卡点。管理流程由企业安全流程管理团队统一制定，并授权软件供应链安全评测团队进行安全评估测试、输出评估结果。通用管理流程框架如下：

图10 围绕SBOM建立安全管理流程

轻量落地方案

应用架构模式和开发模式的转变都要求新兴的安全能力可适配新型场景。悬镜从以下三个方面提出一体化的应用安全方案，将基础环境、代码和安全能力进行整合，共同打造云原生安全场景下的应用防护能力。

• 源头检测

软件成分分析（SCA） 技术是对软件的组成部分进行识别、分析和追踪的技术。

SCA工具可以分析开发人员所使用的各种源码、模块、框架和库，识别和清点开源软件（OSS）的组件及其构成和依赖关系，并精准识别系统中存在的已知安全漏洞或者潜在的许可证授权问题。通过SCA工具，可生成完整的 SBOM作为制品成分清单，同时建立软件构成图谱，为后续分析提供基础。将SCA工具接入DevOps流程，对编译构建环节进行卡点，可保障软件构建时所依赖组件的安全性，确保不引入存在漏洞的组件。

图11 使用SCA工具进行制品成分分析

在此基础上，使用基于插桩技术的IAST工具，在功能测试的同时，检测是否存在高危漏洞风险，并展示漏洞触发数据流，便于修复指导。

• 出厂免疫

针对随时可能爆发的未知0DAY漏洞，推荐使用运行时应用自免疫（RASP）工具实现应用自防御，通过应用的函数行为分析、上下文情境感知及热补丁技术阻断绝大部分RCE类未知漏洞攻击，进行精准有效的防护。

图12 使用RASP实现出厂免疫

• 持续运营

在SBOM的基础上，要解决上线后运营阶段的安全问题、实现安全研发和运营的闭环，不能仅仅局限于单个的SCA工具，而需要与其他更适配持续运营场景的工具结合，形成整体联动的解决方案。

需建立常态化使用和运营安全可信的制品库，通过SCA和SBOM持续为每个应用程序构建详细的软件物料清单，全面洞察每个应用软件的组件情况；同时使用IAST对API进行风险分析及调用威胁阻断；再加上RASP热补丁及攻击防御能力配合开源漏洞情报，第一时间发现并处理开源漏洞风险，构建云原生时代应用风险治理全流程。

以上是本次分享的全部内容。

感谢每一位开源社区成员对OpenSCA的支持和贡献。我们鼓励更多伙伴参与到OpenSCA开源项目的建设中来，成为开源贡献者，有任何建议都可以发在评论区或者Gitee、GitHub上OpenSCA项目的Issues中。让我们一起拥抱开源，共筑开源安全生态，促进开源产业健康发展。

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/