浅谈软件成分分析（SCA）在企业开发安全建设中的落地思路

前言

开源软件具有开放、共享、自由等特性，在软件开发中扮演着越来越重要的角色，也是软件供应链的重要组成部分。根据Gartner调查显示，99%的组织在其 IT系统中使用了开源软件。而来自Sonatype公司的一项调查则显示，在参与调查的3000家企业中，每年每家企业平均下载 5000个开源软件。

开源代码的使用大幅度提高软件研发效率、缩短上市时间、降低开发成本，但是开源软件中存在的大量缺陷、甚至安全漏洞也一并进入了软件部署包，为软件带来巨大的安全风险。

根据国外安全机构的调研报告显示，企业应用代码超过80%来自第三方资源库或第三方组件，97%的java程序至少存在1个已知安全漏洞，而由第三方代码缺陷导致的信息泄露漏洞占比高达72%。

而国内企业的应用系统也存在同样的问题，比如漏洞频发的Fastjson库，攻击者可利用其反序列化漏洞，远程命令执行入侵到企业服务器，通过服务器执行命令，危害性极大。类似的还有jackson、shiro、Struct2,、OpenSSL等。

为了解决这类问题，软件成分分析（SCA）应运而生。

SCA

什么是SCA？

SCA，Software Composition Analysis，软件成本分析是一种对二进制软件的组成部分进行识别、分析和追踪的技术。

2019年，Gartner在报告中把SCA纳入AST技术领域范围，从而形成了包含SAST、DAST、IAST和SCA的应用软件安全测试技术体系，并正式发布了有关软件成分分析（SCA）的技术洞察报告。其中，对软件成分分析技术进行了准确定义：软件成分分析产品通常在开发过程中对应用程序进行分析，以检测开源软件组件是否带有已知的漏洞，例如具有可用安全补丁程序的过期库，以及需要相应授权许可（法律风险）的商业软件或第三方产品。

SCA致力于确保企业软件供应链的安全，从而支撑安全的应用程序开发和组装。

为什么要做SCA

调查显示，平均每个应用有七成以上的代码通过调用第三方组件实现，然而大部分用户对于第三方组件存在的安全问题并未重视起来，因此，解决软件成分中第三方组件的安全问题迫在眉睫，软件成分分析（SCA，Software Composition Analysis）应运而生。

在2013年OWASP发布的OWASP-TOP-10中，风险清单添加了2013-A9“使用含有已知漏洞的组件”风险，其实该风险早在2010-A6“安全配置错误”风险中即有所提及，但随着时间的推移，在开发过程中越来越多的应用直接使用带有已知漏洞的组件部分，因此成为了一类单独的风险持续至今。

SCA致力于解决什么问题

应用第三方组件中的已知漏洞。第三方组件中本身存在的漏洞，攻击者可以利用这些已知的漏洞，对应用系统进行攻击破坏。

第三方组件的软件许可问题。这方面主要是分析调用的第三方组件的许可证类型。目前，国际公认的开源许可证共有80多种。有的许可证对软件的使用方式几乎没有限制，用户几乎不用关心需要承担的责任，但是也存在一些限制性比较强的许可证，如果不小心调用，可能会带来较大的法律风险和知识产权的损失。

第三方组件中的恶意代码问题。这方面的问题不算普遍，但是危害也比较大。风险的来源主要是在非正规渠道获取被篡改的第三方组件，或使用了恶意开发者提供的第三方组件，未经确认就引入开发的业务系统中会带来极大风险。

引用版本过旧的第三方组件。版本过旧从表面来看，跟安全好像关系不大，但是仔细想想，比较老旧的第三方组件有可能会存在一些未知的、开发者没有公布的、且已修复的0day，所以这方面可以当作是不重要不紧急的风险来对待。

怎么做？

第三方组件其实需要我们像对待业务资产一样的程度去重视。梳理下来针对这块的管控主要有以下几种方式：

定期在项目中检查引用的第三方组件

这是性价比非常高的方式，可以直接解决项目中实际存在的问题。在开发或测试阶段主动对所用到的组件进行定期安全检查，分析出引用的组件名称及版本，梳理出来该项目第三方组件清单，将这些信息在开源或商业的漏洞数据库中进行匹配，发现问题及时整改。目前市面上基本所有的SCA类工具都具备该能力。主流的做法是分析引用的三方组件名字、版本、MD5等，通过匹配漏洞库中组件和漏洞的对应关系确定引用的第三方组件是否有漏洞，这种做法简单有效，能够解决大部分问题，适用于场景广泛。

但是讲个题外话，这种做法并未实际检测漏洞是否在现应用中真实存在。例如某第三方组件确实存在已知漏洞，但是代码实际引用并未引入该风险，这就增加了安全部门与开发部门的矛盾，安全说你这个有漏洞，得换新版本，但是开发说我并没有用那个功能呀，不行你验证给我看。。。

