从混沌到体系化：DevSecOps在腾讯云的落地实践

白凡

作者简介
张祖优，腾讯云产品安全负责人

我现在在腾讯安全云顶实验室，我从事安全差不多12年的经验。我过去可能更多偏向于做攻击者的角色，慢慢转向做企业安全体系的建设。所以今天整体分享分为四个部分，首先讲讲腾讯云的产品体系和安全挑战。接下来从腾讯云安全体系的发展过程讲讲我们都做了哪些事情，以及我们做了哪些DevSecOps尝试落地的动作。

1. 腾讯云产品体系与安全挑战

第一部分介绍一下腾讯云产品体系和安全挑战。我准备PPT之前，一开始定标题的时候还挺担心腾讯云几个字有广告的嫌疑。他面临的问题第一点就是产品非常多，目前腾讯官网上有50+产品分类，最多的时候我们面临的产品单单产品上线就是日均将近10个新产品上线，版本更多了。

另外目前腾讯云的产品形态和研发场景也是相当复杂，有很多自研的产品还有合作研发的，包括OEM等。有一些Saas层面的，Paas层面的，Iaas层面的，也有各种云的形态，专有云、私有云、公有云、混合云等等，可以看出他的产品形式多种多样。

包括里面使用的技术栈和架构也是很多，腾讯这边主要是C，其实腾讯云前端主要偏向JAVA这样的框架，包括GO、PHP等等。产品形态Web应用、APP、客户端、小程序等等。还有各种中间件，一些新型架构。

在人员层面也是非常复杂的，腾讯是比较庞大的体系，像腾讯本身总部的员工，还有腾讯也有相关子公司也参与到研发过程当中，还有投资的全资子公司，也在研发体系内，包括找一些外部企业做一些研发工作，所以这里涉及到人员的结构。公司甚至是团队之间，比如跨公司、跨BG、跨部门、跨业务线、跨中心。

所以我们想做好腾讯云的产品安全，这些问题给我们带来的挑战都非常多。比如说最典型的问题，就是不同的中心研发和发布流程可能都是不一样的，腾讯对于自己正式员工的安全要求比较高，过去我们在做很多安全动作的时候发现比如说外包同学或者实习生也好，经常安全意识不到位。本身你的研发流程不一样，每个团队对安全的重视角度也不一样，所以产品的安全角度也参差不齐。另外过去其实不怎么重视外部引入产品也好，这种外部引入风险在安全角度的重视上也是不够的。包括安全团队的职责划分，像我这边负责腾讯云，很多腾讯上的产品其实不是这方面负责的，从我的职责就涉及到跨团队安全落地的问题，我就要和其他团队做协调协作工作。包括腾讯云确实是后来者，我们在安全团队建设角度上也是人数包括相关流程，其实比较后期才建立起来的，这有一个问题就是安全跟不上产品发布的速度。产品的需求发布是快速迭代的过程，安全的话毕竟人数有限，所以有时候不能把所有产品的安全都覆盖住的。包括像工具，很多工具在云的场景下涉及很多新的架构，比如像API的流行，以前一些工具可能不能解决API的流动问题，这些都会带来各种各样的挑战。

2. 从边界建立起的安全防线

当我接了这个工作之后，我的工作就是怎么保障腾讯云的安全。我们第一步做了从边界建立起的安全防线。我一开始分析这里的核心关注点，其实有两个关注点，第一个就是从产品层面是不能出安全问题的，这里安全问题有两个纬度，一个是不出现严重的危害安全问题，比如说被入侵的安全漏洞。第二种就是不能出现很傻瓜化的轻而易举就能发现的安全问题。
第二点就是保障核心数据安全，涉及到入侵，就是保障内网的安全，内网里面有很多运维系统，可能安全的坚固做的不是特别好，所以很重要的一点就是保障内网的安全。还有一个点就是减少入侵的入口。

