转载自数世咨询：https://mp.weixin.qq.com/s/SqKrWM5KpBZGQKHB0lxHTw

前言

近几年来，开源组件导致的安全问题频发：2017年美国征信公司Equifax因未修复Apache Struts中的漏洞，导致大规模个人信息泄露；2020年SolarWinds被黑客入侵，直接导致其客户都受到攻击威胁；2021年Log4j漏洞曝出，引起全球企业忧心忡忡，而美国网络安全审查委员会更是认为该漏洞可能会影响十年之久。

开源组件的问题引发了对软件供应链安全的关注热潮。软件供应链安全经常和开发安全相挂钩——这一定程度上是可以理解的，因为大量的企业会使用开源组件来开发自己环境中所需要的应用。而随着DevOps概念的出现，“开发”本身也只是业务中的一环，开发与运营逐渐融合，形成闭环——而这个闭环围绕的则是企业的应用本身。

开源的安全性，以及开发与运营的融合，使得针对应用的安全理念与解决方案有了新的变化。无论是软件供应链安全，还是DevOps，以及基于DevOps的DevSecOps，都对应用安全这个领域带来了一定的冲击，甚至在各种概念和理念上都形成了一些混淆。因此，本报告并非完全从一个特定的安全领域出发，而是将企业在应用的开发到上线之间的主流工具，基于其共性，合并入一份报告中。

关键发现

·当前的应用安全测试与分析市场的玩家都有自己鲜明的拳头产品，但是没有尚没有一家能够覆盖所有产品类型的解决方案；能够结合多家供应商产品的应用安全集成平台将会成为一大需求。

·尽管说应用安全与软件供应链安全并不等同，但是软件供应链安全的热度确实给应用安全带来了极大的关注。尤其在SCA产品领域，鉴于近年来国内外基于软件供应链的攻击事故频发，开源组件安全管理已经逐渐成为了企业不得不重视的事件。

·当前应用安全测试与分析类产品市场规模最大的依然是SAST产品，SCA产品这两年发展迅猛，占比仅次于SAST产品。未来来看，模糊测试、应用安全平台类产品也值得关注。

·无论是SAST，还是SCA产品，在技术上依然存在许多不完善的地方：比如SAST需要在保证低漏报率的情况下降低误报率，而SCA需要能够更快速地基于代码片段来识别开源风险等等。

应用安全测试与分析概述

应用安全测试与分析的范围

本报告中的应用安全测试与分析特指对应用中的代码、应用的交互情况进行测试与分析，从而确保企业自身开发的应用的安全性；相关产品包括但不局限于SAST、DAST、IAST、SCA、模糊测试、应用安全管理平台等。但是，RASP等对应用进行保护的安全产品（而非检测应用自身安全性）不包括其中。

应用安全测试与分析、代码安全以及软件供应链安全

应用安全测试与分析涵盖的几款工具往往和代码安全，以及软件供应链安全关联，甚至在很多时候这三者之间会形成各种包含与被包含的关系。但是，实际上，这三者依然各有差异。

尽管说应用都是由代码组成的，但是应用安全测试与分析并不等同于代码安全。

传统的代码安全是对应用中的代码直接进行检测与分析，发现代码中存在的漏洞——这一部分功能当前可以由SAST和SCA进行。但是，仅仅依靠对代码的安全性检测在现在的环境中是不够的：代码本身没有漏洞并不等同于代码最终实现的应用是安全的——在应用运行时，应用基于的逻辑中可能会存在漏洞，从而产生被攻击的风险。

因此，仅仅通过代码来判断一个应用是否安全已经不足以满足当前的需求了；完整的应用安全性检测应该同时包括对运行时应用进行测试，也就是测试需要基于应用，而非代码。

而另一方面，由于近年来因开源组件和第三方组件导致的攻击数量大幅度上升，并且影响巨大，软件供应链安全往往与开发安全关联到一起。实际上，这对软件供应链安全的理解，无疑是狭隘的。

从软件供应链的下游来看，软件的最终使用方需要确保相关软件或者组件能够在自身的业务环境中正常运作，并且不会存在安全隐患——这其中应该同时包括基于开源组件的系统，以及完全由第三方供应商提供的软件。另一方面，从今年的俄乌战争中，我们必须注意到：技术也是有国界的——无论是开源社区、开源组件，还是第三方供应商的软件，即使它们当前本身是安全的，但一旦不可用，也依然会导致组织受到严重影响。在俄乌战争中，欧美众多企业与组织中断了在俄罗斯的业务与支持，使得俄罗斯相关组织的业务中断，实际上也是因软件供应链导致的——但是这一问题显然无法完全通过开发安全的手段解决。

同时，软件供应链安全的上游供应商侧，也不仅仅是从开发安全的角度确保产品和组件的安全性，需要确保从开发到交付，甚至运维全环节的安全性。而当下游客户的安全意识越来越强的时候，供应商侧是否能够主动提供相关产品的安全性证明、成分清单等也会成为必须考虑的因素。

以SolarWinds的攻击事件为例，SolarWinds的攻击事件可以视为一起基于软件供应链的APT攻击。SolarWinds本身在每一个环节都确保了自身代码的安全性，做了检测——但是，在最终测试完成进入分发阶段的时候，被攻击者潜入并且篡改了代码。这一攻击显然位于开发安全领域的盲区，需要企业中其他的安全防护机制发现并阻断攻击。而对于SolarWinds的用户而言，知晓SolarWinds存在恶意代码之后，如何快速定位自己的受影响业务系统、如何判断自己是否已经遭到攻击、如何进行响应防御，这一系列行为涉及到多个领域的安全产品——但这一切都是因为软件供应链当中出现了隐患。因此，软件供应链安全绝对不是几个安全产品就能覆盖的领域。

应用安全测试与分析相关产品对于软件供应链安全而言主要覆盖了开发阶段到上线阶段前的应用自身的安全性。主要从开发人员的维度确保开发的应用的安全性。但是，从未来发展来看，SCA则有可能打通软件供应链上下游之间的关联：下游的用户可以更为完整地掌握第三方供应商的组件使用情况，从而能够更为全面地应对软件供应链产生的风险。

从开发安全到应用安全

