随着越来越多的企业和构造将他们的应用迁徙到云上，云原生技术的应用摆设和管理正在变得更加机动和高效，但也相应地引入了一些新的安全风险。
软件物料清单
正如食品行业有配料表，软件行业也有属于自己的配料表，即软件物料清单（Software Bill of Material, SBOM）。简而言之，软件物料清单就是展示软件成分的列表。现在，软件物料清单已成为紧张的基础设施，其原因在于云原生期间的应用风险面与IT技术发生了根本性的厘革。在新的IT架构下，传统的安全防御本领已经不再适用，以SBOM为代表的新一代安全管理工具便显得尤为不可或缺。
云原生期间，重大的技术厘革首先在开发模式上，从瀑布到灵敏到现在以DevOps为主的开发模式，对安全防御本领灵敏化的需求越来越强。第二在云架构上，从大型系统到SOA到微服务为主的贩卖模式使很多传统的界限防御本领不再适用。因此，基于SBOM的轻量化管理等新本领开始崭露头角。第三在代码实现上，从传统的闭源到开源到现在的混源模式，很多场景中利用开源代码的同时会调用闭源的API接口，在安全方向上需要举行特殊考虑。第四点是服务模式，从物理机到虚拟机到现在容器化为主，随之而来的是以开源组件为主的风险以及API、容器风险。
SBOM的基本定位是云原生期间应用安全风险管理的基础设施；除此之外，它还有以下几项特点：
- 是管理第三方组件风险（开源+闭源）的必备工具
- 可深度融合于DevOps应用生产模式
- 可与多种DevSecOps工具链联动强化效能（SCA、RASP、漏洞情报）
- 在云原生应用的开发端与运营端均发挥作用
SBOM现状
云原生期间的底层是依赖于开源世界而发展出来的。剥离了广泛的开源云原生基础设施以及云原生的开源软件应用，很多的云原生应用和场景都将无法实现。开源世界有个很明显的特性就是责任自负。云原生期间，做应用开发或运营时，我们自己是应用安全的第一甚至唯一责任人；这种情况下，安全性并不是开源组件供应方优先考量的方面。
悬镜安全之前发布了自己的开源工具OpenSCA，我们用它扫描了一些云原生开源基础设施，可以看到每个应用基本都有十到几十个不等的漏洞。特殊地，功能越强盛、应用越广泛的开源组件，漏洞可能就更多，由于强盛的功能通常意味着频繁的数据库存取或者第三方API交互的行为，进而产生更多的风险点。
云原生开源应用漏洞概览
Gartner认为，到2025年，全球45%的构造会受到软件供应链攻击；比2021年增长三倍。软件供应链攻击中很大也是最紧张的一部分，泉源于对第三方组件的应用漏洞的利用，比如第三方投毒等。近几年，重大的软件供应链攻击事件很多都与开源漏洞相干。
云原生期间下的软件供应链攻击
SBOM概述
SBOM是代码中全部开放源代码和第三方组件的清单。
实施 SBOM 有助于揭示整个软件供应链中的漏洞与弱点、进步软件供应链的透明度、减轻软件供应链攻击的威胁，进而增强云原生应用的安全。
通过利用 SBOM 可以帮助企业举行漏洞管理、应急相应、资产管理、允许证和授权管理、知识产权管理、合规性管理、基线建立和设置管理等。
下图为SBOM作用的一个例子。在未利用SBOM的情况下，组件漏洞爆发时，组件上卑鄙厂商由于对自身的组件资产一无所知，对漏洞绝不知情，因此无法在第一时间作出漏洞处置动作，导致该漏洞的管理存在一个非常长的不可控阶段，管理成本和风险相应增加。
而利用SBOM之后，上卑鄙的组件厂商会在第一时间知晓漏洞动态以及其对自身组件的影响范围，从而立即举行漏洞缓解及后续修复，真正做到第一时间全流程全周期的漏洞管理，有效降低风险。
SBOM作用表现
从广义的分类上看，SBOM有三种差别的利用场景：
- 软件生产商利用SBOM来帮助构建和维护他们提供的软件；
- 软件采购商利用SBOM来举行采购前参考、协商折扣和订定采购计谋；
- 软件运营商利用SBOM为漏洞管理和资产管理提供信息，管理允许和合规性，并快速辨认软件和组件依赖关系以及供应链风险。
从企业脚色类型来看，差别团队对SBOM有差别的利用需求：
- 项目团队：用于管理软件资产，在开发早期即可评估安全风险，筛选适合的组件/软件，并连续更新SBOM；
- 安全团队：通过提交的SBOM分析软件风险，并通过统一管理举行连续监控，实时相应安全事件；
- 法务团队：核查软件授权题目，避免后续公司业务自身权益受到损害。
各脚色的SBOM利用需求
SBOM实践要点
SBOM记录了软件的组件构成信息。供应商或开发者可以通过提供SBOM清单至组件漏洞信息分析平台，获取最新漏洞风险情报，安排修复并实时更新SBOM。安全运营人员可通过维护SBOM清单库，在有漏洞情报推送或供应链安全事件发生时，快速反向定位存在风险的软件，加速供应链攻击事件应急相应速度。
SBOM与风险管理实践
自动化的支持是SBOM的底层要求。SBOM作为一个列表清单，涉及的组件可能成千上万，必须要用自动化的方式来做SBOM的获取管理以及后续的匹配。
美国国家电信和信息管理局（NTIA）发布的《构建软件组件透明度：建立通用软件物料清单（SBOM）》第二版中提出：SBOM 是一个包含软件组件列表和条理依赖信息且机器可读的规范性清单。只有利用标准化格式才气做到机器可读，并保证足够的规范性。常见的三种国际通用的标准格式分别是SPDX、CycloneDX和SWID。
国际标准SBOM格式
在确定了SBOM的格式与对应的工具后，可以围绕SBOM统一安全评估标准、建立软件生命周期威胁卡点。管理流程由企业安全流程管理团队统一订定，并授权软件供应链安全评测团队举行安全评估测试、输出评估效果。通用管理流程框架如下：
围绕SBOM建立安全管理流程
轻量落地方案
应用架构模式和开发模式的转变都要求新兴的安全能力可适配新型场景。悬镜从以下三个方面提出一体化的应用安全方案，将基础情况、代码和安全能力举行整合，共同打造云原生安全场景下的应用防护能力。
软件成分分析（SCA） 技术是对软件的构成部分举行辨认、分析和追踪的技术。
SCA工具可以分析开发人员所利用的各种源码、模块、框架和库，辨认和盘货开源软件（OSS）的组件及其构成和依赖关系，并精准辨认系统中存在的已知安全漏洞或者潜在的允许证授权题目。通过SCA工具，可天生完备的 SBOM作为制品成分清单，同时建立软件构成图谱，为后续分析提供基础。将SCA工具接入DevOps流程，对编译构建环节举行卡点，可保障软件构建时所依赖组件的安全性，确保不引入存在漏洞的组件。
利用SCA工具举行制品成分分析
在此基础上，利用基于插桩技术的IAST工具，在功能测试的同时，检测是否存在高危漏洞风险，并展示漏洞触发数据流，便于修复引导。
针对随时可能爆发的未知0DAY漏洞，推荐利用运行时应用自免疫（RASP）工具实现应用自防御，通过应用的函数行为分析、上下文情境感知及热补丁技术阻断绝大部分RCE类未知漏洞攻击，举行精准有效的防护。
利用RASP实现出厂免疫
在SBOM的基础上，要办理上线后运营阶段的安全题目、实现安全研发和运营的闭环，不能仅仅局限于单个的SCA工具，而需要与其他更适配连续运营场景的工具结合，形成整体联动的办理方案。
需建立常态化利用和运营安全可信的制品库，通过SCA和SBOM连续为每个应用步伐构建详细的软件物料清单，全面洞察每个应用软件的组件情况；同时利用IAST对API举行风险分析及调用威胁阻断；再加上RASP热补丁及攻击防御能力配合开源漏洞情报，第一时间发现并处理开源漏洞风险，构建云原生期间应用风险管理全流程。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