所以我们第一阶段主要做几个事情，第一个就是安全管控，分别从腾讯云的外和内两个纬度做。比如在外这个纬度，安全的攻击其实是有目标性的，是针对比如说对外的应用或者是对外的服务器，这两者对应的就是域名和IP，所以我们首先建立了流程，就是对域名的解析，对外网IP的放通进行了管控，所以我们首先做的就是流程，两个审批流程。这个建立的目的就是减少非必要的风险暴露面的开放，导致攻击入口的增加。

第二步在内当时简单建立了一个流程，是产品上线的检查流程。我们其实没有覆盖到所有版本，主要覆盖新产品上线。首先保证他是相对安全的状态进行上线，所以我们在腾讯的产品发布流程里面建立了产品审核的流程，这个流程过程当中就定了一些安全的一些检查要点，产品必须满足我的检查要点，做完相关的安全动作之后才允许你上线。第二个像腾讯云其实和腾讯的其他业务有比较大的差异，就是他有很多ToB的场景，比如说合作研发也好、OEM也好他有这种特殊的产品，包括过去腾讯很少有比如说内部的运维系统需要对外开放的。但是在ToB场景下，很多内部使用的系统要通过外面的公司减少人力的压力，就意味着一些相关系统要往外放。这些场景下也会带来一些安全风险。所以我们卡了另外一个口，就是对ToB场景需求的安全审查和审批。
这是针对新增的做法，其实就是减少风险。我们接触这个事情的时候，腾讯云其实已经有很多存量产品在线上，我们当时采用的一种方式就是有限的人力关注重点项目，关注基础的产品。什么是重点项目和基础产品？比如说COM这种机器等等，是我们优先需要关注的。同时我们通过配合测试，这里不得不提一下腾讯内部其实挺多工具的，这是腾讯过去这么多年安全的积累，还是有很多工具的，就是人工+自动化测试方式，去发现这种风险。这是我们第一阶段做的事情，为了解决刚才说的两个纬度的核心关注点。

当时我们做这个事情，像我们人力做的事情其实不敢宣传的，更多还是属于主动找目标，包括关注安全的业务团队会主动找过来做这样的事情。这里的问题就在于人力投入非常大，比如你通过人力做代码审计也好还是什么，我觉得我们团队很高效的，最高效的时候一天能完成四五个版本的安全测试，就两个同学，所以这是很高效的。但是想想腾讯云那么大的产品量，如果我们把这个口子放开的话，我们的人力覆盖不了的。所以我们做这个事情的时候，其实我们是耽误了产品的上线，这是比较现实的问题。

3. 基于风险控制的安全体系