在瀑布开发和传统敏捷开发模式下，主要目标是软件开发的完成。而当DevOps出现后，开发和运营就逐渐结合——这个时候，对应用的防护和检测就不止于开发：比如IAST往往在测试环节使用，而这一场景已经可以视为传统开发模式的末期，从开发环境过渡到运营场景的过程；又比如在本报告中未提及的RASP（Runtime Application Self-Protection，运行时应用自防护）也是针对应用在实际运行时的保护，在运营场景下使用的安全能力。从广义上来看，开发安全保障的是应用在开发阶段的安全性，但是应用本身在开发之后，还有真正的使用场景也同样需要安全防护。因此，最终的防护目标，不是为了确保开发场景的安全，而是围绕开发的应用，实现从设计、立项到运营的全面安全。

企业对开发模式选择会根据自身企业的业务需求而不同；在具体的实现上，也会因企业的环境和IT能力而异——但是，在应用的安全需求上却往往存在很多共性。所以，无论企业使用何种开发模式，在应用安全工具的选择上，依然会覆盖主流的应用安全工具。

对于不同类型的应用安全测试与分析工具，其实并没有绝对的优劣之分，每种不同工具本身就是为了解决特定的安全需求，在不同的开发或者运营场景存在的。企业需要做的，是基于应用的安全需求，在恰当的位置与阶段部署对应的应用安全工具，实现对应用的持续安全防护。

应用安全测试与分析当前市场情况

·应用安全测试与分析产品在2022年度的数字安全成熟度阶梯中基本位于热力区：SAST、IAST和SCA三款产品均处于“融合创新”和“发展市场”领域；模糊测试则处于“融合创新”和“新兴市场”；而DAST则位于滞动区。

在数世咨询的中国数字安全能力图谱2022中都位于“应用场景安全”中，“开发与应用安全”方向下。

·过去两年，由于软件供应链安全的重视程度提升，应用安全整体市场规模在快速增长。明年，应用安全测试与分析产品的国内市场有望达到12亿元。

·从当前市场来看，SAST依然是应用安全测试与分析市场的主要产品。可以说SAST对于企业而言，是应用安全测试与分析产品中的必备产品。另一方面，尽管SCA起步时间不长，但是市场反响已经超过了SCA，并且从未来需求来看，很有可能和SAST一样成为应用安全体系中的标配。另外，在“其他”分类里，应用安全平台型的产品尽管当前收入不高，但是未来而言，需求会越来越高；“其他”中的Fuzzing，或者Fuzz Testing，即模糊测试，短期内可能依然不会引起大规模的市场反响，但是长久来看，同样会成为企业关注的安全工具之一。

·从客户市场区域来看，华东与华南地区是占比最高的两个区域，均为30%上下：江浙沪和广东省蓬勃的金融行业，以及金融行业对应用安全的巨大需求，是这两个区域市场规模较大的主要原因。华北在第三，约占25%。 

部分厂商简评

海云安：海云安的SAST融合了“敏捷”的方法论，并率先提出“敏捷白盒”的理念，以匹配整个敏捷开发流程的发展趋势。

酷得啄木鸟：酷得啄木鸟的主力产品为SAST，是国内最早的SAST产品之一。其特有的缺陷算法分析能够高效检测出源代码中可能导致严重缺陷的漏洞，并进行定位和告警。

默安科技：默安是国内最早推动DevSecOps理念的安全厂商之一。默安的IAST在基础安全性的检测之上，还具备个人隐私信息的检测能力；其SCA能够支持源码和二进制两种检测模式，同时具备组件库准入与安全阻断能力。另一方面，默安也基于自己的多项应用安全能力 ，通过一体化平台的方式帮助企业实现开发工具的一体化管理。

奇安信：奇安信作为国内较早进入应用安全的综合性大型企业，其在应用安全上的积累相当深厚。奇安信的应用安全测试与分析产品主要为SAST和SCA，均为国内市场最大占有率。

思客云：思客云的SAST通过基于项目情景的“智降”二次降噪技术，可以成功将产品的误报数量大幅度降低；同时，其国内领先的增量测试能力也能够极大降低增量代码导致的漏洞漏报。思客云的SCA以数以亿计的开源组件和开源代码数据量为基础，以十字节级的代码指纹为单位分析和匹配代码，兼顾开源安全与同源性分析两大功能需求

孝道科技：孝道科技以单一探针串联IAST、SCA、RASP三大软件供应链安全原子能力，集成“All in one”的三合一平台，并在金融机构生产环境试点实践，以实现应用安全全生命周期的保障能力。

悬镜安全：悬镜安全是国内DevSecOps和软件供应链安全的主要推动厂商之一。悬镜的IAST产品能够和企业的DevOps平台结合，填补CI/CD管道中快速安全测试的需求；其SCA产品能够借助悬镜IAST的能力，在运行状态下检测开源组件。除了商业化的SCA产品，悬镜的开源SCA产品也提升了大量开发者的安全意识，更安全地使用开源组件。另外，悬镜安全的夫子平台能够以平台的方式为企业提供全流程的DevSecOps的安全管理能力。

另外，由于本次并未放入平台类产品、模糊测试等能力的点阵图，但以下几家企业依然值得关注：

比瓴科技：在所有的开发安全供应商中，比瓴科技的特点是做平台，通过ASOC平台将SCA、SAST、IAST、DAST以及Fuzzing和RASP等开发与应用安全的工具整合且联动，即数世咨询提出的“持续应用安全”体系的概念。这个概念已经快速的被许多开发与应用安全的厂商和用户所接受，将是该领域重要的发展趋势之一。

云起无垠：云起无垠专注于模糊测试，而模糊测试的重要性已经得到了业界的关注。如，针对美国总统的行政令，美国国家标准研究所将模糊测试列入软件出厂前的最低测试要求。

SAST

SAST（Static Application Security Test，静态应用安全测试）是指在不运行应用过的情况下，对应用的源代码进行扫描，发现其中的安全隐患。通过SAST，企业可以自动化地对代码进行安全分析，和自身的开发流程集成，提前发现安全漏洞并设法修复。

一般而言，SAST是面向开发人员的安全工具。

SAST能力点阵图

·点阵图将SAST厂商分为三种类型：

融合源：拥有较多不同安全产品能力的综合性安全厂商。

能力源：在某一技术特点上较为突出，或者从某一独特赛道切入应用安全测试与分析领域的厂商。

