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

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

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

接入

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

发现

漏洞

开源组件的漏洞和风险主要是通过邮件列表，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企业版，也直接提供了安全功能。

    管理

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

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

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

    做组件分析的时机

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

    1.自动可靠检测和对应到手工无法找到的已知开源漏洞2.提供正在使用的开源软件的详细溯源3.可以实时管理业界新发现的漏洞4.相当于聚合全球开源社区的安全测试能力5.可以在整个SDLC中使用 使用开源方案有五个难点需要动手解决：1.不处理公司内部开发的代码。公司自主开发的代码，没有纳入漏洞管理范围，需要适配开发。2.不解决应用程序配置漏洞。如spring actuator组件是否存在漏洞，依赖于各个版本的不同配置。3.解决方案的完整性和有效性各不相同。由于漏洞批量信息的有效性和时间性，需要有经验的安全专家依据实际情况，处理妥善的漏洞修复方案。4.不能解决容器、镜像、软件所部署环境的安全问题。5.最重要的问题：如果你使用了免费软件，老板会认为你也是免费的，安全是不值得花钱投入的。

    如果读者任何所在组织有必要做软件供应链安全，也接受投入资源做这件事的性价比，那从现在就行动吧！

    参考资料

    https://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html

    https://blogs.sap.com/2019/01/30/sap-open-sourced-its-vulnerability-scanner-for-java-and-python/

    声明：本文来自安全乐观主义，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。