第一步就保障重要问题包括入侵事件风险不是那么突出，不出问题。第二步就要考虑怎么样全面建设安全体系。我当时做这样的事情，也是参考了很多知名的安全流程，最后做出腾讯云安全风险收敛体系。从几个体系来做，风险的引入控制、风险发展与防护、响应处置、闭环改进，四个环节来做的。
在风险引入和控制这个纬度，我们做的第一件事情就是安全意识的提升。我们当时碰到的明显问题就是业务团队对安全的重视度并不是那么高，可能更关注的是我产品的快速迭代、产品的上线，而不是说当他不出现安全事件的时候，他不觉得安全有多重要。所以我们首先做的是安全意识的提升，培训的事情。
第二个事情就是规范和指引，我们在做安全的过程中也碰到问题，就是很多团队也重视安全，但是不知道怎么做，业务团队其实不知道怎么选择。所以我们做的第二个事情就是输出了一系列规范和指引。包括你如果帮他做更好的解决安全问题的话，你不要指望他掌握很多的安全知识，所以你要尽量帮他解决很多问题，所以我们要做安全开发库，包括一些黑名单的东西告诉他哪些是不能用的。这是风险引入控制的三块内容。我们第一阶段已经做了部分的安全管控的东西流程建设的东西，比如说新产品的上线也好、域名的申请也好，都是需要建设的东西。
另外就是资产管理，这也是风险收敛体系过程中我觉得一直没有做好的东西，不管是攻击还是防守都是有目标的，我们要做的就是要把腾讯云有哪些IP或者主机设备或者域名包括他有多少个产品、多少员工，把他梳理清楚，我们才能针对性地做相关动作，建立安全防御体系。但是到目前为止我们还没有梳理清楚，这也是跟企业内部的一些文化，大家也知道腾讯的中台也好或者技术站也好都是被外面所诟病的。所以基于腾讯的整体情况，我们想做数据这个事情其实不是那么容易的。
另外在发现与防护从两块入手，一块就是应用安全，一块就是主机安全。应用安全就是在上线前、上线中、上线后三个纬度，去建立产品的安全检查体系，通过自动化或者人工，包括整个检查的过程中我们其实辅助了一些人工的手段，人工或者自动化的审计也好。其实还有一些邀请外部安全厂商这种方式，包括腾讯内部是有专业的安全合规团队，也会通过合规角度做一些内审的工作。
在主机层面主要针对几个问题做，一个就是基线扫描，还有第三方主机安全，这些做的比较少，还有针对风险的风险服务的收敛，端口的管制等等。还有最基本的两个防护体系，一个就是外部的防护，还有就是入侵检测，在这之上我们通过安全演习做了整个体系的验证检测。在这之外还涉及到比如说员工的违规行为，会涉及到信息泄露，我们也联合了其他安全团队建立信息泄露的监控体系。再之前就涉及到安全情报，其实做安全工作的话情报是非常重要的事情，你把内部的这种安全做的再好，也抵不住突然爆发的一个漏洞，也许在你专心工作的时候他是没有问题的，但是漏洞的爆发可能让你整个体系打开一个缺口，所以对于安全情报的监控是非常必要的。监控完之后就是及时的响应。

在这当中还有比较多响应处置的事情，我们当时联合了QA先制定了事故定级和违规通报的处罚体制，为什么要做这个事情？说来也是安全意识传达的不到位，很多同学确实如果不从惩罚的纬度定一些要求的话，他们可能不把安全当回事，这可能是安全团队面临的尴尬局面。所以我们先定了这样一个相关规范，包括联合QA，其实腾讯的QA是非常强势的团队，所以我们整个安全体系的建设都比较依赖于QA帮了我们很多东西。
响应方面做完之后就是闭环改进，包括安全运营也好、运营的统计也好，做一些整体安全质量工作的统计反馈，进而做相关的策略优化、流程的改进。这就是我们搞的腾讯安全风险收敛体系的事情。

像安全宣导这一块我们搞了一个图，我们当时达成了一个共识，安全的先导培训非常重要，不然后续的所有安全工作都是展开不了的。所以我们围绕了员工从入职到运维操作，包括产品的上线，这样一个流程建立了一系列安全先导的动作。包括在新员工入职线下培训的员工，会给他们安全培训材料，要求员工必须完成相关的安全内容的学习和考试，并且通过考试参与相关的前线。如果真的出现安全事件，也可以驱动业务同学学习相关安全的知识。后续我相信安全团队做安全培训和宣导，更多通过事件角度来做的，因为很多业务团队真的就是出了事件才会觉得安全重要，所以通过事件这个纬度也是比较好去宣导安全相关的东西。这个流程下还涉及到我们要做安全培训的材料也好，制作相关课程也好，基于现有的媒体平台发布相关的宣导也好，所以我们是整理了这样的体系。

做安全宣导里面比较重要的事情，就是针对外包和实习生方面的安全宣导。从腾讯云的历史经验来看，经常出问题的就是在外包和实习生环节里面。宣导怎么样让他更有效果？我们做了各种方式的宣导，其实有种宣导方式最有效的，就是线下培训。我们去年大概搞了34场线下培训，这个数量大家可能觉得难以理解，我们基本把腾讯云所有中心全部覆盖了一遍，每一场基本有两三百号的同学。为什么说线下培训最有效果？因为很多业务团队其实对安全不是很了解，包括对安全存在很多疑问。我们过去通过宣导也好包括媒体宣导也好包括在线课程也好，其实都是强制性地给他灌输内容的，他其实还是有对安全的疑问。线下培训有一个很大的好处就是面对面的沟通，我们可以针对他的心里疑惑去解答，包括让他理解为什么要做这个动作，包括他可能会有一些挑战我们也可以现场PK，是很容易达到宣导效果的。
像腾讯云，在过去安全违规的事件包括入侵事件，我们去年做了宣导培训之后，最有效的感官效果就是现在基本没有出现类似这样的安全违规的事件，有出现基本也是历史原因导致的。

