软件成分分析技术介绍

软件成分分析技术介绍

1.关于软件成分分析

SCA,Software Composition Analysis,软件成本分析是一种对二进制软件的组成部分进行识别、分析和追踪的技术。在开源软件日益盛行的今天,开源安全威胁成为企业组织无法回避的话题,与此同时,应用交付规模和频率的正在快速增长,软件成分分析对于安全合规风险管控和安全态势感知都是必不可少的能力。

2.基本原理

SCA 的目标是第三方基础组件/可执行程序/源代码等类型的以二进制形式存储的文件,包括但不限于源代码片段或 Package,可执行的二进制组件/程序,基础 lib,tar/tgz 压缩文件,镜像/镜像层,广义的软件构建过程等等。因此,所有以二进制形式存储的文件皆可以是其分析目标。

SCA 的方法不局限于具体的软件开发语言技术栈,即不关注是 Java、Python、C/C++、Golang 或者是 Node,还是 Docker(OCI)Image ,或者是广义的构建过程,而是从文件层面关注目标的各组成文件本身,以及文件与文件之间的关联关系以及彼此组合成目标的过程细节。简而言之,SCA 是一种跨开发语言的二进制文件分析技术。

软件成分分析分为两种模式,静态和动态。静态模式是使用工具对目标二进制文件进行解压,识别和分析各个部分的关系;动态模式则是依赖于活动过程,在活动执行的同时收集必要的活动元数据信息,通过数据的方式对目标组件各个部分之间的关系进行标定。动态模式主要针对组件缺乏自描述信息的场景,如 tgz 文件,而静态模式比较适合有自描述信息的文件,如 docker image。

在这里插入图片描述

3.用户场景

3.1 软件版本收敛治理

当某个软件作为镜像交付的一部分发布到线上运行时,如我们常用的 mysql-connector 客户端,它的软件版本也是会随着时间而不停地迭代出新版本,老版本将不再被支持。这些组件久而久之就容易被恶意破坏者盯上,从而利用一些在新版本中已经修复,但是老版本中依然存在的漏洞发起攻击,从而带来数据泄露的高危风险。由于这些老旧版本已经不再被支持,因此,解决问题主要依靠业务方自身的力量,由于缺乏专业的背景知识,解决成本总是居高不下。
此时,软件研发组织需要通过如下解决方案来及时治理过期的软件版本:
1)建立研发组织软件供应链跟踪机制
在治理之前,我们必须清晰地知道研发组织使用了哪些软件供应链?这些供应链分别是什么?这里的是什么我们可以从多个维度去看,比如开发语言类型,Java/NPM/Golang/CPP/Python;镜像、组件依赖、系统软件、用户自定义等等。基于企业现有的安全、合规扫描能力,对供应链的威胁类型、风险等级进行标识。在用户使用这些供应链进行开发、交付和分发时,将相关的风险信息告知用户。
2)建立基于供应链元数据的分析能力
供应链本身是一个二进制,用户默认使用名称进行识别,这就像我们喊一个人的名字是一样的。但是,在我们进行收敛管理的时候,就需要基于元数据来定位了。比如,我们需要使用我们需要使用不依赖过期版本软件的组件。
这里的分析能力主要包含 2 个部分:首先,分析某个供应链的静态链路关系,即我依赖谁、谁依赖了我。其次,对某个具体的供应链组件,能够分解到最小颗粒度的对象,识别对象中具体有什么。
在这里插入图片描述

3)研发平台提供交付管控能力
在研发平台进行流程推进时,对版本不合规供应链进行识别,然后提供流程阻断能力,这样的阻断能力能够有效防止携带不合规版本供应链的镜像发布到线上。

3.2 应用安全风险治理

大致的流程如上,区别在于这里需要安全扫描能力为供应链标注高、中、低危风险等级。

3.3 业务中台 SPI 治理

近些年业务中台的概念非常火,大家都在积极投入建设中台。业务中台的能力是通过业务 SPI Bundle 的方式提供给场景方调用的,随着业务中台能力的逐渐丰富,SPI Bundle 版本也会随之不断迭代,某些版本已经老旧或者存在安全漏洞也需要进行治理。
于是,我们就出现了 3.1 中的供应链治理诉求。

4.相关产品

目前商业化的产品都是偏工具性质的,距离企业级平台产品差距还是比较大。在开源领域 Google 提出的基于 Grafeas + Kirits 的模型是最符合云原生的、高度可扩展的。
在这里插入图片描述

5.更多资料

开源容器安全工具 Grafeas
https://www.oschina.net/p/grafeas

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页