持续应用安全（CAS）研讨之：ASOC
一、ASOC浅析
今年是Gartner连续第四年在《Hype Cycle for Application Security》中提及ASOC（application security orchestration and correlation 应用安全编排与关联）技术，国外随着CodeDx、Cycode、Snyk和Apirro轮番巡演火的一塌糊涂，国内则方兴未艾。
甚至好多朋友都说，这个ASOC是不是就是Application SOC，是不是各种应用安全技术的中心化平台？这么说，既对也不对，一方面ASOC确实如同Security Operations Center一样，承载了应用安全技术的运营以及对结果的关联分析；另一方面ASOC似乎到不了一个整体运营中心的规模。
随着终端、边界和身份技术的大一统化，我们似乎也在应用上看到了这个趋势，越来越多的企业选择在开发中心建设ASOC平台来统一管理。今年也是第一年，Gartner将该技术列为Transformational级别，即革新性技术。2022年另外还有三项Transformational技术，分别是DevSecOps、SCA和SSE（security service edge）。从业界趋势来说这不是偶然，一是契合了今年RSA大会的主题“转型”，二是踩中软件供应链安全的大潮，因而也成为了Gartner分析师的共识。
ASOC在2019年提出的时候，由ASTO和AVC两个方向合并而成。ASTO强调的是向下编排安全工具链，以超级自动化的方式来完成安全活动；AVC则从漏洞入手，针对各种AST工具长久以来无法解决的误报、重复等问题，引入漏洞关联分析的手段协助用户进行更好的修复优先级判断。
这两个毫无疑问是ASOC的两大核心能力，构成了骨架和肌肉。在今年的Hype Cycle报告中有这么一段话我认为清晰阐述了ASOC的血液：即通过关联多维的数据分析完成开发安全的运营。有了这样的血液，骨架和肌肉才能更好的发挥技术价值。
安全开发的终点不能归结为漏洞处置，而是应以终（漏洞处置）为始，回到应用上，回到人上，回到组织上，真正的完成大闭环，这也符合当今的企业安全建设理念。无论是XDR还是零信任，亦或是SASE，我们都看到了这样的方向。现在行业里也开始喊出持续应用安全（continuous application security）的概念，没有起点也没有终点，而是一直在开发、测试和管理间进行流转和闭环。
二、CAS理念下的ASOC
持续应用安全，更为贴合现在敏捷、云原生、业务优先的开发模式。如果我们把SDL、DevSecOps和CAS放到一起看的话，可以发现一条清晰的优化路径。
SDL就像是1.0一样，通过细分了开发过程中的多个阶段以及安全活动，为企业指出明确的开发安全流程。现在很多企业都说SDL做着做着变成方法论了，变成文化了，也是这个原因，因为里面有人、技术和组织的交织，很难以一套技术框架来定义。
DevSecOps更为强调在SDL过程中的自动化表现，可以视为2.0。正因为发现了SDL的低效和部门墙等不利因素，因此尝试以机器间的沟通替代人与人的沟通，从而将安全左移落地。
而随着机器的增多，大家发现运 营变得低效甚至无效，机器的结果成为了人处置的负担，所以数世咨询发布的CAS理念作为3.0应运而生。持续的获得结果、关联和分析结果、最后加以自动化处置，成为了整个CAS理念的落脚点。
根据数世咨询发布的CAS理念，其中有几项核心能力涉及到ASOC：
自动化和编排：停止依赖于使SDLC变慢或成为事后考虑的人工过程。作为SDLC的一部分，应用程序安全工具的自动化和编排对于确保开发管道有效运行至关重要。
一个协作但细分的工具链：CAS需要确保在正确的时间将多种工具产生的信息片段传递给适当的参与角色，而不会淹没在整个SDLC中，以便安全人员和开发人员知道注意力集中在哪里、何时以及与他们在谁一起。
持续的拥抱问题、控制问题代替完全的消灭问题：事实上完全消灭问题是不可能的，CAS通过关联分析、问题优先级排序等方法大量去除噪音，使SDLC参与角色持续的看到问题，并控制它们。基于数据分析的结果将有助于人员做出决策，并提高处置效率，以持续化的方法迭代解决问题，而不是将问题以低优先级归档后置之不理。
如果我们把CAS比作是一场篮球赛的话，那么细分工具链相当于篮球运动员，而ASOC起到了教练员的作用。在整体的过程中，ASOC对下需要参与安全工具的编排整合，对上需要承接企业安全开发管理流程，通过安全运营剧本完成指挥者的工作。
三、比瓴的ASOC实践
3.1 扩展的编排能力
比瓴CAS持续应用安全平台（领域2.0）编排不限于XAST这样的测试工具，还有可能连接安全需求平台、漏洞管理平台、软件上线审批系统、业务协作系统等等。而编排的工具类型，为了适应现在的数字化潮流，也包括商业工具、开源工具和企业自研工具。之所以有这样的扩展，是为了充分的连接在开发过程中的每一个角色、每一次动作，从而创建出无数种可能性。
领域2.0通过在编排上的扩展，在业务层面引入更多的资源，创造了运营的多变。目前比瓴已经与酷德啄木鸟、孝道科技、四维创智、边界无限、思客云、云智信安达成深度合作关系，使各环节顶尖的安全能力双向互通，为用户带来体系化安全的便捷性与高收益。与此同时也支持SonarQube、Gofuzzing、Appshark等知名开源工具，真正做到了全覆盖的编排能力。
3.2 扩展的剧本能力
技术上看剧本是一段高度自动化的可被机器间通信和执行的程序，业务上看是一次企业安全运营过程。剧本创造了编排资源间所需要协作工作的所有上下文，包含数据流、逻辑流、主体、客体等等。领域2.0目前支持基于Timer、Message、威胁情报、流水线等多种触发方式，提供20多种开发过程中的常见运营模板。
3.3 数据分析能力
领域2.0从编排的多种资源中获得数据，以UEBA的视角进行扩展到企业安全治理层。
从发生错误的角度，根据代码check in的热度图来辅助决策某个部分的代码是否是关键业务代码，从而在此基础上提供更好的漏洞决策、代码保护；
从内部威胁的角度，通过检查系统中的高风险偏差来进行预警，例如从未知位置克隆代码或在短时间内克隆过多的存储库；例如去跟踪多次提交同类问题代码的开发者，进行安全培训；对于多次提交硬编码的开发者，进行严肃教育。
参考阅读
软件供应链安全研讨会全纪实
主动安全3.0与网络安全三元论
2022年应用安全报告：重要趋势与挑战
混沌工程在DevSecOps中的价值
Gartner预计关键基础设施攻击将成致命攻击