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

前言

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

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

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

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

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

供应链各环节被揭露出来的攻击在近几年都呈上升趋势，在趋于更加复杂化的互联网环境下，软件供应链所暴露给攻击者的攻击面越来越多，并且越来越多的攻击者也发现针对供应链的攻击相对针对应用本身或系统的漏洞攻击可能更加容易，成本更低,SolarWinds事件让IT安全方面的形势变得严峻，如何自证安全性？为了加强安全风险管理，需要保证实现以下目标：

完整性：确保在供应链所有环节中，产品、系统、服务及其所包含的组件、部件、元器件、数据等不被植入、篡改、替换和伪造。

保密性：供应链上传递的信息不被泄露给未授权者

可控性：包括供应链可追溯性，即一旦公司的任何供应链发生问题，可以有效识别哪个环节、哪个供应商、哪个组件出现了问题，并可进行追溯或修复。可控性，也包括需方对供应链信息的理解或透明度。公司作为供应商也应当被视为可信的。在企业安全实践中发现安全运营环节大部分的安全管理和应急响应事件，可以归并到供应链安全体系中。

——安全乐观主义点评

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“安全配置错误”风险中即有所提及，但随着时间的推移，在开发过程中越来越多的应用直接使用带有已知漏洞的组件部分，因此成为了一类单独的风险持续至今。

管理者视角：除了不断解决运维、员工开发、外部主动攻击会带来的单点对抗问题，如何有效管理供应商或者外部投资因素带来的安全风险？公司无边界发展，不断扩张带来什么安全变化？

员工视角：如何保障在公司内使用的操作系统、开发工具、组件，产出的产品到达用户面前的制品流转过程都是安全可信的？

政府视角：信息安全技术 ICT供应链安全风险管理指南》ISO/IEC 20243《信息技术-开放可信技术供应商标准-减少被恶意污染和伪冒的产品》
ISO/IEC 27036《信息技术-安全技术-供应商关系信息安全》
NIST SP 800-161《联邦信息系统和组织供应链风险管理方法》 

 ——安全乐观主义点评

SCA致力于解决什么问题

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

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

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

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

分析NPM、PYPI、MAVEN组件简单，检索二进制文件复杂，软件的license法务问题大家关注不多，既然各家公司都没有致力于去解决，背后一定有原因的，可以暂时先放一放，等待事件驱动了再说。

一般业界提出安全团队该如何及时发现安全漏洞情报，发现不安全组件所在仓库。其实相比于升级的困难，这些安全工作仅仅是开头。

  ——安全乐观主义点评

怎么做

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

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

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

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

举个例子，jetty-core是spring框架里的常用低版本组件，工具判断jetty作为应用服务器中间件存在CVE漏洞时，就关联认为使用jetty-core的应用也存在漏洞。这种要尽量避免误报，建立安全和业务的持续信任关系至关重要，升级的成本大于安全分析的成本。

——安全乐观主义点评

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

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

1day漏洞应急

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

存量业务稳步推行，增量业务发现供应链风险因子后，通过风险评估和威胁分析。近日阿里云发现的skywalking漏洞是个特殊的模式，属于0day由内部的安全研究人员发现并修复，再以安全能力推广出去。对于建设好一定安全能力的公司来说，攻击者从0day入手去入侵性价比最高。第三方资产脱离于安全建设能力覆盖，又经常是资产的盲区，使用的0day往往也并不难挖。

——安全乐观主义点评

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

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

NEXUS作为制品仓库管理端平台，支持校验maven组件的sha1值，但是要小心sha1校验文件本身被篡改。

通过统一的内部源、CI、CD平台可以解决大部分的问题，卡口作为立即解决当前的风险的手段无可厚非，看起来也是融入了安全开发流程，但是归根结底是外挂式的安全，是违反研发思维的。审核都是风险规避，让组织运转越来越慢，长期来说默认安全是方向。

不同的组织有不同的DEVOPS文化，dev和ops分工的关系决定了sec的能力。例如有些公司认为部署在主机上面的imagemagick属于ops团队维护，dev只需要关注开发逻辑。某些主机认为ops只管交付和稳定，imagemagick这样的软件业务自己管理。理清楚这类责任共担模型有助于流畅开展安全活动。

——安全乐观主义点评

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

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

有哪些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。以上信息都是从各厂商官网获取，具体实现如何不做评价。

track和check的定位有稍许不同，前者关注于生命周期管理，后者仅仅是个分词匹配的组件漏洞检测工具。容器安全的不少事情也应该属于这个领域。

工具要尽量外采，人比工具重要，让安全人员专注于有价值的工作，不要重复造无意义的轮子，这并不是非得自研才能解决的问题。完成这些工具的集成后，可以领先业界同行2-3年，落后于国际互联网一线5-8年。

 ——安全乐观主义点评

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

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

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

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

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

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

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

结束语

在这个以效率为王的时代，第三方组件虽然为高速迭代的业务系统开发带来了极大的便利，但是同时也引入的较大的风险，只有做好三方组件的管控，才能避免为业务带来安全性问题。

- END -