专注源：以应用安全测试与分析能力为主要能力的厂商。

·本次最终参与并进入SAST点阵图的厂商共有8家，分别为：爱加密、海云安、开源网安、酷得啄木鸟、默安科技、奇安信、思客云、孝道科技。

SAST的价值与局限

SAST的价值非常明显：

·可检测的语言范围广泛。

·能够对应用的源代码进行整体、全面的检测。

·早期发现漏洞，从而降低修复成本。

但是，SAST同样因误报过多被诟病。导致SAST误报多的原因有多种：比如SAST可能缺乏对整体应用的分析，但部分“漏洞”可能已经在应用的其他部分被修复或者相关风险已经被限制，因此形成了误报；另一方面，一些SAST工具在检测规则的制定上也存在不足，导致了误报的产生。

当前国内市场上，减少误报的主流方式依然是对漏洞规则和漏洞类型进行调整：通过只对判定条件十分明确的漏洞，或者只对用户影响较大的漏洞进行告警，以此降低误报率；同时，对其他潜在漏洞进行标记、留存，以便查询、复查。这种方式尽管能够减少误报产生过量告警，但是也留下了一定的漏报隐患，依然需要用户进行最终的平衡。

解决误报的另一种方式则是对现有的SAST机制进行改变——不再是通过逐行扫描发现漏洞，而是基于机器学习、人工智能、语义分析等方法，在对应用本身有一定理解的基础上，进行漏洞发现和识别。

由于SAST本身是在不运行应用的情况下进行安全检测，SAST无法发现运行时或者运行环境相关的漏洞。但是，应用与开发的安全本身并非能够通过单点工具就能解决的，除SAST之外，有其他安全工具可以发现相关隐患。

SAST关键能力

SAST产品的安全能力可以从以下维度进行衡量。

规则库覆盖

SAST的一个关键价值在于其监测的广度上：不仅仅是对整体源代码进行分析的广度，同样也是对语言覆盖的广度。因此，一个SAST产品需要关注其支持的开发框架、数量和漏洞类型的丰富性，从而保障其检测和分析能力能够全面覆盖企业开发环境中的需求。

增量测试

企业开发项目的代码量非常巨大，显然每一次对整体代码都进行检测会产生极大的时间消耗。因此，SAST往往需要通过增量测试的方式仅分析发生变化部分的代码。

但是，无论代码发生了增加，或者是进行了修改，都有可能和之前的代码发生关联后，产生新的漏洞。因此，增量测试需要做到的，不仅仅是测试修改或者增加部分产生的漏洞，还需要能够识别修改和新增部分的代码与之前代码的关联性，并在这个基础上，检测是否有新漏洞的产生。

另一方面，增量测试还需要考虑到“漏洞继承”的问题：即对于局部修复部分漏洞的代码，是否需要重新检测并告警其他之前就已检测出的漏洞。如果这些漏洞不进行重复告警，就可能产生漏报的风险。

漏洞定位与分析

当前的SAST产品基本都能做到将漏洞位置定位到行。但是，事实上，漏洞被利用的位置可能在某一行，但实际上导致这个漏洞存在的根因却是因为代码上下文关联导致的。因此，对于漏洞的定位不应该仅仅局限于漏洞发生的某一行，而是能够将整个漏洞产生的关联链条进行定位与展示，才能更为有效地对漏洞进行分析与修复。

误报率与漏报率的平衡

如上文所提，误报率高是SAST的一个主要问题。尽管部分SAST产品可以通过仅告警确定的漏洞来降低误报率，但这无疑会极大增加漏报率。

误报率与漏报率之间需要一个平衡。这个平衡不仅仅是由企业的开发团队决定，SAST产品本身需要支持。仅报确定漏洞和对所有可能的漏洞进行告警之间有着巨大的鸿沟，当前的SAST产品也需要能够平滑地支持这两者之间告警阈值的过渡，从而帮助开发团队在误报与漏报之间找到一个能够接受的平衡点。不同企业根据自身的开发与安全能力，最大化源代码的安全性。

DevOps下检测速度

尽管SAST的自动化检测能力可以在无人操作的情况下进行，从而在非工作时间段外进行检测，但是依然有部分企业在DevOps场景下会希望更为实时地检测源代码中的问题。在这种场景下，就会对SAST的检测速度提出一定的要求。

SAST市场情况

·SAST是整个应用安全测试与分析产品中市场规模最大的领域。但是，2021年国内市场规模也仅为2.3亿元（未统计国外厂商收入）。未来几年，国内SAST供应商市场有两个方向值得关注：首先，在本次调研中，最终进入点阵图的只有奇安信一家综合性安全厂商，然而，在调研过程中发现，有数家其他综合性安全厂商也正在研发自己SAST相关的产品——通过引导客户意识到开发的安全需求，这些综合性厂商在自己的产品发布后有望进一步拓展国内市场；另一方面，国外开发安全供应商在国内依然有不小的市场占有率，随着国产化替代的要求，这一部分市场也会逐渐被转化。

·目前来看，SAST的交付模式亿单一标准化产品为主，占74%。SAST当前的一大特性依然是能够快速部署到用户环境并且投入使用。因此，单一标准化又功能强大的SAST更容易得到客户的信任。 

·从销售方式来看，SAST能力以直销为主，占比为70%。

·SAST当前主要市场在金融领域，占到45%。金融行业本身规模巨大，又对业务迭代、应用更新的要求有很高的标准，同时对数字安全的重视程度也走在行业前列，因此金融行业在应用安全的各个领域都是主要市场。 

SAST案例：某大型央企T案例（本案例由思客云提供）

场景介绍

大型央企T，国务院国资委唯一以信息服务的企业，全球一流的信息化、数字化技术平台提供商，安全生产的典范，近60家分子公司遍布全球。对业务信息系统的质量，可靠性和安全性有着极至的追求，在业务不断向外延展和加快发展过程中，如何确保信息业务系统的安全、稳定、可靠是该企业实现快速发展的当务之急。

客户需求

大型央企T开发项目很多，三大研发中心，分别位于北京、重庆和沈阳，开发人员水平参差不齐，许多业务上线后发现存在各类代码层面的安全漏洞。不但开发人员耗费大量时间和精力进行修复，同时业务系统被攻击的安全风险还可能影响正常的对外服务，造成企业名誉受损和经济损失。