对第三方组件库进行安全巡检

一般开发团队针对不同的编码语言，都会维护相应的开源组件库，比如Java语言常用的maven组件库，通过定期盘点组件库中组件的名称及版本，针对梳理出来的组件信息，比照开源或商业的漏洞数据库，盘点出当前组件库中组件的安全信息，形成一个组件安全信息库，定期对不安全的组件进行清理或升级。

1day漏洞应急

每当有第三方组件安全漏洞信息披露出来的时候，针对前面已梳理出来的各项目第三方组件清单，可以立即做出判断，了解自己的应用是否调用该1day漏洞组件，是否受此次漏洞披露的影响。

从源头卡住不安全组件的入口

这里主要是针对第三方组件入库时做一个检测，检测内容包括三方组件完整性、安全性、合规性。完整性是指校验即将入库的组件MD5，主要是为规范第三方组件来源渠道，避免下载到被篡改的三方组件。安全性是指检查即将入库的组件是否存在许可证或漏洞问题。合规性是指检查即将入库的组件开源许可证是否适用当前开发项目。

借助工具实现检测维护的自动化

如果想要识别组件库以及项目中的第三方组件及其版本号，并且还要对其进行细致的匹配排查，工作量是非常巨大的，如果没有自动化的帮助，仅仅依靠人工的话，几乎是不可能完成的任务。所以借助工具实现自动化是有必要的。目前已经有不少工具能帮我们完成这一工作，下面梳理一下目前的各类工具。

有哪些SCA工具

开源SCA工具

目前有一些开源的工具专门针对软件成分分析这块提供检测能力，例如OWASP的Dependency-Check和Dependency-Track。大多数开源工具专注于识别带有漏洞组件或版本过旧的第三方组件，并且漏洞库来源比较单一，例如大部分漏洞库来源于公网上公共的漏洞库，并且开源工具对于开源许可证的检测基本不支持（前面提到的Dependency-Track未来版本会支持开源许可证检测）。开源项目在一定程度上可以节省成本，但是在后期支持，以及定制化开发上肯定是比不上成熟的商业软件。

商业SCA工具

针对SCA的专项商业工具往往功能比较齐全，包含针对第三方组件的完整性、安全性和合规性检测的同时，能提供较多的接入方式，例如与组件库的对接，与代码仓库的对接，同当前开发流程的对接。能接受一定成本投入的用户最好选用成熟的商业解决方案。国外能提供这方面方案的有Checkmarx的CxSCA，新思的Black Duck等，国内能提供这方面的方案有默安的MoreSec SCA（因为Gartner有上榜，所以放前面），开源网安的SourceCheck等。当然相比国外发展了多年的方案，国内目前正处于起步阶段，需要大家给点时间。

与AST工具集成

AST工具集成SCA的能力一般也都是商业工具才有的，与AST工具集成有得天独厚的优势。做开发安全AST就是绕不过去的坎，所以在做AST测试的时候，顺带着就可以把SCA做了，省时又省力，但是缺点是与AST工具集成的SCA只能随项目走，不具备从源头治理的能力，简单来讲就是专业度不够。目前针对应用安全检测的工具可以分为三类，SAST、IAST和DAST。DAST不用说了，明显不可能支持集成SCA能力，IAST和SAST由于都是从代码层面分析应用漏洞，所以是具备集成软件成分分析的条件的，国外的SAST和IAST厂商目前没见过有集成SCA能力，这块主要以国内厂商为主，例如默安的IAST、SAST，开源网安的IAST、SAST。以上信息都是从各厂商官网获取，具体实现如何不做评价。

如何评估一款SCA是否适合自己

想要评估一款工具是否适合自己，其实最需要考虑的就是当前的开发流程是什么样的，其次是评估哪些节点去做这个事情比较合理。整体要围绕自己的真实需求去寻找。主要有以下几个点做参考：

1、大方向上，没预算的用户选开源，正在做AST工具选型的选带有SCA功能的AST就可以，预算充足的或是对SCA管控需求比较强的就加一个商业SCA专项工具。

2、能否与DevOps工具链做自动化集成，无论当前开发模式是瀑布、敏捷还是DevOps，都要将这个作为一个评估项，因为DevOps是趋势，保不齐哪天就转了。工具链的集成包含组件库工具的集成、代码仓库的集成和持续集成工具的集成。

3、能够提供API供自有流程平台做集成，这一点对自有流程平台的用户很重要，简单开发就能接入自有平台。

4、能否检测开源许可证问题，这一点虽然是标配，但是有些方案就是不具备这方面的能力。

5、同等条件下，选择漏洞库来源丰富的，最好是那种有接入商业漏洞库的方案。