近日，CIS2021网络安全创新大会DevSecOps应用与技术专场在上海成功举办。本次专场由DevSecOps敏捷安全领导者——悬镜安全的创始人兼CEO子芽出品，聚焦DevSecOps的技术发展和应用实践。会上，多位专家结合自身研究或业务进行了主题演讲和圆桌论坛，精彩纷呈。其中，腾讯云产品安全负责人、腾讯安全云鼎实验室安全总监张祖优分享了腾讯云在DevSecOps以及开源治理方面的实践经验，以下为演讲实录：

这次我演讲的主题是“腾讯云过往的DevSecOps实践”。先做一个简单的自我介绍，我现在是在腾讯安全云鼎实验室，做云安全以及负责腾讯云产品的安全保障工作。

首先分享一下腾讯云安全工作的挑战。互联网公司与传统公司比如金融公司有个很大的区别点是，整体的基础设施和研发体系不统一，不同部门、不同中心的研发体系都是不一样的，而且腾讯内部有很多DevOps平台或者代码分析平台。此外，腾讯云上有300多种一类产品，细分到二类或是子级的产品数量会更多。所以我们在做整个业务线或者事业群的产品安全时，挑战都是比较大的，比较难落地。设想一下，安全需要落于研发和运维体系之中，如果研发和运维体系不够统一，那么安全自然是比较难落地的，所以对于整个腾讯云产品安全体系的建设，我们在思考到底以哪种方式去做。在比较早期的时候，我们采取的是漏洞防御体系，更多是从漏洞收敛的角度，主要以人工的漏洞挖掘为主，这种方式虽然快并且效果明显，在早期可能比较适用，但是后期会发现，这种方式其实是有疏漏的，所以我们现在采用的更多是全生命周期的收敛方式。

下图是我们基于风险引入流程梳理的体系图，分为风险引入、风险发现与防护、响应处置和闭环改进四个维度，基本涵盖了产品安全各个维度能进行的活动。

基于风险引入流程进行收敛

在整体的建设过程中，我们分了4个阶段。

因为可能跟传统厂商一样，我们更需要做到反入侵，所以在第零阶段，我们做的是边界管控，针对一些对外开放的资产，比如外网IP、域名等。在随后的第一阶段，就是从无到有地补齐安全能力与安全活动。

第二阶段是追求精细化运营。在我们内部，产品的形态有好几种，包括第三方引入的、OEM的以及合作研发的，此外还会涉及线上的产品包括私有化交付产品。这几种类型的产品，关注点是不一样的，比如线上产品，大家可能更关注它有没有实际的会导致入侵或者导致服务器被控制的漏洞风险；而OEM或者合作研发的产品，它的研发阶段可能不在企业内部，所以采用的是一种安全准入的机制；像私有化的产品，比如腾讯云私有化产品，其实不影响腾讯自身安全，因为是交付给客户的，但安全问题影响产品口碑。所以在这个阶段我们更多是采取精细化运营，就是针对不同的产品安全场景去建设不同体系。

到了第三阶段，我们更多希望的是提高效率，提高业务团队在安全方面的参与度，提高安全的度量，所以在这个阶段，我们的重点就是实践DevSecOps。为什么要实践DevSecOps？这可能大家都理解，安全左移的目的其实就是因为整个漏洞的收敛，在越左阶段的处理成本会越低。过去为人熟知的是微软SDL那套机制，如今DevSecOps为什么这么火？是因为DevSecOps与SDL相比有个较大的差别：在SDL中，很多时候是安全兜底，安全永远在研发运维之外，但是DevSecOps更多强调的是，安全治理决策不仅仅归安全团队负责，开发、运维甚至QA，都是安全治理的角色之一，它要求人人为安全负责，把安全嵌入到开发流程体系中。对安全的要求不同，原因在于研发运维模式的变更，而安全是要适配自身的研发运维模式的。腾讯云之所以落地DevSecOps，是因为在腾讯内部，腾讯云也是比较早实践DevOps的业务线，那么从安全的维度上就需要跟进DevSecOps。

DevOps模式讲究的是诸如最小模块化这样的技术，这在传统模式下可能是没有的。举个例子，腾讯会议还是一个内部应用时，它的安全保障就是我们做的了。后来腾讯会议被广泛使用，260天迭代了29个版本，对于这种迭代速度如果我们还用过去传统的安全模式去做安全建设，肯定跟不上，即便当时我们专门成立了一个项目组去保障它的安全。所以我们需要一个新的安全模式也就是DevSecOps。