大型央企T积极拥抱“安全左移”的安全理念，希望能在敏捷开发的模式下防范代码安全漏洞以及代码质量和性能上的问题发生，减少系统上线前因源代码上的安全漏洞而造成的安全风险、降低漏洞修复成本。

大型央企T规划建设完整的开发安全体系，重点以安全编码规范，源代码安全检测标准为主，并且要求SAST工具能与CI/CD系统、版本管理、邮件系统等平台无缝集成，实现从代码获取，执行测试，到测试结果分发，邮件通知，全程自动化，实现高效“无人值守式”代码安全测试。同时，建立并实行开发人员安全开发能力培养计划，从根源上减少应用安全风险。

解决方案

思客云根据大型央企T的开发项目管理体系，将自身的SAST检测工具与现有的工具链整合，协助客户制定和完善开发过程中的相关流程与规范，辅以安全培训提升人员安全开发能力，构建完整、标准、可跟踪、可度量的代码安全管理体系。

 

（图：思客云的源代码安全实施方案）

•安全测试管理标准：思客云协助大型央企T根据自身业务信息系统的特点，制定出企业自身的源代码安全测试标准，并将其直接配置到找八哥SAST系统中，形成可落地、可执行的安全基础（安全门）。

•安全编码规范： 思客云结合该企业内部的人员培养体系，与安全测试标准相对应，提供安全编码规范，为开发人员提供安全编码指导。开发人员通过查阅该指南可快速掌握常见安全漏洞的规避方法，以及漏洞的修复方法，提升安全编程能力，提高漏洞修复效率。

·全自动化测试系统：思客云技根据大型央企T现有的开发与测试流程，将自身的SAST整合到现有CI/CD（Jenkins）工具链中，完善敏捷开发平台的安全管理，为开发、测试和安全管理人员提供全自动化方案，实现从代码获取，执行测试，到测试结果分发，邮件通知，全程自动化，实现高效“无人值守式”代码安全测试。

·安全编码知识体系：思客云还协助大型央企T 建立安全编码知识平台，安全编码规范，并组织多形式、多类型的安全知识培训。对开发、测试、以及安全人员进行针对性的安全赋能，培训内容包括开发安全意识、安全设计、安全编码、安全测试、安全漏洞修复等，帮助其提升安全开发能力。 

（图：思客云的源代码安全管理体系）

方案价值

Ø解放人力: 源代码安全测试完全自动化，包括启动测试、出具报告、安全审计、数据统计、发通知邮件等所有工作。基本可以实现“无人值守”式测试。

Ø“第一时间”发现漏洞：当源代码安全测试变得简单、方便、低成本后，可以把安全测试提前到项目开发的最早阶段，实现“开发者”测试，增加测试力度和频度，第一时间发现安全漏洞。

Ø贯彻制度:  建立源代码安全管理制度，并让制度工具化，可以将企业制定的安全测试标准，从纸面上有效地贯彻在测试过程中。

Ø协同审计：可以多部门、多角色地对安全漏洞进行协同审计、减少各部门之间的沟通成本、加快审计速度、提交漏洞修复效率。

Ø安全编码：制定安全编码规范，并将安全编码与安全测试相结合，以测试驱动开发，以规范修复漏洞，不断循环迭代，大大提高所有开发人员的安全编码水平，从源头上解决安全问题。

客户评价

“思客云的SAST代码安全全自动化测试解决方案，依据我们实际需要出发，将代码安全测试的每一个环节都落到实处，方案将“安全测试标准”、“自动化测试工具”、“安全编码指南”三为一体，协助我们完成了“安全左移”的基本理念，不仅满足了网络安全法、等保2.0以上级部门的安全管理要求，同时，极早地发现并修复了大量安全漏洞，提升漏洞修复效率，大大降低了业务信息系统上线后的安全事故的发生率，减少了安全风险。”

——该大型央企 安全测试处处长

IAST

IAST（Interactive Application Security Test，交互式应用安全测试）通过监测应用运行状态中环境的相关信息，来识别潜在攻击威胁以及应用的漏洞情况，通常在测试阶段使用。

一般而言，IAST有三种部署模式：

·旁路流量：旁路流量的模式在技术上偏向于Web的黑盒扫描器模式。尽管不需要在测试的目标应用中配置agent，但该方法容易产生大量脏数据，降低CI/CD中的开发效率。

·主动插桩：主动插桩通过将agent注入到测试的目标应用中，采集从外部进入的数据在可能最终触发漏洞位置的信息，从而监测是否存在漏洞。主动插桩技术由于可能产生许多流量重放的问题，因此同样有脏数据的情况出现。同时，主动插桩技术还可能消耗大量的时间，尽管能够在低误报的情况下检测出已知漏洞，但是反而不适用于CI/CD的节奏。

·被动插桩：被动插桩能够弥补主动插桩的缺陷。被动插桩同样需要在测试的目标应用中部署agent，但是被动插桩技术在测试中保持静默，只采集进入的外部数据流在内部应用中的变化和流转行为，分析是否存在安全隐患。由于不会进行报文重放、篡改等行为，被动插桩模式能够快速对应用进行测试，并且不会产生脏数据的情况。

从未来来看，IAST最终将会以被动插桩模式为主。

IAST点阵图

·点阵图将IAST厂商分为两种类型：

能力源：在某一技术特点上较为突出，或者从某一独特赛道切入应用安全测试与分析领域的厂商。

专注源：以应用安全测试与分析能力为主要能力的厂商。

·本次最终参与并进入IAST点阵图的厂商共有6家，分别为：海云安、火线安全、开源网安、默安科技、孝道科技、悬镜安全。

IAST价值与局限

IAST是当前国内应用安全市场热度较高的产品，其优势非常明显：被动插桩模式能够满足CI/CD的快节奏，同时相对较低的误报率能够让企业关注在那些真正出现的问题——尤其是这些问题确实存在于实际使用场景之中。

同时，SAST检测无法覆盖运行时漏洞，但是IAST是通过测试运行状态下的应用，发现漏洞，两者可以相互弥补。

另一方面，IAST同样能够对漏洞提供完整的追踪链，帮助相关人员完整分析关联的函数，从而采取最合适的修复措施。