可以看一下过去我们做的宣导方式，比如邮件、墙面海报、平台还有贴在厕所的宣传内容，包括企业微信有应用推送类的功能也会推送一些内容。我们一直在做的事情，也是比较重要的事情，就是建立前沿的安全培训和考试的覆盖，我们要求所有腾讯云的同学必须完成在线的安全学习和考试，不分研发还是运维。其实这里内容会有区分，比如说非研发运维同学，我们会让他完成办公安全相关的内容学习等等。我们通过最简单的方式邮件通知，只要你没有完成考试我们会一直给你通知。其实从整体效果来看，腾讯云目前基本完成了百分之八九十的覆盖率。

第二部分我们做的另外一个事情就是发规范发指引，去年这种正式的业务级的规范其实6篇，安全指引将近30多篇。这里为什么发规范？其实很多团队和运维同学是有安全意识的，但是他不知道要做哪些事情，所以你必须告诉他该怎么做，有相关的参考资料给他。

最重要的部分就是安全检查的动作，检查主要分为两个纬度，一个是人工的纬度，一个是自动化纬度。第一部分是安全合规审计，是偏人工的纬度，这其实也是比较好去推动产品做安全检查的出发点，从产品的角度可能对于安全不太关注，但是对于客户角度会对产品的安全合规有要求，迫使他必须通过相关的安全认证等等，从合规的角度推动产品做一些规范性的整改。包括我们邀请外面的安全厂商也好做安全众测，以及自动化的代码审计。另外就是通过周期化的自动巡检，包括人工代码审计，黑盒测试还有上线前的扫描等等。

其实腾讯有个好处，腾讯这边也是推标准化，像测试环境有一个统一的测试环境平台，大部分业务是接入的，所以我们可以直接和测试团队打一个合作，再通过他的测试环境做流量采集，再做自动化的黑盒测试。上线前的扫描测试也有一个好处，你针对线上环境的自动化扫描一般容易污染线上业务环境的，所以这个方式就容易解决这个问题，又能把安全问题提前发现，避免把安全问题到了线上。

我们还做了比较多的众测赏金计划的活动，比如说腾讯会议发起的百万赏金计划，通过国内外的白帽子去发现产品安全问题。

主机安全风险收敛方面主要针对三个纬度做，一个就是高危端口，还有系统漏洞和风险服务，另外人工推动风险服务的收敛。像高危端口方面我们是自己构建的监测平台，这个平台基本是人工不管的，这个平台实现了全闭环的应用流程。我们针对所有的外网IP进行监控，其实内网IP我们也有监控，但是可能没有告警。

对所有外网IP进行监控，一旦发现高危端口的开放，我们会直接联动工商系统进行告警，通过工商系统进行事件的跟进，业务同学就必须修复，完全实现全部自动化的闭环。像高危端口这个东西的开放，过去我们也做过相关东西的统计。为什么会出现这种开放？有几个大概纬度，一个就是运维同学也好经常出现一些操作不当的问题，还有外网IP没有及时的收敛导致外网IP的误绑定，还有有些同学意识不到位导致开放的危害，还有就是运维不当比如说你的策略是临时策略，重启要失效了之类的。还有一些同学可能会拿着内网的机器做测试，会临时开启一些环境，就会导致端口的开放。过去像腾讯云出现的入侵事件，我们都是通过入侵检测环境都是有效发现并且阻止了，但是相关风险动作还是出来了。我们分析了一下过去的入侵事件，大部分都是高危端口的开放导致的。

