专家有料 | 李中文：美团软件成分安全分析（SCA）能力的建设与演进

文丨李中文（e1knot）

现任美团安全高级工程师，负责公司基础安全运营相关的能力建设工作，拥有丰富的安全运营能力建设经验。曾在DEFCON China、ISC等多个会议分享安全运营相关议题。

前言

随着DevSecOps概念的逐渐推广和云原生安全概念的快速普及，研发安全和操作环境安全现在已经变成了近两年行业非常热的词汇。在研发安全和应急响应的日常工作中，每天都会收到大量的安全风险信息，由于目前在系统研发的过程中，开源组件引入的比例越来越高，所以在开源软件治理层面需要投入很多精力。但是由于早期技术债的问题，很多企业内部在整个研发流程中对使用了哪些开源组件，这些开源组件可能存在严重的安全隐患等相关的问题几乎是没有任何能力去收敛，所以多年前的SCA（Software Composition Analysis，软件成分分析）技术又重出江湖，变成了这一部分风险治理的神器。本文主要探讨的范围是利用SCA技术实现对开源组件风险治理相关能力的建设与落地。

SCA概念其实出现很久了，简单来说就是针对现有的软件系统生成粒度非常细的SBOM（Software Bill of Materials，软件物料单）清单，然后通过风险数据去匹配有没有存在风险的组件被引用。目前市面上比较出色的商业产品有Synopsys的Blackduck、Snyk的SCA、HP的Fortify SCA等，开源产品有国内悬镜的OpenSCA。但是通过对这些产品的调研和分析后发现，这些产品由于诸如风险数据库完整度、与现有研发流程耦合程度、性能和社区支持不完整等原因，不能很好地融入企业内部的研发流程，但是这一部分能力在企业内部对于SDL工作而言又是不可或缺的能力。所以企业内部的信息安全团队需要结合业务团队的需求，安全团队自身对于风险的理解，企业内部的研发流程现状和现有的技术与数据能力、应用成本和ROI等现状和问题进行综合考虑，打造自己的SCA能力，从而帮助业务团队多快好省地解决软件供应链层面上的信息安全问题，安全团队也可以更好地对组件风险问题进行全局视角下的治理。从上面的内容大家也许听出来了，在企业内部建设SCA能力的过程中会涉及到很多的产品和运营方面的问题，诸如跨部门协作、系统稳定性、业务和安全部门对于风险的定义不一致等问题。本文主要介绍SCA能力在企业内部实际落地的过程、遇到的问题以及对SCA技术的看法和展望，旨在为业界提供一个可以参考的解决方案和范本。

安全视角下的研发风险

在企业内部的信息安全团队看来，很多企业内部实际上在整个研发流程当中遇到的风险面实际上是蛮多的，通过对于各种攻击面的梳理和分析之后，实际上在研发流程中被经常提及的风险主要包含以下三类。

一、通用漏洞风险

在组件安全层面上，首先遇到的问题，也是最容易发现的问题就是漏洞问题，造成的影响也十分直观，可以导致系统因为恶意的利用导致出现非预期的功能，进一步破坏系统的完整性和可用性。根据2021年Synopsys放出的软件供应链相关的数据显示，开源代码仓库中至少存在一个漏洞的仓库占整体开源仓库的比例从2016年的67%上升到了84%，至少存在一个高危漏洞的代码仓库占全部仓库的比例从2016年的53%上升到了60%，最高的时候是2017年，这一数字是77%。

 而根据2020年Snyk发布的另一份开源组件与供应链安全的报告显示，漏洞的数量仍然需要提高警惕，XSS漏洞仍然占据数量榜首，紧随其后的是命令执行类漏洞，这些漏洞会严重影响系统的稳定性。

 在上述所罗列出来的风险当中，当注意力集中到恶意包（Malicious Packages）上时，我们可以发现该类型的风险是2019年度上升幅度最快的威胁之一，这也引出了下面的问题。也就是软件供应链相关的风险。

二、供应链相关的风险

