Gartner 软件成分分析市场指南 2020

2020年8月18日 ID G00721255

多个风险因素和开源软件使用爆炸性的增长，使软件成分分析成为应用安全一个必不可少的安全工具。安全和风险管理的领导者们应该使用这个市场指南，理解这个正在不断变化的竞争格局，以及市场将如何发展。

概述

关键发现

几乎所有的组织都使用开源软件。由于可利用的漏洞引入了风险；通过恶意软件和恶意代码导致的扩展攻击平面，能够获得访问权，影响专有代码和架构，导致法律和知识产权暴露。
没有软件成分分析，应用开发中开源软件的好处很容易被其导致的风险掩盖。
根据Gartner调查，开源软件的安全性和可持续性，是大多数调查者最关心的问题。
这些担心，导致了一个日益增长的市场，各种厂商都提出了解决方案，在使用开源软件时，识别和减轻风险，提供修复指南。
对软件成分分析工具的兴趣增长很快，虽然估计只有40%的组织使用软件成分分析工具。据Gartner分析，终端用户对这个问题的问询，从2019到2020，增长了40%。

推荐

为了管理和降低开源软件的风险，负责应用和数据安全的风险管理和安全的领导者们，必须要：

把软件成分分析工具包含到应用安全测试工具里面，利用并响应结果，识别和降低开源软件风险。
加固软件供应链，阻止引入漏洞、恶意或不合适许可的软件。最好的方法是生成内部的软件库，包含认可的代码和制件，方便开发人员使用。在任何情况下，都要强制，采取自动化方法，检测内部和外部的源代码（制件）。
和内部相关参与方（应用开发和测试，法律和合规，风险管理）一起工作，简化决定过程，明确可接受风险水平，建立策略，在整个开发流程自动化地强制执行。
在当前的工作流中，为开发人员和测试团队定位好软件成分分析的作用，保证周期性的使用，尽可能的自动化实现。使用软件成分分析工具是缺省行为，而不是例外。

市场定义

本文档在2020年9月10号得到修订。

软件成分分析（SCA）产品分析应用，一般在开发阶段，检测嵌入的开源软件，或者第三方组件。软件成分分析工具通常识别已知漏洞，例如过期的、已经有升级补丁的软件库。也确定发布特定软件包所使用的软件许可（支持法律风险评估）。

市场描述

根据Gartner调查，超过90%的组织使用开源软件。在企业的应用中包含开源软件，提供标准化的功能，是一个快速增长的用户场景。现代的应用程序更多的是组装，而不是完全自己编写代码，开发人员组合多个开源软件包，在单一应用加上中自己的专有逻辑。这个方法有多种好处，减少费用，缩短推向市场的时间，避免被供应商锁定，符合标准等。然而，开源软件带来一系列风险，包括长期可用性，安全漏洞，软件许可合规等，以及潜在的对知识产权失去控制。

开发人员和应用安全团队主要的担心是，直接或传递性依赖库中的漏洞进入组织开发的专有代码中。和大多数软件一样，这些缺陷也被扩散，产生风险。根据Veracode的研究，在他们最初的扫描中，70%的应用包含由开源软件带来的漏洞。Gartner调查表明，尽管存在这些问题，对开源软件的检测率很低。这个事实也在厂商Snyk的一次调查中得到了证实，揭示了仅28%的反馈者承认，对所有的依赖库（直接和间接）有强控制手段；其他的33%认为他们对直接依赖库有控制，但对间接和传递性依赖库没有，剩余的调查者则承认缺少控制或根本不知道。

软件供应链风险已经赢得了很大的关注。和漏洞对比—漏洞是偶然的，已经观察到数量日益增长的事件—在可信任的开源社区中，恶意代码被有意的引入。虽然开源代码是软件供应链中几个攻击途径之一，检测恶意代码的能力，如依赖库中的后门或其他恶意软件，是软件成分分析软件的一个新的需求。