另外就是漏洞情报和资产测绘方面，我们有专门的团队做漏洞情报的跟进，我们还建立了资产测绘。做这两者的目的其实就是你内部体系做的再好，也解决不了外面漏洞爆发导致的安全风险的引入，所以我们必须做这样的监测，一旦外网漏洞的爆发我们能马上感知到然后去跟进。为什么要做测绘？资产测绘的目的就是识别腾讯这么多服务器里面，有哪些服务器按照哪些主键按照哪个版本，一旦哪个版本出现漏洞的时候，我们可以及时感知到底有多少受到了影响，就可以马上推动修复的工作，这是一个漏洞情报和资产测绘的必要性。

下一个也很重要的就是信息泄露，过去这种问题也碰到很多，就是止不住的信息泄露。大家可能听说过很多信息泄露的事件，包括国内外信息泄露的事件，包括比较多的都是信息泄露导致的。比如说典型的很多企业都用公有云，公有云通过你通过控制来操作，也允许你通过API的方式，这里就涉及到密钥的管理工作，大家可以尝试搜索一下，Github上有一大堆密钥开发的东西，黑客拿来就可以直接控制你的这些云资源。对于腾讯云也是一样的，也会存在这种风险，所以我们其实建立了这样一套信息泄露监测的体系，包括和Github官方的合作，达到一旦发现泄露马上感知、马上处置、马上止损的效果，包括一旦出现我们会进行及时的通报等等之类的。

还有就是应急响应方面，是比较常规性的工作，我们其实有做一些优化。这里更多强调自动化统计运营的动作，包括建设一些安全客服也好、智能机器人也好，通过自动化的方式减少安全团队的投入。

最后是运营统计，我可以介绍一个我们的经验，我们过去发现每个月其实对于业务团队的压力不大，业务团队可能没有什么感觉。所以我们和QA制定了一个信誉积分，每个月每个团队的分数100分，当你出现安全事件的时候就会给你扣分，一旦你的分数小于80分，我就要求你团队的总监必须答复为什么分数这么低，以及后续的改进措施。在我们过去的实践效果中是有一些效果的，能让很多团队被动地重视安全。这个虽然说不是我们初衷希望的，但是为了安全的防护，我们其实有必要做一些可能得罪业务团队的事情，也也是安全团队比较尴尬的事情。

最后一个纬度就是安全演习，像腾讯云去年做了三场超过半年这样的安全演习红蓝对抗的事情，从办公安全、内网的服务安全还有产品安全三个纬度，通过内部的演习体制验证腾讯云整体安全体系的完善性或者强壮性。假如说发现问题，我们也能够及时修复。我们去年做了三场演习，效果还是很明显的，发现的问题还是挺多的，当然这些问题目前已经修复了，就是说这种演习在腾讯云内部是常态化的动作，通过红蓝对抗。

4. DevSecOps的尝试落地

最后部分讲讲DevSecOps做的尝试落地，DevSecOps落地其实和企业落地的事情息息相关的，我们也是跟着整个研发团队包括QA的步骤来做的安全动作。我们一开始做的时候有三个问题，为什么要做？怎么做？假如这个事情特别大的话先做什么？我们做安全还是挺累的，你就是不断要掌握新的知识。

我们要先了解什么是DevSecOps，DevSecOps其实是Gartner2012年创建的概念，他的核心理念就是安全是整个IT团队包括开发测试运维安全团队包括QA也好所有成员的责任，需要贯穿在业务生命周期的每个环节。过去我们更多强调可能安全团队的角色就是安全团队为安全兜底，跟业务团队可能关系不是那么强。另外强调每个人对安全负责，还有安全工作前置，尽量往开发工作左移，还有就是柔和嵌入到现有的开发流程体系。这是DevSecOps核心的理念和主要的点。