但是，IAST的局限性也很明显。最大的问题就在于IAST支持的语言数量很少，当前只支持数个主流语言的测试。另外，IAST的落地也依赖于一个相对成熟的开发环境，需要开发人员有能力设计各种测试用例，以覆盖完整的应用运行时相关的函数，否则就可能因此存在漏报的情况。

IAST关键能力

IAST工具的选择可以考虑以下三个方面。

语言覆盖

尽管说IAST支持语言数量偏少是IAST的一大软肋，但是对于一些大型开发项目而言，很有可能会用到多种不同的语言。因此，IAST供应商就需要确保能提供尽可能多的IAST语言支持。当前国内主流IAST厂商能覆盖Java、PHP、Python、Node.js、Go、.NET（包括.NET Framework和.NET Core）。企业需要从自己业务需求出发，尽可能确保IAST供应商能够覆盖自己的开发环境使用语言，并且了解IAST供应商未来的语言支持计划，以满足自身的业务需求。

漏洞检测效率与效果

IAST的前期部署相对而言会比SAST更为复杂，因为IAST的测试需要一定的人工进行。因此，IAST供应商在产品中提供的模板以及在整个过程中提供的服务就极为重要。丰富并且贴近实践的模板和高质量的服务，能够帮助企业将IAST尽快投入自己的环境，并且发挥作用。

另一方面，IAST的使用效果不仅需要基于漏洞的检出数据，还要考虑到漏洞的检测分析。IAST依然还是更面向于开发者的安全工具，因此需要能够通过让开发者都能理解的漏洞报告，引导开发人员进行漏洞修复，这包括了漏洞的影响链条、漏洞的影响范围、具体威胁情况等等。

IAST市场情况

·IAST在2021年的市场过亿。但是由于这个领域专注的安全厂商较少，市场规模本身也会一定程度受限于供应商的能力。另一方面，IAST对企业的IT建设水平也有一定要求，这也会成为IAST推广的限制之一。

·目前来看，IAST的交付模式以单一标准化产品为主，占82%。 

·从销售方式来看，IAST能力以直销为主，占比为83%，OEM数量极少。 

·IAST当前主要市场同样在金融领域，占到36%。金融行业IT化程度较高，对更为灵活 、高效的测试产品需求也更为迫切。运营商领域也同样有类似需求，占比在19%。 

SCA

SCA，Software Composition Analysis，即软件成分分析，是对目标软件中的成分进行分析，从而识别其中开源组件相关信息，并进一步展现其安全性的工具。

SCA可以说是开源生态下的产物：当企业开发环境中有超过九成的代码来自于开源组件的时候，这些开源组件的安全性就需要得到验证与追踪。尽管如此，对自身项目中开源组件的分析只是SCA价值的一部分；从软件供应链角度来看，在理想状态下，SCA应该同样具有对第三方供应商提供的相关软件进行成分分析的能力——因为第三方供应商本身也是企业软件供应链当中重要的组成部分。

但是，SCA在当前落地时依然存在着不少的问题，未来的技术发展值得关注。

SCA点阵图

·点阵图将SCA厂商分为三种类型：

融合源：拥有较多不同安全产品能力的综合性安全厂商。

能力源：在某一技术特点上较为突出，或者从某一独特赛道切入应用安全测试与分析领域的厂商。

专注源：以应用安全测试与分析能力为主要能力的厂商。

·本次最终参与并进入SCA点阵图的厂商共有8家，分别为：海云安、开源网安、默安科技、奇安信、思客云、孝道科技、悬镜安全、云弈科技。

SCA核心价值

同源性分析

SBOM（Software Bill of Materials，软件物料清单）是记录软件组成成分的清单，包括了使用的第三方软件与开源组件及其版本、凭证、漏洞等信息。通过SBOM，SCA可以将分析与整理的信息通过格式化的文档进行输出，帮助企业进行软件层面的“资产管理”。

考虑到企业现有环境当中已经含有大量的开源组件——并且极大概率是没有对使用的开源组件进行记录的，SCA对于大部分企业而言的首要工作是厘清当前环境中开源组件的使用情况与来源，并整理输出SBOM文档。企业首先需要通过 SCA发现自己环境中现有的开源组件，尤其是过时版本的组件、停止更新维护的组件、来源不明的开源组件、最新业务系统中不再使用到的组件等对企业会带来直接威胁的软件成分。通过SCA对现有的软件成分输出SBOM文档，可以让企业对自身当前企业IT环境的安全状态有一个更全面的认知，从而可以着手对现有的威胁进行处理。

在梳理完当前的企业使用的软件成分后，下一步就需要常态化开源组件管理。通过将SCA工具融入开发流程当中，可以规范开源组件的引用，追踪并确认使用的开源组件，从而持续把握企业使用的软件成分，避免开发过程中的开源组件使用盲区。

安全性分析与管理

在对环境内的组件有一个清晰的把握之后，组织下一步要做的是发现组件中的安全隐患，并加以管理。这一能力并不只是发现已知的组件当中存在哪些漏洞，同时还需要对这些漏洞进行管理：包括基于自身环境和业务对漏洞严重性进行优先级排序、提供处置建议（如更新到某个版本）等。

软件成分的安全性分析与管理同样是个持续的任务，开源组件和第三方供应商的软件同样会更新版本或者被发现新的漏洞。SCA也需要能够为组织提供最新的软件成分安全信息与处置建议。

依赖性和业务关联分析

除了安全性，组件之间的依赖性（dependencies）也是SCA的重要价值。

由于如今的软件成分是由大量的开源组件组成，组件与组件之间都存在着相互的依赖性关系。一旦某个组件出现漏洞，往往会影响到与它关联的其他组件与系统。因此，企业需要的不仅仅是一份自身环境内的第三方软件与开源组件清单，还需要了解各个组件与软件之间的依赖关系，实现快速了解特定组件与软件中的漏洞对IT环境的影响。

在这之上，数世咨询认为，企业开发业务应用、购买第三方软件的最终目的是确保企业业务能够顺利运行。因此，对开源组件和第三方软件的管理也不应该局限于技术层面，也需要涵盖业务层面：基于组件之间的依赖性，进一步关联组件与业务，能够有机会从业务层面量化因软件供应链带来的风险与影响，并构建相对应的响应计划。

开源合规