开源组件的生产-构建-发布过程其实是与企业内部常规的系统研发上线的流程是一致的，简单来说可以抽象成下图中的样子：

 开源软件作者完成代码编写后push到源代码管理平台（GitHub、码云、Gitlab私服平台）等，然后在CI/CD平台上发起构建编译打包的流程，在这个过程中，CI/CD平台会从组件依赖平台（Sonatype Nexus私服或是MVNRepository官方源）上获取需要依赖的包，在CI/CD平台完成打包/镜像封装过程后，通过项目分发平台分发到生产环境上，更为现代的方法是直接拉取Docker镜像做部署，完成系统的上线。

这个过程看似简单，但是实际上环节还是有不少的，我们把每个环节拆解来看，实际上每个环节都是会有很多风险的，如下图所示：

 

1.  IDE插件投毒：为了更高效率地开发软件，开发人员往往会在自己的IDE当中引入各种各样的插件来提升自己的开发体验与效率。这个是一件非常正常的事情，但是往往软件开发人员没有足够的安全意识，导致自己的IDE中可能会安装了一些有问题的组件，甚至IDE本身也出现了供应链投毒的情况，这种case多到数不胜数，比较出名的是2021年5月份Snyk披露的一份安全报告中显示攻击者在VSCode的插件市场发起了投毒行为，一些有问题的扩展是“LaTeX Workshop”、“Rainbow Fart”、“在默认浏览器中打开”和“Instant Markdown”，所有这些有问题的扩展累计安装了大约200万次，此次事件所造成的影响是非常广泛的。
2.  提交缺陷代码：在软件开发环节，开发人员因为水平、安全意识的诸多原因，往往会在开发过程中引入漏洞，这本身是一件十分正常的事情，但是对于开源软件而言，因为几乎是所有人都可以向开源项目提交代码，并且通过审核后就可以merge进项目，所以总会有不怀好意的人故意引入有问题的代码，比较典型的case是2021年4月，明尼苏达大学Kangjie Lu教授带领的研究团队因故意向Linux引入漏洞，导致整所大学被禁止参与Linux内核开发。除开道德问题，这种风险实际上有可能因为审核的疏忽导致风险直接被引入。
3.  源代码平台被攻陷：其实Git平台本身由于保护不当，也有极大的概率被攻陷，虽然说攻陷GitHub这种平台本身不太现实，但是有很多开源项目都是自己搭设的Git平台，再加上一些众所周知的原因，Git平台本身缺乏保护是一件很大概率发生的事情，在2021年3月，PHP的官方Git就遇到了类似的case，由于PHP官方Git，PHP团队在git.php.net服务器上维护的php-src Git仓库中被推送了两个恶意提交。攻击者在上游提交了一个神秘的改动，称其正在"修复排版"，假装这是一个小的排版更正，并且伪造签名，让人以为这些提交是由已知的PHP开发者和维护者Rasmus Lerdorf和Nikita Popov完成的。所以Git平台的安全保护本身也是需要提高重视的。
4.  代码branch被篡改导致打包结果不一致：由于开源项目的Git仓库是向所有人开放的，有些攻击者会尝试新建不同的branch植入代码然后进行发布，这样虽然编译过后的包带有CI/CD平台的签名，但是仍旧会引发严重的安全隐患，早在2019年的DEFCON会议上，就有安全研究员就发现了WebMin的1.890在默认配置中存在了一个很严重的高危漏洞，1.882到1.921版本的WebMin会受到该漏洞影响。但奇怪的是，从GitHub上下载的版本却未受到影响，影响范围仅限于从SourceForge下载的特定版本的WebMin，后来经过调查后发现，是代码仓库没有添加分支保护机制出现了问题，引发此类安全风险。
5.  CI/CD体系被攻陷：在前面如果我们完成了代码完整性检测的话，如果流程没有被篡改或者构建平台运行正常，一般情况下出现问题的几率很低，但如果CI/CD平台和前面的Git一样被恶意篡改或是破坏，结果必定会出现安全隐患，SolarWinds事件就是由于这一原因导致的，攻击者在CI/CD过程中嵌入了后门，通过了签名校验，再通过OTA分发补丁之后导致出现了让人震惊的供应链攻击事件。