厂商使用了许多方法，结合了自动检查和扫描，还有更传统的手动研究，检测攻击。考察的因素包括一个包的“健康度和好处”，也关系着包的可持续性，如提交者的数量、更新的频率、对漏洞的反应，代码缺点或者控制的变更。其他的方法考察可执行文件意外修改、包内容的改变（基于脚本语言的包里面，引入可执行文件）、或一个应用行为的变化（如打开一个网络连接），和其他异常行为。

评估软件供应链风险的要求，首先来自能理解恶意软件风险的领域的增长。包括国防和政府，多种金融服务，医疗，交通运输，公共事业和工艺制造等垂直领域的互联和IoT设备。这些担心将推动使用“实时”的软件组成清单，随着软件新版本而自动更新。这些要求被认为会快速变成软件成分分析工具的“桌上筹码”。这个发展将有利于具有高级代码分析能力，能够开展识别、分类、报告恶意活动研究的厂商。

在商业产品中，正在研发的功能是帮助优先级排序、修复和缓解风险。在软件成分分析（SCA）和静态应用安全测试(SAST及交互式应用安全测试(IAST)之间集成（SCA产品的直接扩展，或者是独立的工具）。帮助系统不运行软件的情况下，识别包含在内部的开源软件成分。因为SAST和IAST工具能够展示通过应用程序的控制流，所以使这成为可能。被影响的代码也许会被删除，或因为缺陷代码没有被真正运行，被发现的相关漏洞可以降低修复优先级。

其他的功能是和代码库集成（如Git，Sonatype Nexus，JFrog

Artifactory）。这种集成实现多个目的，对期待寻找高控制水平的，可接受的开源软件包的组织，代码库可用来存储白名单软件，另一个使用场景是代码或制件添加到代码库中时，作为一个检查点。对新增加的软件做检查，生成发现问题的报告。

还有一个功能是生成拉取的请求，简化问题包的升级操作—开发人员仅需要检查建议的更新，同意把应用更新到最新时间。在某些情况，这些拉取的请求也会提供一个可能性评估—开源软件的升级可能会中断应用，或和有问题的应用不兼容。

为回应这些担心，安全和开发团队已经把SCA工具变成先识别问题，然后缓解和修复问题。市场主要由工具组成，虽然也有一些类似功能的服务，都可归于下述四种类型：

开源。许多开源工具实现SCA功能。大多数为特定的语言和应用框架设计，因此使用范围有限，也缺少商业软件的某些功能。虽然OWASP的依赖库检测功能可以支持多种语言（.NET组件，JAR文件，JavaScript）或文件格式（archives，CMake，Node.js）。大多数开源工具重点是识别漏洞，过期的软件包，仅依赖有限的漏洞库资源，如国家漏洞库（NVD）。这样的工具不检测许可类型，或其他的项目属性（维护者数量，更新频率，解决漏洞的速度）。尽管功能有限，特别是由于新冠病毒导致的业务缩水，组织的预算受限，开源工具变成了更多组织的主要选择。
独立的产品。这些商业产品提供了很多重要的功能—许可检查，修复指南，开源软件治理和策略加强等等。例如Snyk和WhiteSource（都提供容器扫描产品，发现容器镜像中的问题），Sonatype和Revenera（收购Flexera），提供软件库，治理能力（控制开源软件使用）等功能。
AST套装组件。随着SCA工具的要求增长，更多的应用安全测试（AST）厂商增加了SCA产品，如Checkmarx，Contrast Security，Veracode，Synopsys。这些功能通过插件提供，要求额外的软件授权，并不和SAST或者IAST一起。后者提供必要的代码扫描功能，SCA识别和报告开源软件报警。SCA工具的趋势是作为产品集中独立的产品来提供。
应用开发平台。应用安全工具需求的增长，应用开发工具厂商也开始在其产品中包含安全能力，虽然厂商不多（下面市场方向中有进一步介绍），趋势是将持续，并对当前的AST市场产生破坏。

除了开源或者商业工具，SCA也可以通过服务实现—SaaS模式或者扫描方式。对开发团队来讲，扫描并不是一个优化的方法，但在并购活动中，评估潜在的法律和安全风险时比较有用。

市场方向

自从SCA市场在15年前建立，一直在周期性地变换重点。最初，法律团队使用这个工具做并购尽职调查是主要的购买者，主要查看公司软件包中相关的软件许可类型。有限制的开源许可也许会限制商业使用，或强加其他没有吸引力或不利的条款。随着时间，应用安全团队开始对开源软件中的漏洞发生了兴趣，漏洞检测变成了关键功能。

最初的产品功能是独立的方案，由专注于市场的厂商提供。随后，AST厂商在扩充产品种类的时候，收购了许多这样的厂商。在过去的一些年里，一轮新的独立厂商开始兴起（如Snyk和WhiteSource），和应用安全团队比较而言，经过优化的产品更适合开发人员使用（虽然这两个都是当前的买家）。今天的市场由混合的厂商组成，独立产品，单一方案的厂商和AST多产品方案的厂商竞争。合作伙伴和OEM关系是进入市场的重要途径。特别是独立产品的厂商，将软件许可扫描技术，漏洞和许可信息提供给缺乏自有SCA能力的厂商。例如，Rapid7和Snyk合作，扩展传统的DAST和漏洞扫描技术之外的AST市场空间；HCL 和WhiteSource达成一致，访问后者开源漏洞和软件许可数据。

根据市场环境分析，开源扫描项目被认为是一个独立的工具，虽然传统上他们倾向不直接和商业产品竞争，但如前所述，这一直在变化，至少在某种程度上。开源工具在越来越多地应用在组织很难判定购买商业工具费用是否合理的场景，也被用来当组织觉得商业产品功能无法满足需求的场景。

应用安全团队是SCA产品最常见的买家，做尽职调查的法律团队也在持续购买（主要是临时服务）。虽然这些团队越快越倾向于组合的AST产品集，但独立的厂商（Revenera，Sonatype，Snyk，WhiteSource），在这个市场持续保持成功，并逆势向平台发展。同时，就像其他类型的AST工具，在SCA方面，开发团队正在作为一个独立的购买中心，占用测试工具的预算。这个趋势至少和采用DevOps有关，开发团队日益承担更多的责任，包括安全测试。

作为市场更广泛转变的一部分，开发人员成为工具的买家。Gartner观察到，应用开发工具厂商正在将安全测试工具包含到产品集中，包括SCA。例如GitLab在产品中，包含混合的专有和开源的AST工具（包括2018年收购的SCA厂商Gemnasium），微软收购GitHub加强Azure DevOps产品，GitHub又收购了Semmle（漏洞扫描工具），NPM（Node.js包管理器，也可认为是一个安全工具），Dependabot（依赖库检测或SCA工具）。其他的厂商也达成协议，把SCA能力包含到应用开发平台中，如RedHat,和Snyk达成协议，在OpenShift产品中包含后者的漏洞库。

向未来展望，我们能够预测：

SCA作为组织的AST工具集的重要性会持续增长，由于开源软件的广泛使用，范围将会扩大到评估开源软件的其他风险，如包括可持续性、稳定性，软件包的由来（据Gartner 调查，开源项目的可持续性是客户第一关心的问题）。工具将开始提供针对软件包的报警，尤其是小团队维护的软件包，对已经披露漏洞的更新慢或反应滞后。这些评估将包括软件包本身和任何传递性依赖库。
这些可持续性的检测将会扩展到包括软件供应链问题，如前面讨论的，这些功能将包括对一个给定软件包的自动化检查和深入变化研究相结合。
大多数SCA工具只关注开源软件，但一些买家对商业软件表示了担心，这将提醒厂商，增加对商业软件库的支持。
中长期来看，新的AST厂商的出现—特别是，现在的应用开发工具厂商，如GitHub，Gitlab，OpenShift，包括软件库厂商（Sonatype，Git，JFrog），加上购买决策中心向开发团队细微的移动，二者相结合，将会摧毁AST平台厂商。这些厂商可能坚持服务传统的市场和买家（逐渐缩小的细分市场）。然而，他们将被强迫和应用开发工具厂商竞争和寻找差异化，这些工具厂商可能将扩充产品，通过收购AST软件套装，更好的满足买家AST的需求。其他的SCA厂商也将面临紧迫的竞争，然而，如观察所见，一些厂商建立合作伙伴或OEM，将利用市场向他们有利的方向移动，并围绕着开源软件包做进一步的投资研发。
虽然AST和SCA厂商已经避免了明显的价格竞争，但这种情况将在短期内发生改变。对于这一点，厂商正在更多功能和更深入的研究及开源软件情报的基础上竞争。其他的竞争，来自于拥挤的AST市场，独立的SCA产品厂商，新的来自于开发工具厂商的竞争，已经明显可见。低价替代品，如开源项目，将会给市场带来价格压力。（短期，这个趋势将会由于新冠病毒带来的经济效果而恶化）

市场分析

SCA市场由产品买家和服务提供商组成，提供如下功能：

开源软件的识别和确认。技术是变化的，识别基于标准编程语言特定软件包的技术，被用来在一个程序中增加源代码（其他软件）。这些包括目录，或其他指令，取决于特定的编程语言。其他方法包括扫描代码本身，或库来识别特定的包元素，更少见的是，工具将检查代码，搜索片段，一段来自一个大的软件包的代码。除了发现特定包（直接依赖包），工具也应该识别间接或传递性依赖库，指一个软件包含有其他包，常常递归的形式。
软件许可识别和风险评估。如同商业软件，开源软件几乎总是根据许可协议来分发，明确说明软件被使用的方式。存在多种软件许可，内容变化很大。有些是非常宽容，对软件如何被使用没有限制，对使用者也不强加任何责任。相反，更多限制性的许可会带来明显的法律风险，并通过许可条款的实施而造成知识产权的损失。虽然工具尝试指出有问题的许可，在特定许可条件下，使用一个软件包，应该听从律师的建议。
软件漏洞。如同任何软件，开源软件包含能被攻击者肆虐利用的漏洞。SCA方案的一个重要功能就是识别包含漏洞的软件包。根据厂商依赖的公开和专有数据库的大小，内部的研究团队加以补充，更大的精确性和更自信的发现，这个功能已经成工具之间的差异化的重要指标。前面提过，作为流程的一部分，工具会推荐合适的升级路径，修复不安全软件包。一些厂商，如Snyk，提供补丁（例如，漏洞还没有被维护者修复），虽然这并不普遍适用。
治理和控制。考虑到他们（低）风险的偏好，组织也许希望对应用中的开源代码做进一步更大程度的控制。在这种情况，一个典型的反应是生成一个开源代码包的许可软件库。开发人员自由的使用软件库中的代码，其他的包必须先通过检查和许可流程。这个方法假设有资源检查建议的版本，维护当前软件库中许可软件包的通用性。一些厂商，如Sonatype，使用Nexus Firewalls产品，帮助加强这些策略，通过尝试限制开发者下载未经许可软件的能力。其他的方法不那么正式，当浏览基于web的软件库时（GitHub，Stack Exchange），通过浏览器插件，对有问题的软件，警告开发人员，不管这样的许可软件库是否存在，在构建流程时，组织应该扫描软件，保证未经许可的软件包无法进入内部。
报告和分析。如前讨论，生成和共享软件组成清单，识别和阻止软件供应链风险，变得更重要。虽然没有广泛实现（缺少标准化共享规范），生成一个正式的软件清单的能力还很缺少。至少工具应该报告使用的代码中直接和传递性依赖，代码在哪里被使用。当标准化到来时，这就使组织能够支持软件组成清单。在这期间，这样的清单能够帮助快速地识别新发现漏洞或问题的潜在影响。如果一个问题被发现，安全团队能快速和容易的识别是否和哪里—给定的软件包在被使用，就会相应地计划修复措施。

代表厂商

许多不同类型的厂商提供SCA工具和服务：

厂商产品，服务，方案名称

Checkmarx Checkmarx 软件成分分析（CxSCA）

Contrast Security Contrast OSS

FOSSA FOSSA

GitHub Dependabot

GitLab Dependency Scanning

JFrog JFrog Xray

MoreSec Technology MoreSec SAST/SCA

Revenera FlexNet Code Insight

Snyk Snyk Open Source Security

Sonatype Nexus Lifecycle，Nexus Firewall，Nexus

Lifecycle Foundation，Nexus Auditor

Synopsys Black Duck Software Composition Analysis

Tidelift Tidelift Subscription

Veracode Veracode Software Composition Analysis

WhiteHat Security WhiteHat Software Composition Analysis

WhiteSource WhiteSource for Developers

市场推荐

就像任何应用安全发展路径，从建立策略开始，以横跨安全域风险容忍度，法律责任，知识产权，供应链可行性和完整性作为基础。至少在某种程度上，在一个组织的产品集的不同应用中，每一个相关因素都会变化。但即使一个针对所有产品的通用策略，也比没有强。这个策略能够用来描述基于风险的指标和条件，对组织来说，可接受或不可接受，帮助定义必要的产品功能。
安全策略应该表明构成一个可接受风险的漏洞类型和严重性。他们能被增加到应用程序的技术债务中，作为最终的解决方案。其他的则要求即时修复或减轻风险。这些策略对给定应用的风险概况很敏感，因为对一个应用来说可接受的风险，对另外一个应用来说可能就是明显的安全或合规风险。当没有修复措施或修复必须被延迟时，策略应该包括解决漏洞的指南。
某些类型的工具要求满足评估的范围和速度，以便更好地支持DevOps，或其他快速变化的开发方法。评估标准应该包括如下因素：

技术覆盖范围—语言，框架，要评估的开源生态系统
工具提供数据的深度和广度—漏洞，数据源的质量和数量，包括许可类型的识别和相关风险。
单个软件包的状态和起源，数据优先级排序的能力，越来越得到重视
对产品主要的终端用户，操作的合适性—例如，相比法律团队，开发人员更喜欢大量的不同接口和功能设置。
帮助识别潜在修复或缓解措施的能力
和软件开发生命周期（SDLC）及其他相关系统的集成
报告和管理

对于内部和外部使用，生成和维护动态软件组成清单的能力日益重要。Gartner曾经推荐组织生成这样的文档，特别要注意组成软件包的单个元素和传递性依赖库的起源或历史。组织维护（和要求）这样的文档越来越重要，作为购买软件或许可的条件，以及用于内部跟踪的目的。这个文档帮助组织更好的了解软件的作用，更准确地评估软件潜在的风险，问题出现时迅速识别漏洞代码。各种提议的格式有助于分享，组织应该监控和行业有关的正式的定义和格式流程，保证工具支持生成文档所需要的最基本的目录和追踪能力。
至少在中短期内（一到两年），买家在评估选择时，总体成本控制上应有一个宽阔的视野。和供应商就价格谈判不亢不卑，明确表示市场上有可接受的、价格更低的产品。Gartner 客户通常对安全工具的成本表示担心，SCA也不例外。新冠病毒相关的经济力量更增加了这样的压力，导致许多组织寻求性价比更高的方案。现成可得的开源的SCA工具，提醒很多评估者把他们考虑在内。当然有一个平衡，开源代码成本很低，但可能在未预料的方面增加费用，如收集和分析多个工具的结果，对单一应用生成一个综合的视图。商业工具一般都会把这种任务作为基本功能之一，然而，取决于厂商，他们能快速地突破预算。