我认为SDL和DevSecOps两者之间不存在很大的冲突，并不是一个取代的关系，只是各自适配不同场景。相较于SDL模式，DevSecOps讲究的是更多自动化的融入、敏捷的迭代。而且通过每年的RSAC会议讨论主题可以看出，DevSecOps本身是一个在不断发展的安全框架，它并不是一成不变的。DevSecOps分成了10个阶段，其中第6个阶段原来叫configure配置，现在叫prevent预防。它本身就是一个在不断完善的理论，所以每个公司对DevSecOps的使用是不一样的，要与自身的研发运维体系适配。我们在对腾讯云过去的安全活动进行梳理，可以发现过去做的很多安全活动是在Ops（运维）阶段，比如经常做的黑盒测试，在上线前做得相对少一点。所以我们选择实践DevSecOps体系是基于之前梳理总结的结果，需要在开发阶段补充更多活动。

DevSecOps的核心是流程、技术和文化，最难的是文化。整个体系落地的关键点主要有四个：最底层的是工具链的建设；第二个是核心的自动化测试能力，比如IAST、SCA的能力；第三个是基于CI/CD流水线的安全嵌入；最后需要关注一些新的关键技术，比如容器安全、API安全。

实际在建立DevSecOps体系时，我们分了两个阶段。第一个阶段是腾讯云内部多平台的阶段，DevOps平台和代码分析平台都是不统一的。我们于是采用了一种方式，就是把安全能力向多平台适配，把各种安全工具封装到多个DevOps平台，而在一些统一的平台比如Git仓库，我们会做主动扫描。然后通过统一的数据上报来统计和确认业务的覆盖度，并通过统一的安全运营平台来实现安全问题的告警、度量等工作。

到了第二个阶段，腾讯云内部的产业事业群成立了一个技术委员会，统一了DevOps平台，于是安全体系的落地也转变了方向，我们把安全能力落实到这个统一平台的功能里面。这个统一的DevOps平台包含几个不同阶段的功能，所以我们要基于不同的功能去分析有哪些对应的安全能力可以在功能里直接嵌入，其中当前比较成熟的是开发、测试还有制品管理这三个阶段。本地开发阶段主要基于DevOps平台的本地流水线，通过ECI去落实；代码分析阶段，我们主要嵌入了SAST代码成分分析、SCA以及敏感信息检查；自动化测试阶段主要包含黑盒DAST以及IAST，关于IAST，除了依靠内部能力，也在试用悬镜的灵脉IAST；制品管理阶段需要比较多的能力，如容器镜像扫描、二进制文件分析、病毒木马检测等。

为什么在这里我们要做工具的封装，很重要的一点是原来用的很多安全工具在现有DevOps流水线上不一定适用，比如有一些过去自己研发的安全引擎，放在流水线上让业务同学去执行，却要执行十几个小时，这对于业务团队来说是无法接受的。所以原来的工具并不是拿过来就可以直接用，要涉及封装。还有本地流水线的检查和线上流水线的检查，规则的复杂度不一样，本地相对简单一点，线上可能复杂一点，但是也要考虑时间的因素。而针对一些我们当前没有能力触及的方面，更多会采用商业化采购的方式快速补充。

代码分析阶段，刚才讲到的是三项能力，SAST、SCA以及敏感信息检查，主要是在本地和CI/CD两个场景下去嵌入的。自动化扫描工具SAST是直接嵌入的。自动化测试阶段涉及DAST，主要是通过测试环境的流量转发的方式，刚才悬镜安全的子芽也介绍了，准确来讲这是广义的IAST。我们过去在这方面做得比较多，就是通过流量转发的方式去实现上线前的扫描。另外关于IAST，我们主要是在测试环境中去集成和测试。

在制品安全这个阶段，我们平台有一个制品库能力，可以直接在制品库里集成安全检查，也就是说所有的DevOps流程中产生的制品会统一放在制品库中，而制品库的所有制品默认都要进行安全检查和安全提示。不过目前还做不到拦截下载，这是下一步要完善的，我们会在CD的过程中加一个能力来针对识别出安全问题的制品，拦截它，不允许它使用。

在更早的威胁建模阶段，我们采用的是半自动化方式，通过问卷加自动化的API调用这种多模式的结合来实现半自动化。针对大部分的产品，我们是让业务自己填自动化评估过程问卷，然后由系统进行一个自动化的判断，判断是否合理以及识别哪些点是有风险的。针对一些重点产品，比如腾讯会议，可能还会涉及人工审核，在新功能上线前，以人工评估的方式为主。

安全编码规范这部分，是基于公司整体编码规范的检查来做的。我们其实有两个版本的安全编码规范，其中一个版本是腾讯开源出来的基于开发语言的，之前还有一个版本是基于漏洞维度的。

