供应链安全：安全建设中的软件组件依赖问题

OWASP TOP 10列表中反复强调的“使用含有已知漏洞的组件”逐步成为供应链安全的显著问题，外部研究机构显示78% 的漏洞是在项目中的间接依赖中被发现的。读者们不妨想一想被Apache Struts和fastjson支配的恐惧，就知道依赖安全类的感知和修复过程非常复杂。所以目前的SDLC中的软件安全领域越来越关注软件成分分析，将其作为一个独立的安全建设领域很有必要，今年上半年默安科技和360代码卫士分别发布了对应的产品（链接xxx），笔者试用后对产出的指标并不十分满意，本文重点阐述一些方法论，以及为读者介绍如何借用开源的力量尽力做好依赖安全。

着力点：接入、发现、防护、管理

下图是笔者总结的第三方组件流通图，可以看到组件的分发过程很零散：

接入

读者们可否有信息回答这个问题:”作为安全负责人，你知道公司使用和开发的应用中使用的开源组件都是最新的，已经安装了所有的重要安全补丁？”答案一定是窘迫的，如果连自己公司正在使用哪些软件，用什么开发的系统都不知道，何谈为其安装安全补丁呢？原因在于许多企业所用的开源组件并没有保存准确、全面、更新的资产清单，所以要做好组件安全，首先要有清晰的组件列表，并实时后台自动维护。不仅仅关注外部引入的代码，也要区分商业组件、开源组件和内部组件的版本和漏洞。

发现

漏洞

开源组件的漏洞和风险主要是通过邮件列表，github issues，nvd漏洞库进行的标注，所以最重要的工作总是发现项目中的依赖->找到对应的cve漏洞，值得一提的NVD 不仅在优先级分配上难免受到主观因素的影响，而且 CVE 中的数据报告、评分和可操作性都有可能存在严重滞后、缺失问题。

软件许可协议

除了安全问题外，license问题也需要关注。远有思科供应链的的教训，FSF状告Cisco以 Linksys品牌出售的各种产品违反了FSF拥有版权的程序许可条款，包括 GCC、GNU Binutils和 GNU C库，最终以思科任命一名董事以确保Linksys产品符合自由软件许可，以及思科向FSF进行未公开的财务捐助作为收场。详情参看https://www.fsf.org/licensing/2008-12-cisco-complaint。

近有Oracle索赔谷歌88 亿美元的大事件,背景是OpenJDK这个GPL项目的著作权属于Oracle。当时在谷歌供职的Joshua Bloch直接从OpenJDK复制了9行代码到谷歌的Android项目中。要点是Android项目没有按GPL兼容的方式授权，这就触犯了oracle的著作权。这个故事告诉我们，软件供应链的license安全部仅仅是简单的引入组件的问题，复制粘贴的代码片段也是需要关注的点（面向csdn复制代码的小伙瑟瑟发抖）。

下面为大家展示价值88亿美元的所谓违反软件协议的9行代码…..

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) {
        if (fromIndex > toIndex)
            throw new IllegalArgumentException("fromIndex(" + fromIndex +
                       ") > toIndex(" + toIndex+")");
        if (fromIndex < 0)
            throw new ArrayIndexOutOfBoundsException(fromIndex);
        if (toIndex > arrayLen)
            throw new ArrayIndexOutOfBoundsException(toIndex);
    }

未按照开源许可证约定使用开源组件会引发潜在的法律纠纷，其中最常见的是 GPL（GNU 通用公共许可证）许可证违规。懵懵懂懂的用户使用了不合规的license，会导致产品下降或被传染被迫开放自有商业产品的源代码。在《金融领域应用安全源代码安全检查产品测评方案》就特别提出：“送检产品关键核心模块的源代码开源比例原则上不超过30%，所使用的开源代码中不应包含GPL等强制开源的类型”，这说明国家对某些重要领域的风险防控提出了“自主可控”的要求。

防护

自动化流程必须工具先行，下图囊括了商业工具的能力：

Fossa在中国已经有代理，jfrog的产品是xray（和长亭的重名了），snyk势头不错，和github集成推广力度大。商业工具的产品名介绍在这里：