开源组件的合规问题同样值得关注。不同的开源组件有不同的开源许可证，对开源组件的使用规范有不同的要求。出于法律合规层面的考虑，企业需要在使用相关开源组件的时候遵守开源许可证的规定。SCA能够对企业使用开源组件的方式进行合规层面的建议与审计，帮助企业避免违规使用开源组件带来的隐患；这一方面对海外业务相关的业务系统尤为重要。

SCA关键能力

开源知识库

SCA的首要任务是梳理软件中的各个成分的来源。因此，SCA自身必然需要有庞大的知识库才能将企业环境中的软件成分进行对应：这包括了开源组件库从而有识别开源组件来源的基础、漏洞库从而能对组件的安全性进行分析、许可证库从而能满足开源合规的需求等。

组件识别与分析

在开源知识库的基础上，SCA需要能够将应用中使用的具体组件进行识别，从而发现应用是否存在因开源组件产生的风险。

当前的组件识别方式有源代码和二进制两种。源代码识别直接从代码入手，发现组件来源；而二进制识别则是对开发的应用已经进行编译以后形成的二进制文件进行分析。

相比源代码识别，二进制识别使用的阶段可以更为靠后。由于基于最终的二进制文件进行分析，因此可以检查出在开发途中被篡改的，或者恶意引入的文件。另一方面，从未来的发展角度来看，企业自查软件供应商的组件使用情况也会越来越重要，而软件供应商提供的软件往往是最终的二进制文件，从而使得二进制识别技术变得更为关键。然而，当前来看，二进制识别相比于源代码识别，在技术成熟度上依然存在很大差距，需要一定时间去突破。

可视化能力

SCA在明确组织IT环境中所使用的组件后，下一步就需要将不同组件之间的依赖性关系进行分析。但是，如果仅仅能够从系统层面厘清依赖性关系显然是不足的，安全工具的最终目的是能够帮助安全人员达成需要的安全目标：因此，需要让安全人员也能够明确掌握环境中不同组件之间的关系才是SCA厘清依赖关系的价值所在——也就是通过SCA实现对环境中相关组件的可视化能力。

通过SCA的可视化能力，组织能够了解不同组件以及组件所在软件，对业务的影响情况，从而能够更准确地对自己面临的风险进行评估，另一反面，在一些影响重大的漏洞信息后，如果有组件的可视化能力支撑，组织能够马上定位相关漏洞在自身环境的影响范围，以及业务影响情况，综合自身的情况，进行对相关漏洞的响应行为。

SCA落地难点

开源知识库的使用

在部署时，开源知识库使用可能不尽人意：即使SCA供应商本身拥有大量开源组件信息，但是却可能无法完全提供给用户。

主要原因在于当前许多企业依然会要求供应商通过本地部署或者私有云部署的形式提供产品，而非供应商自身的云端进行赋能。因此，SCA供应商需要将自己海量的数据本地部署到用户侧。而在每次更新时，同样需要通过交换大量物理硬盘的方式进行更换，造成SCA的部署与更新会有极大的困难。

当前来看，这个问题的解决方法有两种，但是都需要用户自身去改变。

第一种方式是用户逐渐接受SCA供应商以云端的方式提供服务，从而避免本地部署产生的大量不便。

另一种方式是用户需要自身在开发阶段就建立良好的开源组件使用规范，如只从固定的、可信的来源使用开源组件。缺乏开源组件使用规范的开发，会导致项目中引入大量不明来源的开源组件，从而对SCA的开源知识库一味追求大、广、全，潜在增加了许多不必要的开源组件信息。一旦能够对开发环境中开源组件的使用进行规范化处理，就能大大减少对开源组件库数量的要求，配合压缩技术，开源知识库的规模可以降至20Tb以内，而每次的增量更新则能在1Tb以内进行。

代码片段识别能力

SCA当前在技术上面临的一个挑战是代码片段检测能力。如果开发者直接将整个开源组件引用到项目中，那么通过包管理器即可对引用的组件进行识别。但是，开发者也同样会只引用开源组件中的一部分代码，这个时候就需要通过代码片段进行开源组件来源的识别，避免相关风险。

代码片段的识别能力除了需要精确、有效的识别代码来源之外，可识别的代码片段颗粒度度、以及识别速度同样重要。但是，当前整体来看，通过代码片段进行开源组件识别技术依然处于发展阶段。

二进制检测能力

二进制检测能力是SCA另一个技术发展挑战。从二进制文件中进行检测，可以对已经编译的应用进行二次检测，发现开源组件入库后被篡改的行为。另一方面，成熟的二进制检测能力还能够对来自企业软件供应商的软件进行检测，明确其所使用的相关组件的安全性。

尽管说二进制检测技术的使用场景非常有价值，但是二进制检测的技术本身当前同样处于发展阶段，无论是检测速度还是准确度都不很理想。

SCA市场情况

·由于近年来软件供应链安全越发受到重视，SCA作为开源组件治理的重要工具，其市场规模也在快速扩大。最早的一批SCA客户以国外厂商产品为主；随着国产化替代的要求，国内厂商有望转化这一块的市场。

·SCA单签的交付模式以单一标准化产品为主，占71%。定制化产品与运营模式和作为项目中的某一个功能模式相差金额接近。 

·从销售方式来看，SCA能力以直销为主，占比为79%。 

·SCA当前的主要客户同样在金融领域，占42%。其次为运营商和互联网行业。互联网行业对SCA有大量的需求，但是互联网行业本身拥有很多的优秀IT人才以及安全人才，往往可以自给自足；另外，互联网行业也会偏向于使用国外SCA产品。 

某全国性大型综合类证券公司开源治理落地实践（本案例由悬镜安全提供）

客户背景

某全国性大型综合类证券公司秉承“以技术引领业务，以客户为导向”的价值观，大力发展金融科技，打造信息技术核心竞争力，综合应用人工智能、大数据、云计算等新兴技术，将自主掌控与创新作为企业IT文化，持续优化信息系统建设，为客户提供优质服务，助力业务快速发展。

客户需求

