一、前言
很久没写点东西，最近因为一些工作需求，要写一点比较有新意和前沿的东西，结合自己做安全产品的经历，在DevSecOps领域发现ASOC这个方向国内鲜有人讲，因此有了这篇文章简单介绍下ASOC这个领域。
ASOC我刚看到这个单词的时候，相信跟很多人的反应一样，以为是“Application SOC”应用安全的SOC，但是其实全称是“Application Security Orchestration and Correlation”应用安全编排与相关性，从后续的研究来看，可能跟应用安全的SOC也差不多意思，但是更有一些偏重的方向和额外的新意。
为什么把ASOC叫做DevSecOps皇冠上的明珠，主要是因为ASOC的建设一般处于DevSecOps体系建设的后期，企业威胁建模、SAST、SCA、IAST、DAST等各种工具集成、流水线运转基本完善后，进一步考虑增加DevSecOps体系的效率与漏洞质量的时候，才会试图建设ASOC平台。就像叠金字塔，需要下面的底座建设完善后，才能开始叠最上面的部分，这也并不是意味着ASOC是一个多好的方向，反而越基础的安全建设市场需求量越大，但是做好一个ASOC平台比做单品肯定要难不少，所需要产品经理对DevSecOps的理解也确实比做AST中某个单独工具要高，所以我们可以看到国外做ASOC方向的厂家并不多，主要是专门做DevSecOps方向的安全厂商在做完其他AST工具后，才开始涉足此方向，进一步完善自己的产品体系。
二、ASOC的定位
ASOC的概念在2019年Gartner的成熟度曲线中首次被提出
ASOC方向是结合了ASTO（应用安全测试编排）和AVC（应用安全漏洞相关性）两个方向，ASTO与AVC的概念均是2018年成熟度曲线正式提出，但是AVC方向在更早17年就有相关的分析报告了，并且Gartner貌似对“重构漏洞修复优先级（VPT）”这个点非常看好，很早就连着在AVC、RBVM、TVM三个方向中都提到了，可能修不完的漏洞早已成了大家的共识吧，必须区分一些优先级出来。
ASTO与AVC的概念正式提出一年后快速合并为ASOC，个人认为主要原因还是AVC方向的模糊性，虽然说AVC强调多数据源的漏洞关联分析，并没有强调在哪个阶段，但是提到AVC方向的主要还是开发安全厂商，貌似“开发安全工具之间的漏洞关联分析”才变成了AVC的定义，并且既然提到多数据源关联分析，那么数据源肯定需要聚合到一个平台上，这就跟TVM纯正的漏洞管理方向又比较重合，再加上现在TVM厂商也是被卷的没办法了，想各种创新能力，早就做到了多数据源关联分析，因此既然一方面AVC面临TVM厂商的合并，另一方面市场实践认为AVC在开发阶段做可能更合适，那么干脆就与ASTO一起合并成了ASOC方向。
以我对AST这个领域的了解，这么做还是非常有必要的，“建设一个DevSecOps的统一管控平台”已经成了大家的共识，统一管理统一分析可以带来更低的使用成本，以及在数据中挖掘一些更高级的内容，这个产品在市场已经是这么实践的了，已经发生了，但是这个事情迟迟没有一个明确的产品方向，估计Gartner也看到这一点，那就赶紧搞个ASOC做大一统，所以我前面说即使你把ASOC理解成“Application SOC”也没有太大的问题，方向上类似，只是细节不同。
但是多数的ASOC厂商只是做到了统一管理，做的好一些的做到了自由工具编排，如何从数据中挖掘更多的价值，只看到了小部分的实践，并没有太多令人惊喜的地方，跟安全运营领域的SOC产品对数据的挖掘程度相比还差不少。
三、ASOC的核心能力
既然ASOC是由ASTO和AVC两个方向合并而成，ASOC的核心能力自然而然就是这两个方向核心能力的并集，向上统一管控各类开发安全工具，向下统一对接DevOps各类工具，提供自动化流程编排与工具编排能力，流程与数据统一管理、统一输出，不同数据源漏洞的关联分析，重新对漏洞危险等级排序，提供漏洞修复优先级建议等。
3.1 应用安全测试编排（ASTO）
应用安全测试编排（ASTO）其所要解决的最主要的问题是，AST工具分类安全需求、威胁建模、SAST、IAST、SCA、DAST、模糊测试等越来越多，企业可能光是开发安全阶段的扫描工具就有十几种，这些工具都需要与CI/CD平台集成，并且不仅仅是流水线平台，还涉及到跟DevOps工具集成，如果我们把需要互相对接的工具连一条线，这就组成了一个庞大的网状结构，异常复杂，漏洞数据可能可以通过漏洞管理平台统一管理，但是工具的管理就必须一个个工具去看了，这带来了巨大的使用成本。
那么怎么解决？就像网络通信中的HUB，加一个集线器就好了，ASTO就是充当这个集线器的作用，向上统一管控各类开发安全工具，向下统一对接DevOps各类工具，把网状结构变成中心发散的结构，大大降低了复杂性，当然这也意味着ASOC平台需要进行大量的集成适配，能够对接各类开发安全工具，同时梳理清楚每个安全工具可以与哪些DevOps过程中的开发工具对接，包括流水线对接，在这些复杂的对接之上，包装出一个简易的可视化操作页面，这其实是很考验产品功底的。在拥有这么一个工具后，企业引入安全工具只需要把安全工具对接进入ASOC平台中，然后在ASOC平台中进行一些配置，工具就可以应用到DevSecOps流水线中了。
所以在定义中说道“ASOC工具应该充当应用开发与安全测试工具之间的管理层”，这么做的好处不仅仅在于降低成本，当所有工具都在一个平台中管控的时候，对比安全运营领域就像ASOR一样，平台开始具备一定的编排调度能力，ASOC平台也可以通过编写剧本的方式，规定AST工具在什么时候执行，获得什么样的输入，得到什么样的输出，输出到哪里等等这些工作，在仔细观察MAVERIX产品所展示的图的时候，可以看到例如OSA（开源软件分析，类似于现在的SCA）安全过程不止是在Build阶段进行，而是在Code、Test等不同阶段都有，通过剧本编排可以很比较方便的完成AST工具在不同阶段的调用。
同时在ASOC平台上，也会去集成所有安全活动流程，例如安全需求审核流程、完整的漏洞管理流程、软件上线安全审批流程等，当流程编排与工具编排碰到一起的时候，带来的就是比较极致的灵活性与自动化，当然这部分做好也非常难，需要足够灵活，才可能适配企业的各种情况，这么说可能太抽象，举一个具象化的例子来说明此过程的好处，例如
（1）.ASOC调用SAST扫描源码发现漏洞，由于SAST漏洞的误报率过高，安全运营人员通过ASOC筛选漏洞结果，将特别高危的某些类型，或者某些比较准确的规则爆出的漏洞输出到BUG管理平台，其他的漏洞待定
（2）.BUG管理平台上，研发修复漏洞后更改状态，漏洞状态反向同步到ASOC，ASOC发现漏洞状态为“研发修复”后，再次调用SAST进行复测，标记是否“修复成功”
（3）.进入到IAST测试阶段，IAST发现的漏洞带有执行函数与数据流，若发现数据流基本一致的漏洞，ASOC平台对比数据流，自动给漏洞打标上“SAST检出、IAST检出”的标签，代表该漏洞可信度高，若该漏洞之前SAST未推送到BUG管理平台，那么综合SAST的代码信息与IAST的数据流信息，一同推送到Bug管理平台；若已经修复，那么就不再重复推送。
这么一个过程是企业比较常规的漏洞管理过程，但是这其中什么时候调用工具、工具结果如何比对、如何避免重复推送漏洞，没有ASOC平台的情况下，免不了企业需要进行工具二次开发工作，这个也是ASOC所带来的价值。
3.2 漏洞相关性（AVC）
应用安全漏洞相关性，主要是把不同来源的漏洞信息，聚合进行分析，进一步确认漏洞的真实性，提供给用户最佳的修复优先级建议，如下这张图大致解释了AVC所做的事情
要搞清楚AVC能做什么其实也很简单，把每个AST工具所能输出的信息整理一下，发现其中的交叉点，就是可以重点进行关联的地方，例如上文例子中提到的，IAST可以获得运行时最精准的数据流，反编译可以得到代码信息，SAST可以获得程序分析推断出的数据流，如果入口点、执行点、漏洞类型一致，是不是大大提高该漏洞的有效性，毕竟两个工具交叉验证均存在，同时也避免不同工具的相同漏洞重复推送的问题，当然，Gartner所认为的漏洞关联分析，也貌似仅限于此，我们自己有一些更深入的思考，在下文中介绍。
值得一提的有两个地方，一方面是数据源不仅仅是AST工具输出，还可以是威胁情报和业务数据，这就类似RBVM的意思，不过威胁情报多在事件型漏洞如SCA输出的CVE漏洞中起作用。另一个方面，这些漏洞的输出也不仅仅是输出到BUG管理系统，在DevSecOps中也强调与Ops上线后阶段的联动，例如：选择暂缓的漏洞，输出到具备虚拟补丁功能的WAF或者RASP中，或者漏洞与安全运营过程结合，攻击这使用A攻击手法，且资产上正好有A漏洞，那么这条事件就应该提高优先级来处置，等等。
四、超出定义之外的思考
在研究了ASOC方向和相关产品实现后，深入思考这个方向，还能够发现很多可做但是没人做的事情，我思考的核心点是，只能做漏洞数据的互相关联吗？AST工具的输出只有漏洞数据吗？AVC仅仅只是做一些漏洞的去重，关联不同工具的结果吗？
很快我就给出了否定的答案，继续思考也让我看到了一些难以解决的问题的曙光，单工具困于误报率、漏报率问题久久不能解决，其核心问题是“工具自身是有能力壁垒的”，单工具就限定了分析方法比较单一，单一的分析方法决定了这个工具的分析上限，以前我们做SDL经常说的一句话是“不同工具有自己擅长解决的漏洞问题是不一样的”，反过来说也一样“不同工具有自己不擅长解决的漏洞问题”，但是厂商永远是希望它尽可能解决所有问题，导致误报漏报居高不下，例如我看到甚至有用SAST做逻辑漏洞检测的，这误报能不高吗？例如SCA工具就是通过版本匹配得出漏洞的，业界都是这个思路，所以报出的组件漏洞，不确定能否真实利用。这就是我所说的工具的能力壁垒，也是思想的壁垒。
这里只列举一些我看到过在国外产品上已经实现了的功能，更多我自己思考的，并且已经基本验证过可行的，这里就不写出来了，因为可能会涉及到我们自己做的后续产品方向，比较敏感。
4.1 打破壁垒的化学反应1-代码覆盖度
IAST的一个常见问题是，由于IAST一般是靠测试人员点击触发，所以测试覆盖度是一个比较大的问题，为了解决这个问题，IAST厂商都有识别API覆盖度的功能，那再进一步，代码覆盖度能不能做？以前没见到过哪个厂家做这个事情
超出漏洞本身去考虑，上文提到的一个问题，AST工具的输出只有漏洞数据吗？SAST只输出漏洞的数据流吗？不是的，做过SAST就知道，SAST是基本要做全部代码的数据流构建的（当然也有从危险函数反推的），那么SAST是可以输出全文的数据流的；IAST所输出的也不仅仅是漏洞是数据流，IAST可以把每条请求代码执行的数据流记录下来（可能反编译会有点误差，但是问题不大），那么把这两个数据流一对比，是不是就可以知道本次测试的代码覆盖度了？甚至SAST还能分析出哪些是新增代码，哪些是新增数据流，进而得到本期新增功能的测试代码覆盖度
上图是Code Dx在这个方面上的实践，SAST的分析结果用树状图展示出来，IAST有测试到的数据流，用额外颜色进行标记，从而得到代码覆盖度。
4.2 打破壁垒的化学反应2-函数可达性
SCA工具最大的问题之一，是无法确定爆出来的CVE是否可被真实利用，原因是SCA就是通过版本匹配得出漏洞的，业界基本都是这个思路，所以报出的组件漏洞不确定能否真实利用。如何去解决？或者有没有想过如何解决？还是做产品都人云亦云，业界是这个方案那我们也用这个方案，这最简单了。
我看国内近两年也有很多做SCA的创业公司，SCA入门的门槛低，好产品化，做到60分不难，做到90分是非常难，但是这些公司的产品看着能力都差不多，如何确定漏洞真实性、准确的二进制成分分析这些难点问题，没有人去解决，依然是难点，做出的产品都雷同。（腾讯前段时间发了具备二进制分析的SCA，还是比较厉害的）
函数可达性，是用以解决SCA无法确定CVE漏洞真实可利用的一个实践思路，如下图所示，是SNYK对此问题的探索，比业界做的跟进一步的是，他们收集了CVE漏洞的触发函数，给每个CVE漏洞标记一个漏洞函数，这个工作量不小，CVE描述中并不是所有的都描述了漏洞函数，这是一个堆人工的活。
有了CVE对应的漏洞函数后，利用SAST所分析的数据流，寻找哪些数据流上存在此漏洞函数，再向前推断数据流，入参变量是否外部可控，如果发现了外部可控变量到CVE漏洞函数的路径，那么就将此漏洞标记为Reachable，意味着该漏洞函数是可达的，该CVE漏洞很大可能是可被利用的。
五、结语
Gartner定义漏洞关联分析主要指不同数据源的漏洞数据，但是我认为这里的数据不应该只是狭义的漏洞数据，应当包括各类AST工具产生的如威胁模型、请求数据、数据流信息（SAST产生的推断数据流、IAST产生的真实数据流）、代码上下文、组件信息等等，把这些数据深入分析，进行联动对比整合，才能够得到一些如我们上面所举例的更高级、更有价值的结果，以此来解决更多AST领域现存的难点问题，例如SAST的误报率居高不下、IAST如何保证覆盖度、SCA如何确定漏洞真实可利用等。一个真正优秀的ASOC产品，可能在这个星球上还没出来，这个方向也是鲜有人去涉足的。
我们以前做安全产品，很多都是直接抄国外产品的理念与实践，这个其实无可厚非，北美的安全市场比国内领先大概5年，可以说先抄再根据国内实际情况做优化落地是最快的路径，但是这个过程走多了，抄着抄着也觉得没啥意思了，写这篇文章也是抛砖引玉，希望能引发更多人在这个相对未知方向上的思考和研究，万一真正优秀的ASOC是国内先做出来的呢？谁都说不准，可以有点理想，进行一些微小的工作。