WhiteSource属于老牌产品，奈何在国内知名度低，工具实现了通过执行静态扫描来确定漏洞优先级的功能，这可以方便定位应用程序是否直接调用组件的易受攻击部分。这是巨大的亮点，有时候代码的package.json或者requirements.txt写了高危组件，但是实际代码没有引用。另一个时髦功能是通过创建pull request以升级到符合公司策略的版本来自动修复漏洞，极大的节省了修复闭环时间。Synopsys就是收购coverity的公司，也收购了Black Duck Hub和Protecode SC产品，实现了二进制溯源功能，直接进行二进制文件扫描和报告功能也是亮点，有时候做组件分析面对一些历史dll，完全不知道从哪个cpp库里编译出来的。但是对于更复杂的许可证合规扫描，synopsys就必须单独使用另外的Black Duck Protex和Black Duck软件。笔者认为Synopsys的扫描速度快、可靠，提供了详细的修复建议，但误报率相对高。产品具有非常强大的策略管理、SDLC集成以及强大的漏洞管理能力，适合企业对SDLC团队中有严格的要求，并且有额外精力针对不同类型的应用程序制定不同的扫描策略，类似于航天，车联网行业应该会受到欢迎，在互联网行业就笨重了。

Snyk的目标是使开发人员不依赖专业的安全专家也能够修复漏洞，因此不仅可以通过创建pull request进行自动修复，还可以为开发人员提供一个调用图，其中显示了其直接依赖项所包含的间接依赖项和相关漏洞，以帮助开发人员理解为什么需要某些补丁。这个功能十分重要，因为开发人员ctrf+f查找pom.xml后，说我没有fastjson，实际上是可能com.alibaba.otter这个包，引入了fastjson。一般用mvn dependency:tree命令才能梳理清楚。

GitLab从2017年开始提供安全产品，现在除了二进制SCA之外，还提供静态和动态分析。GitLab倾向于不像sonar一样扫描出问题就通过“质量门槛”中断构建。相反是推崇使用安全reviewer的角色，通过代码审查解决安全漏洞。我个人很喜欢它的理念–将安全前置，但是这样面向开发人员的特性会让安全人员工作量增大。例如在gitlab容许开发人员忽略任何漏洞，不管实际是不是高危严重的。这迫使安全人员仔细标记已被忽略的漏洞是不是误报。鱼与熊掌不可兼得，在效率和安全之间必须权衡。

还有几款蓬勃发展的开源或共享工具，读者部署起来也能为企业做软件成分分析。

首先推荐可以使用dependency check，支持各种语言，持续社区更新，有命令行、docker部署、丰富的报告格式。原理是基于开源的 NVD 开源漏洞数据库来监测安全漏洞的，缺点是基于文件名来使用Lucene分词匹配cpe不准确，这个环节引入一部分误报的问题。

另外一款工具是dependency track，是owasp新出的工具，界面较好，方便管理。

SAP公司开源了Java和Python SCA 工具，提供静态代码安全性测试功能，以后有时间会为读者们重点介绍。

对于node应用，有npm audit fix命令可以自动升级版本，原理是通过nodesecurity.io的接口查询漏洞，详情参看https://www.npmjs.com/solutions/security-compliance。

如果基于github，那么有snyk.io，git alert、lgtm、sonar oss免费服务可以使用。另外gitlab企业版，也直接提供了安全功能。

管理

管理层面要先行，想一下做到完全的安全是行不通的，没有管理的支持是说不通的。需要的安全管理参与范畴有：

成立开源治理团队，包括管理者、法务、安全专家、研发负责人，梳理重点组件，推动大面积的升级版本
建立第三方软件引入制度，审核组件的历史漏洞、预估业务解耦风险，选型备用组件。
面向研发工程师进行政策、法规、案例的培训宣传。
聘请知识产权律师处理软件法律冲突，审核并购公司的合规性。
采购和部署自动化工具发现软件依赖的使用。

笔者据此勾勒了以下的支撑框架模型：

做组件分析的时机

在企业建设黑盒，白盒成熟阶段之后，如果你打算立项做软件成分分析的任务就要准备好分锅，是的，就是这样–你发现的低版本组件也许永远也不会形成漏洞，开发人员凭什么去费心修复？所以要提前沟通好职责：业务开发人员负责排查和升级日常的安全工作，而安全人员从更高的维度把控安全问题，例如建立更好的安全流程，给出专业的修复建议。本文最后要提醒读者们使用开源方案的优劣之处：当然优点除了免费，还有：