近几年开源技术快速发展，开源技术的广泛应用为企业提供便利的同时，也带来开源漏洞、开源许可证/知识产权合规等风险问题。企业的软件应用包括外购、自研、合作开发等多种来源，包含传统CS、BS、微服务等多种架构类型，涉及C、C++、Java、JS等多种开发语言源码管理，面对复杂的应用环境，开源治理工具需要具备很强的兼容适配能力。如何快速识别应用第三方组件中的已有漏洞、软件许可问题以及恶意代码问题，防止对应用系统进行攻击破坏，同时还包括使用版本过旧的第三方组件可能存在一些未知、开发者没有公布的、且已经修复的0day问题成为企业面临的痛点。

方案实现

为确保引入开源成分的产品安全性，该证券公司基于开源软件的特点，结合业务实际情况，建立了内部开源治理体系，从源头保障软件供应链安全。信息技术部门负责开源软件引入、开源软件检测、开源许可证管理，以及开源软件使用及运营过程中的风险评估、安全培训等安全风险管理。

该证券公司为了实现开源治理的有效落地，在软件供应商管理、开源软件引入、安全风险检测、安全威胁情报监控以及开源软件退出管理等环节设计了对应的管控机制。

u供应商准入机制：对于外购的商用软件，需要评估供应商资质与等级，根据等级设定准入门槛；

u开源软件引入管理机制：制定和维护软件版本基线与黑白名单，开源软件的引入需要满足基线与黑白名单要求。

u开源软件安全风险检测机制：应用系统在上线前、运行时都需要进行开源软件风险扫描。上线前，在需求开发管理流程、应用变更管理流程卡点执行扫描，禁止存在开源软件漏洞的应用上线；运行时，定期进行开源软件安全风险扫描，推送相关漏洞工单并处置安全漏洞。

u开源软件安全风险监控机制：统一进行开源软件信息记录，形成开源软件物料清单，同时进行常态化威胁情报跟踪，当软件爆发新的合规问题或漏洞风险时，能及时预警，进行风险管控。

u开源软件退出管理机制：对于老旧、不再维护或存在安全风险的软件，经技术、安全团队等多方评估后进行退出处理，同步更新软件版本基线与黑白名单。 

（某证券机构开源风险治理流程）

具体实践步骤：

该证券公司的开源治理工作与自身DevOps相关的流程、平台、工具高度融合，开源软件的引入检测、许可检测、漏洞检测等动作都在应用需求开发管理流程与持续交付流水线中嵌入完成。

其中，使用制品工具记录制品构建的基础信息，提高软件构建的可追溯性，并能够根据依赖信息，进行反向依赖分析，快速定位组件变更的影响范围，提供风险评估能力。

使用悬镜安全的源鉴OSS开源威胁管控平台（简称“源鉴OSS”）进行开发测试阶段开源组件安全风险管理。源鉴OSS基于开源应用缺陷检测、多级开源依赖挖掘、纵深代码同源检测等核心能力，精准识别应用开发过程中引用的第三方开源组件，深度挖掘组件中潜藏的各类安全漏洞及开源协议风险。源鉴OSS侧重应用系统实际运行过程中动态加载的第三方组件及依赖，在此基础上进行深度且更加有效的威胁分析。将源鉴OSS嵌入需求管理与开发测试的流程中，在编码完成提测后自动触发OSS组件扫描，根据扫描结果推送缺陷工单，彻底卡住引入漏洞组件的源头。

（源鉴OSS DevSecOps部署图）

使用HIDS在线上生产环境进行运行阶段的开源组件安全风险管理，实时扫描线上环境的所有主机，探测引入的风险组件。漏洞管理平台同步检测数据后推送工单督促完成组件漏洞修复。

方案效果

该证券公司自开展开源治理工作以来，已构建了一套较为完善的开源治理体系。在日常研发过程中，该证券公司高度依赖近万开源组件，甚至基于开源技术构建了分布式的证券业务核心系统，得益于开源治理体系的落地实践，在通过开源组件实现技术创新及业务快速交付的同时，收获了良好的开源风险治理效果。

u与研发流水线融合，形成开源软件风险闭环管理

整个开源安全风险治理体系以GitLab源码库、JIRA开发需求管理流程、持续集成流水线、持续交付制品库为依托，通过悬镜源鉴OSS与制品检测等开源软件风险检测工具，将开源软件的风险发现、修复、记录跟踪等治理能力内嵌在应用全生命周期管理流程中，实现安全内生。目前，开源软件风险闭环管理流程已经覆盖该证券公司所有应用系统，跟踪近万个开源软件，漏洞检出效果显著。

u研发流程中进行安全卡点管理，漏洞修复效率且修复率高

该证券公司长期进行威胁情报跟踪与开源软件漏洞管理。当出现开源软件安全漏洞预警时，信息安全团队能及时发起漏洞扫描，通过漏洞管理平台推送工单跟进修复。从漏洞预警到工单推送，整个流程在24小时内完成。日常漏洞跟踪修复率高达95%以上，实现了高效高质量的开源软件安全漏洞风险管理。

u提升软件供应链安全治理与运营水平

该证券公司引入开源治理检测工具后，一方面发现大量第三方开源组件存在的安全风险，另一方面能够从内部清晰地掌握软件中的开源组件资产、开源组件安全风险、开源组件许可证依赖以及SBOM软件物料清单等，提升自身软件供应链安全治理与运营水平。 

（源鉴OSS在证券用户的应用场景）

客户评价

公司开源治理体系建设将由点向面持续发展，继续在软件测试选型、技术使用管理、技术运维管理、定期健康评估、软件退出管理等治理过程中，强化组织管理制度与风险管理机制。悬镜安全作为软件供应链安全领域的头部厂商，在开源治理方面具备创新先进的技术产品和稳定完善的解决方案。在开源治理体系实践中，悬镜安全与公司各部门进行积极主动的沟通交流，不断对源鉴OSS部署过程进行打磨，最终实现了SCA开源治理工具在公司内部的柔和落地。未来，我们十分有意愿和悬镜安全在软件供应链安全治理与运营方面展开深入探讨并达成合作升级。 

其他

应用安全测试与分析产品并不只有上述提到的SAST、IAST与SCA三款。但是，其他产品相对市场较小，因此，并未展开进行调研。然而，以下三款应用安全测试与分析产品依然值得提及。

DAST

DAST（Dynamic Application Security Test，动态应用安全测试）通过在应用运行状态下进行安全测试，以发现其中存在的安全隐患。一般而言，DAST用于应用上线前以及运营状态，对基本已经完成的应用进行测试。