我们也在尝试框架安全或者默认安全，比如在治理SSRF（服务器端请求伪造）漏洞的时候，我们尝试做一站式的SDK（软件开发工具包），让业务在接入时不用考虑太多研发问题。

还有在DevOps平台中，我们考虑加入安全视图。这种安全试图可以让业务人员一站式地看到安全相关情况以及接入情况。因为业务太多，每个业务的DevOps成熟度以及研发运维的流程都不一样，没法用统一的标准去要求，所以我们对DevSecOps统一的流程要求和标准做了个分级，分为1到4级。统一的要求是1级，针对一些DevOps成熟度高的业务，比如腾讯会议，级别要求会更高。

也会涉及建设度量，分为两部分，一部分是对业务安全的度量，比如度量产品是否安全，另一部分是对DevSecOps实践效果的度量。针对后者，主要有三个维度，一个是能力建设，一个是运营推广，最后一个是效果。

在这么多的发现工作之后，还涉及风险收敛。风险收敛是有区分的，因为它跟整体的安全度量是绑定的。我们在内部推行一个叫安全信誉积分的指标，这对业务的威慑力比较大，因为假如某个团队分数小于80分，是要求团队的领导者去解释的。因为要鼓励业务尽量在上线前发现问题，所以安全信誉积分的度量会在上线后，并且会进行一个度量惩罚的机制，但是在上线前不会纳入。这就会有收敛的差别，比如上线前的一些流水线，我们更多是通过门禁去拦截，主动扫描相关部分就不纳入到度量机制里，通过风险处置平台去推动。线上的常规性扫描可能会纳入安全工单去跟进。还有Nday和0day漏洞是不可预期的，我们也不会纳入。

最后谈谈开源治理。我觉得在互联网公司做开源治理挺难的，原因就是我们没法像其他公司那样从入到出全流程去管控，尤其在入的阶段能做的事太少了，因为像腾讯这种公司，供应商、合作方的数量太多，根本没法去管理，所以我们在使用阶段和管理维护阶段做的事情比较多，这里做个分享。

这是我们之前关于log4j2事件响应的流程。

log4j2事件响应流程

第一阶段是情报的获取，我们建立了一个漏洞情报的监测机制。第二阶段是情报的研判。并不是所有情报都会获得高规格的响应，我们会研判出漏洞的影响程度尤其是对腾讯的影响，比如对于有些组件，腾讯没有用到这个技术栈，就没必要响应。在影响清查阶段，我们做得比较多，采用了几种方式，首先是上线WAF的防护规则，其次采用三种方式，一种是SCA，通过代码层面去识别具体哪部分使用了Log4j2；另外一种是通过PoC的方式，测试哪些暴露在外网的业务是实际上存在漏洞的；第三种，通过HIDS去识别主机层面的log4j2的Java包。针对一些重点产品，我们会做人工的排查。在整体的收敛优先级上，以外网的漏洞为第一优先级，通过SCA和HIDS识别出来的漏洞次之。 

在基于情报的风险清查方面，我们基本上是采用这样一个机制：从监测、分析、资产匹配、影响面输出到推动修复。这里还涉及资产测绘的能力建设，因为一旦一个漏洞爆发，再去探测其实有点晚了，所以需要提前做好资产测绘，这样可以很快地匹配出影响面。

关于开源治理，我们主要是在组件识别与安全管控这方面做得比较多，也会涉及一些规范，比如腾讯有一个软件源，我们在其中嵌入了安全检查，一些假的包或者存在漏洞的包，是不允许被下载的。但是我们没法要求用户只能使用腾讯软件源，所以做得更多的是在中间阶段。整体的组件识别采用了三种方式，一种是SCA，一种是传统的网络探测，Banner识别，最后一种是主机探测。安全治理角色也有三类：兼职的业务安全接口人、安全团队以及QA。此外还有风险处置平台。因为厂家根据几十万个安全问题，通过表格来跟进，是比较累的，所以后面不断迭代优化，推出风险处置平台。

如果从开源软件的全生命周期来总结，大概有以下几个维度。在引入阶段，一个是对软件源做相应的检查，业务会主动做安全评估和引入报备，此外还建立了开源组件安全管理规范。在使用和维护管理阶段，我们采用黑名单的方式，比如Struts2是在腾讯黑名单上的，不允许被使用。

以上就是我想分享的，谢谢大家！

悬镜安全

悬镜AI（北京安普诺信息技术有限公司）由北京大学白帽黑客团队"Xmirror"主导创立。公司力求以人工智能技术赋能信息安全，在公司研发的产品中，深度结合机器学习、红蓝对抗、攻击链模型等技术，为企事业单位提供前沿高效的DevSecOps全流程AI安全管家服务。