为什么要做这个事情？根据去年发布的中国DevOps调查报告来看，其实DevOps在互联网、金融行业、运营商等已经得到广泛的落地实践，所以对于腾讯云这样一个大的体系其实也是一样的，很多团队已经在落地实践这样的东西，包括有的团队已经实现很久了。DevOps为开发团队带来更快更好的开发协作，团队可以比较快速的几周甚至几天之内，像腾讯会议过去一百天发布了20多个版本，他可以快速提高敏捷性和效力。这里的安全就很容易成为一个瓶颈，过去腾讯会议的安全也是一样的，就是安全跟不上腾讯会议的开发节奏，我们永远是滞后的。随着DevOps的流行，DevSecOps也是势在必行，我们必须落地实践相关动作，不然的话安全可能就会成为比较大的矛盾。

为什么一定要把安全动作前置？在应用生命周期的各个阶段，漏洞的修复成本随着开发生命周期是逐步上升的，从研发到测试到发布到运营，可能是两倍、十倍、百倍的进行，当你产品上线的时候你要修复一个漏洞需要考虑很多问题，比如说对于产品的影响稳定性之类的，所以说左移是能让修复成本降低的。

包括我们过去做的是SDL，SDL到DevSecOps是两种角色转变，过去安全是在外面，DevSecOps这样的角色其实是安全和各个一起参与的，是协同共作的状态。包括可以看到从传统安全到DevSecOps几个比较大的差一点。比如说过去是安全责任，安全团队是主要的责任方，DevSecOps讲究安全是每个人的责任。SDL安全较缓慢，也常置于流程之外。DevSecOps柔性嵌入研发运维流程，更讲究自动化。还有过去可能安全团队经常需要大量人工的参与做安全的动作，DevSecOps更多讲究的是自动化的流程，能做应急反馈处理优化这样的动作。DevSecOps也不是万能的，并不是适合于所有的业务。为什么做这样的分析？

目的是我不希望腾讯云第二阶段做了那么多工作成为白费的，当我们想落地DevSecOps情况的话，假如说要把第二阶段做的事情推翻，这其实不是合理的状态。所以我们做了这样的分析，我们发现这里并没有存在明显的冲突，只不过DevSecOps可能更进了一步，他可能更讲究自动化、更多的前置包括做安全防护的处理。

既然要做就要讲讲怎么做，DevSecOps有三个关键点要做的，一个是人和文化，包括说安全意识的培训，鼓励开发团队为安全负责，每个人都是安全的责任人，形成这种共识和认知。以及流程方面，要做流程整合，要做定期代码检查红蓝对抗也好，要建立安全情报机制，加强与业务部门的协作等等。在技术方面涉及到要有相应的安全工具，实现更自动化的安全检测，相应工具要能够嵌入到相应流程里面。

这是DevSecOps的九大实践要素和文化融合的七个阶段，看几个关键点。一个就是意识方面、编码方面，还有自动化的代码分析，还有第三方导入代码的分析，以及漏洞的处理方面要形成共识，要有工作的流程，包括相关安全评估的引入。

我们当时参考了相关体系之后，回头看了一下腾讯云过去的安全工作，把相关的安全工作往里嵌。我们更多是Ops的阶段，在开发阶段比较少，因为过去安全阶段更多做保障做兜底，而不是从前置角度做事情。所以我们理清了这些事情之后，就明确了DevSecOps要做哪些事情。最基础的就是要做工具链的建设，还有就是基于CI/CD的安全嵌入，这里比较关键的几个点，比如说自动化测试的要求，动态测试也好、静态测试也好、交互测试也好。

包括在腾讯云新的技术战略下有几个关键点要重点关注的，比如说容器安全、API安全、第三方组件安全。我们相关工作也是围绕这几个角度来做的。

工具链方面我们更多是自研，腾讯其实在推科研协同，腾讯内部有很多安全团队的，腾讯内部通过开源协同的方式大家可以共建工具，不需要完全是我们自己团队研发。包括我们也和外部的一些人进行合作，比如说Github，我们也是Github开源安全联盟的成员之一，我们参与的就是安全工具的工作组，基于Github的一个静态审计的工具做研发工作，这个都可以成为我们整个工具链建设里面其中一环。