DAST工具不需要了解应用的源代码就可以进行测试，同时也不会依赖于应用的类型。另一方面，DAST的测试方式更贴近实际攻击者使用的工具，因此能够较为真实地模拟现实攻击场景。

但是，DAST的实际使用效果并不理想。尽管DAST的测试方式会更为贴近攻击场景，然而其测试的范围也很大程度被局限在常见攻击类型中，对于漏洞检测的覆盖面非常不足，容易产生大量漏报。同时，DAST对于使用者的要求也更高，需要具备一定量的安全知识才能使用DAST并理解DAST生成的报告。最后，即使通过DAST发现了漏洞，也依然难以对漏洞进行定位。

Fuzz Testing/Fuzzing

Fuzz Testing，或者说Fuzzing，即模糊测试，通过将无意义、随机的信息输入到应用中，观察应用程序反应，以发现安全隐患的方式。Fuzzing测试的是应用在完全不按既定使用方式的情况下，是否会产生被攻击的可能。

Fuzzing和DAST一样，对使用者要求较高。尽管Fuzzing通过输入随机的信息进行测试，但是依然要平衡纯随机信息以及根据应用本身生成的随机信息。另一方面，Fuzzing也容易花费大量时间进行测试并且对结果进行深入分析，这对当前一些在推进DevOps的企业可能会产生一些顾虑。

不过，考虑到Fuzzing有机会发现其他应用安全测试与分析产品遗漏的安全隐患，随着Fuzzing自身的技术以及企业IT能力的日益成熟，相关产品值得关注。

应用安全平台

随着应用安全测试与分析的产品逐渐成熟，企业能使用的相关工具也越来越多。正如前文所提到的，不同的产品适用于应用开发与运营的不同状态，企业也开始需要一个平台对应用安全测试与分析产品进行整合和管理。

应用安全平台依然是服务于企业对应用的开发与运营情况，所以需要相对应的能够融入企业的应用开发与运营流程当中，在技术上需要有对接企业相关开发平台的能力。另一方面，对于使用DevOps的企业，应用安全平台覆盖的不仅仅是开发阶段的安全需求，也包括了应用使用状态下的安全检测与防护。因此，应用安全平台管理的不仅仅应用安全测试与分析产品，也需要包括RASP等运营场景的安全能力。

未来趋势

应用是企业数字化业务的重要载体，因此应用的安全直接关系到企业数字化业务的运营与发展。企业对应用安全的重视程度必然是日益增长的：无论是对企业内部开发使用的应用，还是购买的供应商的应用，最终都会需要通过安全的检验。从这个角度来看，应用软件供应商今后也会因为面临来自客户的安全挑战，而加大在自身应用开发安全层面的投入。

应用安全测试与分析只是应用安全整体中的一部分。从未来来看，无论是这些产品自身的技术深度还是对整体应用安全，乃至软件供应链安全，都会有不同的趋势影响。

SAST智能化

对应用源代码整体检测的需求一直都会存在，SAST的重要性在应用开发的流程中不言而喻。随着代码量越来越大，对SAST检测的准确性要求也越来越高。通过改变告警标准的方式来降低误报率在当前来看是一种提升SAST使用效率的手段，但是对于开发团队而言依然指标而不治本——因为这样会提升SAST的漏报率。

要解决SAST误报率高的问题，本质上依然需要从SAST的引擎入手，通过人工智能等技术，使SAST工具能够更为全局化地理解源代码，从而降低误报的产生。

IAST多语言化

当前IAST面临的限制之一，就是其支持的语言种类较少。相比于SAST、SCA支持的语言种类，仅能支持数种语言的IAST在使用的场景上会存在一定的局限性。随着IAST使用的普及以及相关业务的发展，IAST能够支持的语言种类也会逐渐增加。

SCA泛用化

SCA作为近年来尤其热门的领域，在软件供应链安全中承担着不小的作用。当前SCA的使用场景依然集中在企业为了管理自身开发环境中使用的开源组件并确保其安全性，但是SCA从发展来看，可以做到更多。

当软件供应链安全越来越受到重视的时候，企业在意的不仅仅是自身开发中用到的开源组件的情况，更需要知道其他软件供应商合作伙伴中用到哪些组件。固然，当二进制检测能力走向成熟的时候，企业可以通过二进制的SCA检测能力识别供应商使用到的组件，但是显然会消耗大量的时间。只有通过“以链治链”的方式，才能更高效地对相关开源组件进行治理：即企业在购买、使用供应商合作伙伴的软件时，同样要求相关供应商合作伙伴出具准确的SBOM信息，以便企业进行软件资产的管理。

因此，随着软件供应链安全越来越受到重视，SCA的价值将不仅仅存在于自身开发应用的安全性，也将会是向下游客户证明自己生产软件的安全性的有力手段。

开发团队安全化

尽管说DevSecOps并非对所有项目而言是最优的开发模式，但是其将安全融入到开发与运营流程中的思想是值得借鉴的。事实上，应用安全中不仅应该“安全左移”，而应该贯穿整个应用的生命期，从而能够在任意的阶段对应用进行安全检测、漏洞修复、攻击防护等等的措施。

开发团队安全化并不是意味着要求安全团队融入到开发团队当中，而是提升原本开发团队的安全开发意识与能力。因为开发团队是最了解应用的一方，开发团队安全能力的提升不仅能够有效减少安全团队与业务团队之间的矛盾，更能够提升应用安全隐患的修复效率，提升应用安全能力的使用价值。

应用安全平台化

应用安全的建设离不开应用开发和运营体系的成熟。当应用开发和运营体系成熟的时候，企业会有一套完善的围绕应用开发和运营的流程——而这个流程往往会有一个应用平台进行整体管理。在这一场景下，针对不同的应用开发和运营时期，会有不同的风险，相对应的安全能力才能合适地嵌入到不同阶段。平台还需要监控、分析应用全阶段的安全情况，持续输出应用安全能力。

持续应用安全（CAS）就是基于这样的思路提出的，它针对不同应用开发和运营时期的安全问题，通过一个平台来整合SCA、SAST、IAST、DAST、FUZZING、RASP、移动应用安全测试等安全能力并进行安全数据的分析，最终达到帮助用户减少资源投入、整合安全能力和提升安全效率的目的。