像我们过去做了很多这样的工作，我们回头来看大部分其实相对比较完善的，比如说一些安全培训也好或者相关的编码规范也好，我们都是已经具备了。在编码阶段比如说一些静态的测试等等，我们相关系统在第二个阶段包括基于腾讯整体的安全能级是已经比较完善的。

第一块的工具链的建设，其实你会发现和第二阶段也有很多关系，因为我们第二阶段有很多工具可以在第一阶段直接得到应用，不需要重新建设，包括背靠腾讯这棵大树，我们是有很多工具可以直接拿来用的，只是可能我们需要做的事情是跟DevOps相关的流程包括CI/CD相关的流程，让工具兼容相关流程，让自动化更友好，这是我们需要重点做的事情。

第二步做的事情就是基于CI/CD流程的安全嵌入，这是2018年提出的黄金管道的概念，通过一套稳定的可落地的安全方式，自动化的进行CI/CD的软化流水的体系，也是国外相关专家提出来的。我们通过这个流程拆解我们可以做的事情，可以发现大概四个阶段。第一个阶段在代码检查阶段，静态代码的扫描也好还是明码信息检查也好，第二阶段构建阶段就是开源组件检查，包括当你构建完之后相关的APP客户端检查，就是部署环境里面涉及的就是安全扫描以及主机内的漏洞扫描。其次在测试阶段主要是两块，一块是上线前的扫描，还有就是黑盒漏洞扫描。

当你完成整个阶段的时候，其实是可以触发一些额外的扫描动作的，比如说端口开放的扫描，其实发布环境的这种服务的部署开放，基本等同于你这次上线的相关环境，所以这个阶段可以做一些端口开放的扫描避免这种高位服务的开放，包括系统漏洞的扫描还可以做到包括管理后台的开放扫描。为什么这里强调管理后台开放，这也是有运营数据支撑的。我们过去做入侵收敛的时候发现当我们把端口开放这个问题大部分解决之后，另外的问题导致的入侵就增加多了，就是相关管理后台的开放，这里管理后台涉及到几块，一个是自研的相关管理后台，还有很多业务团队在使用大数据平台也好，一些自动化工具也好，可能都会涉及到相关控制台，这些其实可以直接做一些相关的危险动作，所以我们必须在这方面进行相关的自动化检测和管控。

这是我们内部代码检查的平台，通过代码扫描的方式在相关的平台里面切入安全检测的能力，作为一个默认的检测规则做这样的检测。

第三方依赖方面，腾讯整体角度是搞了一个腾讯的软件源，通过源头处理安全问题，这个动作里面切入安全动作，避免一些比如你在主服务器也好或者开发过程中，当你使用的版本是存在漏洞的版本，是直接不能使用的。

另外内部其他团队也构建了一些检查工具，就是比较常规的第三方依赖的分析与检查。我们还构建比如说主机内的扫描，通过服务器层面检查相关问题。

刚才讲到的像API的安全等等，其实都是新的架构下需要特别关注的点。像这种API等等其实相对比较少的，就是针对新的点是比较少的，所以我们也是针对性的构建一些能力。比如API这一块，我们通过API层面构建自动检查工具，发现不规范的安全问题，包括漏洞利用的情况。容器这块是另一种做法，统一做法我们目前做法就是镜像仓库，通过镜像仓库本身发现问题。

我们也会尝试更多前置的工作，比如前几天看到百度发的文章，讲的是通过安全开发库和代码的检查流程的配合，去检查危险函数，一旦检测到开发代码中使用的函数不是安全推荐的安全函数的话就可以进行相关的告警，这也是我们正在尝试的方向。包括在滴滴里面他有一个尝试，我们其实也在尝试这个事情，就是把相关需求的分析检查，包括设计的安全检查这样的动作尽量自动化，我们通过把安全规范进行规则化，通过业务同学自填，比如说业务同学填你的密码算法使用的是哪个版本的，我们安全规范里面使用另外一个版本，就可以形成自动化检测，一旦发现他自检过程中不符合安全规范要求的就会进行告警。