腾讯安全平台部研发安全团队 harite
多年来，软件开发以及其引发的信息安全领域总是相生相伴地持续发展。安全领域一直在适应软件研发的流程和模式，为研发出更加安全的系统保驾护航。最近几年，国内越来越多的人开始提及以及实践DevOps的研发模式。腾讯内部以腾讯CI、k8s等为代表的DevOps平台不断发展和完善，也有越来越多的业务开始尝试使用这种研发模式。伴随着DevOps在公司内的快速发展，研发安全保障的思维和技术也需要不断演化发展，其中一个重要的思想就是DevSecOps，它完全遵循DevOps的思想，将安全无缝集成到其中，使之升级成为DevSecOps。亚马逊首席技术官、副总裁Werner Vogels也在腾讯公司主办的第五届互联网安全领袖峰会（CyberSecurity Summit2019，简称CSS2019）上重点讲了DevSecOps的议题，指出“不仅仅是安全团队，所有人都应该加入到其中，我们要有将安全纳入战略思考的思维”。
本文向你介绍业界有关DevSecOps的思考以及我们的实践（第三章因涉及内部信息内容有所删减，如需查阅完整版本请投简历）。若已了解DevOps可直接阅读“二、DevSecOps理念”，若只关心腾讯内部实践可直接阅读“三、DevSecOps试水”。
{全文内容较长2万字 ，阅读时长20分钟}
修订
“安全需要每个工程师的参与”-DevSecOps理念及思考 引子 修订 一、DevOps拾遗 1.1、什么是DevOps 1.2、瀑布模式vs 敏捷模式 vs DevOps 1.3、DevOps工具链 二、DevSecOps理念 2.1、传统安全SDL 2.2、DevOps对SDL的挑战 2.3、安全领域更深的思考 2.4、DevSecOps诞生 2.5、DevSecOps原则 安全左移（ShiftSecurity Left） 默认安全（Secureby Default） 运行时安全（RuntimeSecurity） 安全服务自动化/自助化（Securityas Code/Pipeline） 利用基础设施即代码（IaC） 利用持续集成和交付 需要组织和文化建设 2.6、DevSecOps实践 Plan（需求和设计） Create（编码/编译） Verify（测试/验证） Preprod（预发布） Release（发布） Prevent（预防） Detect（检测） Respond（响应） Predict（预测） Adapt（适应） 三、DevSecOps试水 3.1、DevSecOps工具链 Plan（需求和设计） Create（编码/编译） Verify（测试/验证） Preprod（预发布） Release（发布） Prevent（预防） Detect（检测） Respond（响应） Predict（预测） Adapt（适应） 四、未来的思考 附录：更多参考资料
1.1、什么是DevOps
早在2008年，在软件研发领域敏捷开发的国际会议上，已经有人开始反思研发流程中Development和Operations等角色之间的合作和效能问题。2009年，在O'Reilly集团举办的“VelocityConference”会议上，两名Flickr员工（技术运营高级副总裁John Allspaw和工程总监Paul Hammond）做了题为“10 Deploys per Day: Dev and Ops Cooperationat Flickr”的演讲，从考古的角度来说这次演讲非常有价值和纪念意义，可以看做开创了我们现在所说的“DevOps”概念。其后，这个概念不断地被美国硅谷等地的一些大小互联网公司所采用和发展，创造出了一种新的软件研发思维模式和行动指南。
维基百科上，DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
现在，即使对DevOps有过了解甚至是已经在使用这种研发模式的人来说，也非常难以定义到底什么是DevOps。有些观点认为，DevOps是区别于传统的瀑布模式，基于敏捷模式，并将敏捷思想和实践从开发扩展到运维（也有激进的观点认为它完全不同于这两种研发模式），是一种新的思维模式和行动方法。它的目的是为了提升整个研发效能，进行更便捷、更快速、更可靠的交付，从而提高产品竞争优势。DevOps模糊了以往研发模式中开发、测试、运维等岗位和角色的界限，加强了他们之间的协作，通过流水线和一系列的自动化机制、成熟可伸缩的基础设施（如云）等，使开发人员获得更高的效能，可以更加频繁且快速的将代码变为产品，并从这种快速中获得持续不断的反馈和验证，也获得更高的可靠性。如下图示经常会被用于对DevOps的示意。
图：DevOps理念示意
1.2、瀑布模式VS敏捷模式VSDevOps
让我们对比下瀑布模式、敏捷模式、DevOps三种方式，可能更利于理解他们在表面上的变化。
图：从代码角度的对比
图：从流程角度的对比
实际上，上述对比只能说明表面上的变化。为了能够达到DevOps的目标：更便捷更频繁地进行更可靠的交付，除了思维模式以外，DevOps需要一些技术和工具来支撑，也是得益于一些基础设施和工具等的发展和成熟，越来越多的公司才得以来践行DevOps。
1.3、DevOps工具链
从目前业界的最佳实践来看，这其中主要包括几个关键的东西：持续集成（Continuous Integration，俗称“CI”）、持续交付（Continuous Delivery，俗称“CD”）、微服务（Microservices）、自动化测试、基础设施即代码（Infrastructureas Code，俗称“IaC”，又隐含包括了虚拟化、容器、自动编排、配置即代码等技术和理念）、监控和日志记录（Monitoring and Logging）等。业界围绕DevOps已经形成了一系列的工具集合和解决方案，如下图：
DevOps能够带来的价值也是很明显的，包括更快的研发交付速度，加快了产品创新和尝试。有效管理更大规模下的系统，提供更可靠的质量。从文化角度，深化了研发各角色之前的协作。不仅仅是互联网行业，包括最传统的金融证券等行业其实也在做很多的尝试。
作为最早一批开展多种多样互联网业务的腾讯公司，据笔者了解到的情况，至少早在07~08年左右，Qzone等业务的研发团队就已经开始做类似的尝试，在服务用户数量、系统规模和复杂度等远超当时Flickr的情况下，某些子系统能够做到保证质量的情况下每周2个及以上的版本发布，虽说跟后来Flickr的每天10次 发布还有非常大的差距（表面上看只是频次的差距，其实背后是思维逻辑、基础设施、研发成熟度等的差距），但已经诞生了腾讯内部比较早期的朴素的DevOps思维和实践。个人认为，腾讯当年的互联网业务研发方法论“海量之道”中有很多思想结晶事实上也成为了现在DevOps理念中的关键组成部分，类似于小步快跑、自动部署、大系统小做、动态运营等等。最近几年，腾讯内部对于自研业务也有不少优秀的DevOps工具链和解决方案诞生并且在公司内部逐渐广为使用。
特别说明一下，并不是说你使用了一些CI或CD平台，就是做到了DevOps。实际上想要真正成功实施DevOps并从中获得优势，可能是需要改变整个产品设计、研发流程、系统架构以及思考方式，需要建设成熟的研发基础设施等工作的，这一点极其重要！举个最简单的例子，如果你的系统还不能做到自动化测试，直接上DevOps可能会死的很惨 :-) 因此，DevOps本身的实践也是一个过程，需要结合自身研发的痛点来有针对性的逐步发展。不过通常来说，CI和CD可能是迈向DevOps的第一步。
2.1、传统安全SDL
传统的基于瀑布和敏捷开发的研发模式下，有很多软件安全开发的管理理论方法，比如BSIMM（Building Security In Maturity Model）、SAMM（SoftwareAssurance Maturity Model）等。其中，一个行之有效并且大量地被IT/互联网行业所使用的最佳安全实践被微软发明并向业界推荐，名称为安全开发生命周期（Security Development Lifecycle，俗称“SDL”），这套方法论和其中的最佳实践已经成为一些行业事实上的标准，国内外各大IT和互联网公司包括腾讯也都在基于这套理论和实践，结合自己的研发实际情况来进行研发安全管控。如下图可以看到整个过程，需要注意的是，SDL本身并未关注运维，为了弥补这个缺陷，微软也推出了OSA（Operational Security Assurance）。
图：SDL过程实践，这是官方发布的中文版本，其中的“要求”对应“需求”，“实施”对应“编码”
SDL在研发、测试之外定义了安全的角色，通过流程上的保证，使安全人员及其工作能够嵌入到研发过程中的各个环节，以此来降低产品中出现安全漏洞的风险。
2.2、DevOps对SDL的挑战
图：SDL中Sec的角色和工作机制无法很好的适应DevOps
DevOps出现之后，问题也来了。传统意义上的DevOps只关注开发、测试、运维及其之间的协作，安全（Security）是被排除在外的。随着业务的复杂度以及商业价值的增加，安全问题也已然成为企业发展战略的关键组成部分。DevOps中频繁的交付以及其他行为方式的改变事实上已经成为了双刃剑，对旧有的SDL这类研发安全管控思想、流程和工具形成了很大的挑战，也让研发安全问题越发不可控。DevOps对传统安全SDL的挑战目前看主要体现如下等几个方面：
【弱化的设计过程使安全评估难以展开】
敏捷时代所倡导的“代码即设计”导致了开发人员在设计上花费的时间大大降低。许多DevOps团队更是进一步升级了这个思想，比如硅谷创业家Eric Rise在其著作《精益创业》一书中提出了“精益创业”（Lean Startup）的理念【附录5】，其核心思想是，开发产品时先做出一个简单的原型——最小化可行产品（Minimum Viable Product，俗称“MVP”），然后通过A/B test等方式收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。如果是失败的尝试，则尽快让它停止。这些会导致两个关键的问题，一个是安全人员要不要/有没有必要参与到其中，另一个是安全人员根本无法参与到设计阶段，无法去进行传统的针对设计方案的威胁建模和风险分析消除等工作。
【高速的交付让安全过程无从下手】
敏捷模式的研发过程可以将发布降低为1~2周，如果认为这个频次还能够承受的话。DevOps下更加极端，有个公开的数据可以参考，亚马逊在整个2014年部署变更了5000万次以上，平均每秒部署2次变更。这个强度之下，传统的SDL实际上已经无法落地。
【云、微服务、容器等技术需要新的安全能力】
云技术的快速发展，特别是基础架构即服务（IaaS）和平台即服务（PaaS）等的技术，深刻地改变了我们进行系统架构和设计的思维模式。云的环境中包含了众多的开发、运维、管控及安全等的功能和产品，如账户管理、数据存储、加密和密钥管理、审计、故障处理、监控等等的服务和API。举个例子，现在很多云都有serverless的服务，使用它如何来评估安全风险和安全责任呢？使用云，就意味着必须接受共享责任模型（SRM，美国国家安全局的一份报告中提出这个概念），一些云服务厂商称之为“责任共担模式”，需要了解云技术供应商和自己的责任范围以及如何确保云供应商执行了所要求的安全能力。此外，云服务用户会面临一些新的安全风险问题，可以参考TreacherousTwelve。 微服务是许多成功实施了DevOps案例中的一部分，亚马逊和NetFlix围绕微服务构建系统和组织方面取得了巨大成功。但是微服务也有一些缺点，如操作复杂（单个微服务很容易理解，但是他们之间的互相关系和治理可能会超出人的理解能力）、攻击面分析困难（单个的攻击面可能很小，但是整个系统的攻击面可能很大，并且基于操作复杂的问题不容易看清楚）、边界不清晰（相比传统的三层结构的Web网站，数据流分析难以应用在微服务的架构中，因为不容易确定信任边界）、审计困难（除非使用统一的日志记录和审计机制，否则想要审计系统中众多的微服务是一件非常困难和高成本的事情）等。
容器特别是docker的发展和使用，也是DevOps的一个重要实践，它改变了传统的部署方式，与微服务等更容易结合。但是容器类技术也会带来另外的问题，比如资产识别问题（可能会遗漏，需要从基于OS或虚拟机的力度增加到容器力度，但是容器的使用又很灵活，快速的大量创建和销毁会使之成为很大挑战）、安全系统的兼容（比如一些主机入侵检测系统HIDS可能需要能够支持容器）、引入新的安全风险（如 内核溢出、容器逃逸、资源拒绝服务、有漏洞的镜像、泄露密钥等，都需要新的方法来应对，详情参考Docker的作者Adrian Mouat列出了使用Docker时需要注意的五个安全问题）。
【安全的职责分离原则被挑战】
传统思维中，职责分离（SoD，Segregation of Duties）是一个基本的要求。特别是审核和合规领域极其关注这一要求。试想一下，一条流水线可以从代码直接通到服务器上去运行。如何平衡这种便利性和安全性？此外，这一点也可以扩展到变更的安全管理上。每天有那么多变更，怎么来对这些变更进行有效管理？万一有次恶意变更呢（最近一次国内的删库跑路事件）？传统的审批模式因为阻碍自动化已经过时。有关变更的安全管理，有个案例可以很好的说明这一情况，骑士资本集团（KnightCapital Group）的一次失败变更使其在 45 分钟内就亏损了 4.6 亿美元。最终破产而被收购。
诸如此类的挑战，以及SDL本身固有的一些问题（如各个角色信息不对称、孤岛效应、意识不足、配合沟通困难、延误放大等）使得在DevOps潮流之下SDL逐渐变的困难重重。甚至有些悲观的看法认为SDL无法适应DevOps的出现，事实上已经死亡。微软可能也感受到这一压力，提出了“SecureDevOps”的概念和实践。
2.3、安全领域更深的思考
传统的SDL类的方式管控多年，但还是会有持续不断的大小公司被入侵和数据泄露等安全事件发生。另外如上所说，面对发展势头猛烈的DevOps这种研发思想和实践，传统的SDL已经渐感力不从心。无数的事实告诉我们一个道理，安全人员的角色不能仅仅是兜底，况且实际情况是根本无法兜底，所以需要引入一个重要的思维变化，也被如亚马逊首席技术官Werner Vogels等人反复在讲，安全需要每个工程师的参与。安全不再是单独安全团队的责任，是整个组织所有人的一致目标和责任，才能更好的对研发过程中的安全问题进行管控。这并不是一个推脱责任的说辞，实际上对安全团队的思维方式、组织形式和安全能力建设等提出了更高的要求。想要每个工程师在安全意识和安全能力上都达到专业安全人员的标准是不可能的，因此如何能够将安全要求和安全能力融合到DevOps过程中来，如何让安全赋能从而让整个组织既能够享受DevOps带来的好处又能够较好的管控安全风险变成是一个重要问题。这些思考也导致了DevSecOps思想的诞生以及一系列的解决方案的尝试。
2.4、DevSecOps诞生
也是因为发现了上述的问题并且做了深入的分析研究之后，2012年，Gartner通过一份研究报告“DevOpsSec:Creating the Agile Triangle.”提出了DevSecOps的概念（备注：有一些同样意思的名词如SecDevOps、DevOpsSec甚至是RuggedDevOps，本文中统称DevSecOps）。在这份研究报告中，确定了信息安全专业人员需要积极参与DevOps计划并忠实于DevOps的精神，拥抱其团队合作、协调、敏捷和共同责任的理念。也即是，完全遵循DevOps的思想，将安全无缝集成到其中，使之升级成为DevSecOps。2016年，同样是Gartner这个研究机构，公开了一份名为“DevSecOpsHow to Seamlessly Integrate Security Into DevOps”的研究报告，更加详细的阐述了DevSecOps理念和一些实践。Jim Bird也在书籍《DevSecOps：Securing Software through Continuous Delivery》归纳总结了不错的思考和实践。想要深入了解DevSecOps，这几个原汁原味的资料个人非常推荐。做为Gartner近年来主推的一个研发安全的概念，它持续地通过研究报告推动着该领域的发展。一个对DevSecOps最简单直观的图示如下图：
这一安全研发体系的概念和实践特别是最近几年越发被业界所重视，谷歌趋势可以看到关注度的增加。
所以，问题的关键就变成了如何遵循DevOps的思想，将安全无缝地集成其中？以下从原则以及实践两个方面展开详细论述。
2.5、DevSecOps原则
【安全左移（Shift Security Left）】
这是一个DevSecOps时代非常关键的思路转变，其实也很容易理解。持续的发布不停地进行，靠以往把所有的检查在发布之前进行根本跟不上这个速度。所以需要更多的关注研发流程的“左”边，在更早的环节中（设计、编码、自动测试）也要进行安全介入和管控。但安全工作必须从工程师的角度出发，制定更加轻量级可迭代的措施，并以有效、可重复和易于使用的方式实现自动化。这个想法虽好，但并不是那么容易落地，主要的原因是安全人员数量并不足够，所以需要让开发和运维人员承担更多的安全责任，这里需要安全人员对他们进行更多的安全培训（意识和能力），还有就是提供有效的工具来帮助构建更安全的系统。
这一思想诞生了众多的尝试。对需求和架构设计中的快速安全评估机制以及简易威胁建模方法论和工具集等，例如PayPal曾在2016年的RSA大会上分享他们每个团队都必须进行初步的风险评估，并在每一个新应用或微服务开始工作时填写一份自动化的风险调查问卷。又如沉寂多年的源代码安全扫描手段和工具重新被重视（如GitHub推出的CodeQL等产品），在IDE中做更好的集成提供更好的体验等。为了更快地开发代码，敏捷或DevOps团队大量使用开源组件、库或框架等代码，据全球最大的开源组件中央仓库服务提供商Sonatype的研究报告指出，应用的源码中大约80%的代码是开源的组件、库或框架代码，由此也引发了开源组件安全以及供应链攻击等视角，也诞生了一些安全工具和解决方案。还有一些人重新思考如何更高效并且将安全融入到单元测试、集成测试等测试环节。总之，围绕这一原则，已经并将继续产生一些探索和安全的解决方案。
【默认安全（Secure by Default）】
这一思维至关重要。拿编码环节来说，持续的快速构建也意味着需要快速的产生代码，而如何快速的产生安全的代码变的越发重要。在开发人员能力短期无法质变（或不停的有人力交接或新人加入等）时，通过提供默认安全的开发框架或者默认安全的组件可能很好的防止犯低级错误，比如搞Web开发的同学肯定知道，一些新的开发框架中都内置了一些安全机制或者安全操作库，比如得益于框架内置的anti-csrftoken安全机制，你在一个基于CodeIgniter框架并且打开了该项配置的应用中可能很难找到CSRF漏洞。再比如当你使用Go或Rust语言构建系统时，基本上也杜绝掉了C/C 中常见的缓冲区漏洞及攻击，这是语言特性中默认安全原则的体现。当然，默认安全的原则并不仅仅限于代码，Web接入层上默认覆盖的WAF、默认安全配置的云/容器/数据库/缓存等基础系统和服务、统一的登录鉴权认证服务、KMS（密钥管理系统）、保护关键数据的票据系统、零信任（Zero Trust）架构等等，都是默认安全的很好实践。这也要求安全团队要参与到整个系统架构、基础设施等的建设中。反过来也会要求更多的组织架构保障以及安全与研发团队之间的沟通协作能力。
实际的实践中，跟“零信任”等安全思维很相似，表面上看起来好像很简单，其实根本没理解背后所需要做的工作的复杂性。真正想要尽可能的分析系统并且使之各个环节做到默认安全是一件长期和不那么容易的事情。虽然回报巨大，但它要求从根本上改变安全部门与研发部门协同工作的方式。需要两者更紧密的合作起来，一方面增强应用安全和软件设计相关的知识，提升安全编码能力；另一方面要以易用和安全的方式将安全防护措施融入到开发框架、模板、系统架构中，并且还要有持续有效的检查和监控机制。此外，它也需要研发人员及其管理人员做出承诺，要把上述这些默认安全的框架和系统用起来。如果安全不是所有人的一致目标，便很难实施默认安全。
【运行时安全（Runtime Security）】
这个并不是什么新话题。但是在越来越快的发布之下，倒逼着安全的考量除了上述提到的左移和默认安全以外，更加需要特别关注和加强上线后运行时的异常监控和攻击阻断能力提升。需要有更加及时快速自动化的风险监控、发现、阻断、恢复等的手段和机制。类似于致力于提升系统整体可用性的各种Monkey（混沌工程），安全机制也需要有类似的机制和能力，重点在识别内外部的安全风险上。再比如与应用运行时环境嵌入更紧密的运行时应用自我保护（RASP，Runtime Application Self-Protection）技术，以前如果还犹犹豫豫，那以后可能会更多纳入大家的视野中。虽然也有一些问题如部署比较麻烦、兼容性问题、性能问题等，但是借助于云、容器等成熟的大规模基础设施和技术之上通过优化完全有可能提供更优雅更易于接受和使用的方案，能够带来更快更精准更细致入微的安全检查及防护能力。此外，对于很多安全风险来说，情报来源管理和自动化分级分析是第一步，然后如何更快的检测？又如何快速地对问题进行响应，特别是为了提升安全响应效能，不能仅仅从单点来考虑，要从全网及整个系统架构层面来考虑，将分散的检测和响应机制整合起来，这也导致了Gartner在2015年提出了安全编排自动化和响应（SOAR，SecurityOrchestration, Automation and Response）的概念，更好的完成运行时的风险响应问题。
【安全服务自动化/自助化（Security as Code/Pipeline）】
在DevSecOps中，安全并不是特殊或者拥有某种高权限的存在，跟其他所有研发环节和工具一样，不能因为安全而中断DevOps的流程。如果你的安全服务没有实现自动化，那么就无法称之为DevSecOps。整个研发流程都在围绕流水线运转，你不可能突然在其中把开发人员支走，很莫名其妙并且无法被接受。应该向他们提供可使用且易于理解的安全工具，让这些工具自己进行配置和运行，保证这些工具能以合适的方式融入到流水线中，融入到各个流程中，成为DevSecOps工具链中的一环，使用角度跟其他工具没有大的区别。总而言之，需确保安全测试和检查服务能够自动化和自助化并且提供快速且清晰的反馈。业界有一些研究和尝试比如漏洞代码自动修复（MIT的CodePhage，GitHub发布的针对开源漏洞组件自动修复的Dependabot）等技术，虽然目前看有些成熟度可能还不高，这些方向虽然困难但绝对是正确的，是一种贯彻DevSecOps思想的尝试。但是这里也要小心陷入另一个误区，需要清晰的认识到，安全领域是没有“银弹”的。如同所有风险类管控一样，信息安全的管控本身一定是层层防御的机制，对于很多营销目的的所谓新技术一定要全面了解多方对比才能做出判断，不太可能指望搞一个方案就一劳永逸的解决所有安全问题，就要达到100%安全，这是不切实际的空想！就如同软件研发领域“没有银弹”，系统可用性没有100%（一般我们说要做到4个或5个9），安全也没有100%。
【利用基础设施即代码（IaC）】
基础设施即代码（Infrastructure as Code）思想和工具是以前成功构建实施DevOps的关键，安全管控也要积极的利用这些能力。利用他们确保大规模场景下配置、环境和系统行为等的一致性，通过版本控制、代码审计、重构、动静态分析、自动测试等手段持续交付流水线来验证和部署IaC设施，确保标准化、可审核并且使之更安全，减少攻击者发现和利用运维漏洞的机会。各种安全系统和安全机制也积极使用这些设施，另外在出现安全漏洞或应急事件时，直接使用IaC的一些机制快速安全可靠的修复漏洞或部署缓解措施。
另一方面，也特别要保护这些基础设施，保护持续集成和持续交付管道等研发流程中的关键系统，真的无法想象流水线系统被恶意控制之后会导致什么。最近几天爆出的有关SaltStack自动化运维工具的漏洞造成了不小的影响。所有的操作集中起来对于安全保护的要求会更高，因为对攻击者而言至少目标是更加明确了。
【利用持续集成和交付】
对于安全来讲，从某些角度来说，快速的持续交付也会带来某些“好处”，要充分利用这些好处。举个例子，大家都知道源代码安全扫描机制有个很大的局限性问题，就是误报率高，这是机制使然。已知的最好的工具可能误报都要在50%以上，并且这个值很不稳定，对于特定的代码误报率会更高。以前写1周的代码，提交增量代码触发扫描可能要发现100个疑似漏洞需要花费额外时间来排查，最终有效的是50个（假设）。现在如果每天要发布好几次，快速的发布也意味着每次所需扫描的增量代码量大大降低，即使还按照50%的误报率，可能一共就只有10个疑似需要确认，事情就变成了可以接受的情况。这样这些以前搁置的安全工具就有可能有效的使用起来。从本质上说，更快速的变更意味着每次变更的范围更小且独立性更强，轻量级的变更更容易被理解和检查，所需的测试也会更快，错误也会更容易发现，发现问题时修改起来也更简单。当然，如果你的代码更加标准化（如代码风格、代码规范、框架及架构等），这一点会越有利。有一些研究结论也表明，研发安全领域，轻量而频繁的变更可能让系统变得更安全。从腾讯以往的漏洞数据来看，一些老旧的站点确实存在着大量的漏洞不断的被发现。如此看来，对于安全来说，变更很快，或许也并不总是坏事 :-)
【需要组织和文化建设】
DevOps以及DevSecOps并不像某些ERP软件系统那样，买一套部署，然后用起来就解决了。对于一些想要践行的公司来说，DevSecOps工具链需要去提取痛点（需求）、购买/研发系统并部署、推广使用以及建立度量这样一个正向循环才能持续发展，并由一个个业务、部门逐步试用推广变成整个公司的研发方法论，在这个过程中也需要辅以研发文化的建设。这个过程还需要结合各个公司的一些实际情况来具体问题具体分析，以一步步解决问题提升研发效能的方式来制定适合自己的DevSecOps实践方案。比如谷歌会有专门的组织架构及员工角色SRE（Site Reliability Engineering）联合他们的专业安全团队来共同践行DevSecOps，而腾讯因为历史上业务和技术发展情况的不同，组织架构上可能需要通过内部的开源协同方式来聚集一些团队共建DevOps及DevSecOps。
除了以上原则外，最后还有一点需要留意。就是要特别关注安全建设的衡量和实际效果的评估和改进，安全不是一蹴而就，要结合内外力量避免虚假的安全感。一些措施如经常性的红蓝军（Red Teaming）对抗渗透测试（Pen Testing）、针对外部安全研究人员的漏洞奖励计划（Bug Bounties）、完善的安全事件复盘等都是一些已知的不错实践。
2.6、DevSecOps实践
Gartner作为最早提出并持续关注DevSecOps思想理念和实践的研究机构，虽然它的一些报告中有时也带有浓郁的商业利益气息，但是其所给出的一些研究结论和技术概念也确实客观上推动了很多安全领域的发展，有很大的参考价值。目前DevSecOps的实践还是在快速摸索和发展阶段，Gartner在2019年的一篇文章中，给出了一个它经过调研和分析之后认为的一个比较全面的实践清单（在DevOps的工具链基础上，增加Sec工具链实践）如下图，由一系列关键路径和持续的关键步骤中的措施和机制组成，周而复始的运转。它的关注点主要是研发过程中的安全漏洞以及其引发的各类风险的管控。以下笔者也试着做些个人的解读以方便大家理解，抛砖引玉。
【Plan（需求和设计）】
• 偿还安全债务
类似于系统研发过程中因为各种各样的原因会出现很多技术债务，其实也会出现安全债务，需要认识到风险并且制定计划逐步偿还。举个真实的例子，某业务的登录设计采用Email账号 密码方式，这种单因子的方案肯定是不安全的，研发团队也注意到了该风险，上线了额外的扫码确认机制以完成安全的双因子登录认证。但是由于对推动客户开启的困难性以及该风险的重要性的低估等原因，并未有什么手段或计划去提醒或者强制客户开启该安全的登录方式，一直到最后爆发了大规模性的“撞库”进而产生了很多的恶意登录和利用发送垃圾消息，引起了广泛的关注造成不小的影响才慌忙应对，紧急修改产品流程强制客户开启。研发团队中肯定要有相应的角色能够承担产品流程和架构上的安全评估和设计并且持续评估和跟进推动问题的解决。
此外，老生常谈的话题肯定也少不了，包括安全意识、能力（编码规范、测试规范、等）等的制订、培训和考核。要注意，仅仅是漫无目的的教和学通常来说并不是十分有效，建立某种教考结合的方式是有必要的。研发人员至少要了解到各种各样可能的安全风险，而不能完全没有听说。
• 度量与指标
管理学中有一个说法：“你如果无法度量它，就无法管理它”(“It you can't measure it, you can't manage it”)。DevOps推进需要良好的度量方式，研发安全管控也是一样的道理。有些比较容易想到的指标可能并不是最优的，比如单纯根据漏洞数量来评判研发人员的安全能力乍一听有道理但是细想肯定有问题。有些人不写代码，有人写的多有人写的少，有人接手和维护了大量的已有系统老代码，单纯看漏洞数量势必会让辛勤解决安全问题的人吃亏，变成了“不做就不会错”，这显然不是一个好的导向。这些基础问题由于并不是那么炫酷，关注和探讨的人反而不多，个人觉得这是一个重要问题。一般来说，这里包括了安全系统的覆盖率，使用率，漏洞发现率，每千行代码的漏洞数量，漏洞修复速度等等方面，可用于评估研发团队的安全成熟度。
• 轻量有效的威胁建模
除了传统意义上的威胁建模方法论和工具以外，快速的安全自查checklist、安全知识库等都是一些有益的探索。目的都是要把需求和设计的安全评估推上持续构建的快车道。让这个过程不至于变的名存实亡。
• 安全流程和安全工具的使用培训
【Create（编码/编译）】
• IDE安全插件
各类的安全漏洞扫描、开源组件版本检查甚至是代码质量代码风格等的工具可以让研发人员在编码时就发现和消除一些潜在的安全风险。在DevSecOps时代，这个需要大力的投入，如果做的好，可以大大减轻后续环节的工作量。不过这里也面临一些挑战，比如针对源码静态分析的误报率问题，再比如某些安全漏洞准确的检测方案极度依赖编译或构建过程等等。有一些资源可以去参考，比如VSCode的插件商店等。
【Verify（测试/验证）】
自动化测试是必不可少的。安全领域会衍生出以下专用安全工具需要融入到流水线中。
• SAST
静态应用程序安全测试（StaticApplication Security Testing），是指针对源代码进行静态分析从中找到安全漏洞的测试方式，有些工具也会依赖于编译过程甚至是二进制文件，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确度。也被称为白盒测试（White-Box Testing）。常见的工具包括老牌的Coverity、Checkmarx、FindBugs等，比较新的CodeQL和ShiftLeft inspect。一般来说，优点是能够发现代码中更多更全的漏洞类型、漏洞点可以具体到代码行便于修复、无需区分代码最终是变成Web应用还是App、不会对现网系统环境造成任何的影响。但缺点也不少，比如研发难度高、多语言需要不同的检测方法、误报率很高、不能确定漏洞是否真的可利用、不能发现跨代码多个系统集成的安全问题等。传统的SAST因为始终不能很好的解决误报率问题，并且因为研发模式的问题，导致研发人员很难在编码结束之后又要花费非常长的时间来做确认漏洞的工作（其中可能大部分的都是误报），所以在一些行业并未大规模的应用，但是DevOps时代，结合CI的过程，上述一些新型的工具开始广泛利用编译过程来更精确的检测漏洞降低误报率，并且极小的CI间隔也让误报率问题带来的负担大大降低。
• DAST
动态应用程序安全测试（DynamicApplication Security Testing），是指在测试或运行阶段分析应用程序的动态运行状态。在不需要系统源码的情况下，通过模拟黑客行为构造特定的输入给到应用程序，分析应用程序的行为和反应，从而确定该应用是否存在某些类型的安全漏洞。也被称为黑盒测试（Black-Box Testing）。常见的工具包括针对Web应用商业和开源的AcunetixWVS，长亭科技X-Ray、w3af等，也包括一些针对电脑或终端App等的应用。这些工具的优点是从攻击者视角可以发现大多数的安全问题、准确性非常高、无需源码也无需考虑系统内部的编码语言等。但缺点也很明显，需要向业务系统发送构造的特定输入有可能会影响到系统的稳定性和写坏数据、因参数合法性、认证、多步操作等原因难以触发从而导致有些漏洞发现不了、漏洞位置不确定导致修复麻烦、某些可能非常耗费资源（如基于安卓虚拟机等）或者耗费时间（又不能影响环境运行又要发送大量请求并且等待响应）等。从腾讯的实际情况来看，DAST技术依然是最可靠的漏洞检测技术，发现了大量的真实安全漏洞。传统的依赖人手动来提交的方式依然无法适应DevOps，所以结合了下文IAST手段的全自动化的方式越来越多的被发掘和使用。
• IAST
交互式应用程序安全测试（InteractiveApplication Security Testing），由Gartner公司在2012年提出的一种新的应用程序安全测试方案。它的出发点是比较容易理解的，上文提到的SAST通过分析源码、字节代码或二进制文件从“内部”测试应用程序来检测安全漏洞，而DAST从“外部”测试应用程序来检测安全漏洞，它们各有优劣。有没有可能有一种方式结合“内外部”来更好的自动化进行检测来更准确的发现更多的安全漏洞？IAST就是Gartner给出的方向，寻求将外部动态和内部静态分析技术结合起来，以达到上述目标。有一些很有效的具体的方式被发掘和使用，比如在针对Web业务的DAST方案中，相比于传统的人工录入参数和发起扫描这一无法结合到流水线中的方式，通过一个应用代理在做自动化测试的时候自动收集CGI流量并且自动提交扫描从而可以很好的融入到流水线中。再比如更进一步，通过在Web容器中插入对关键行为的监控代码（比如hook数据库执行的底层函数），跟外部DAST扫描发包进行联动，可以发现一些纯DAST无法发现的SQL注入漏洞等。可以获得SAST和DAST的优势，但是挑战在于对系统的环境或代码的侵入性比较高，实施成本大。更多有关上述三种安全测试方式的对比可以参考这里。业界有在RSA创新沙盒比赛中获奖的ShiftLeft protect，也有开源的工具如百度的openrasp-iast等，此外一些国内外的安全厂商陆续也都有推出IAST产品。
• SCA
软件成分分析（SoftwareComposition Analysis）。如前文所指出，越发快速的开发意味着开发者要大量的复用成熟的组件、库等代码。便捷的同时也引入了风险，如果引用一些存在已知漏洞的代码版本该怎么办？如何检查他们？这衍生出了SCA的概念和工具。有一些针对第三方开源代码组件/库低版本漏洞检测的工具也被集成到IDE安全插件中，编码的时候只要一引入就会有立即的安全提醒，甚至帮你修正引入库的版本来修复漏洞。有一点需要留意，有些编码语言或方式的检测方法会很简单（如nodejs等带有包管理类功能），但有些可能并不容易（如c/c 等）。
【Preprod（预发布）】
部分的措施在某些情况下会融合到上一个阶段“Verify”中。
• 混沌工程（ChaosEngineering）
简单来说，这套方法论认为分布式系统中的各种故障和问题都是不可避免的并且随着复杂度不断提升已经不太可能通过上线之前的测试来发现，但是系统架构要确保在这种情况下依然能够提供稳定持续的服务。混沌工程方法论通过在分布式系统中自动注入各种预设的故障来增强系统可用性以及自动的发现脆弱的环节并改进。这是一个很大的话题，我们不做详细展开。这里举个例子，Netflix公司的“Chaos Monkey”项目，就像一只淘气的猴子跑进了你的机房里面乱打乱踢，随机产生了诸如进程被杀死、服务器断网、机架掉电等各种各样的故障和问题，你的系统需要确保在这样的情况依然可以提供持续稳定的服务。这个相当于系统可用性建设中的自动化演习，只不过它把这种演习直接做到了系统架构中，可以随时随地随机的在预发布环境甚至是线上环境中展开，以此逼迫系统面对故障时彻底的自动化恢复以及可以尽早的发现和解决可用性问题，此外混沌工程还关注异常时的度量等信息以供分析人员使用。有关这个详情推荐参考其官方著作《混沌工程：Netflix 系统稳定性之道》。
在安全方面虽然有一些公开项目比如“Security Monkey”，但只是一个传统意义上的监控机制，还有待持续发展。要把一些安全的异常或自动化的攻击测试融入到线上系统架构中以不断的锤炼提升系统处理过程中的安全性，举些例子比如本来是一个正常的对数据库的查询，但是一旦这些请求替换成了“拖库”的行为，应用本身可否安全的处理？甚至我们假设系统中的安全漏洞无可避免，这种情况下有无办法发现或杜绝“拖库”行为？这些其实反过来都对系统的安全架构和设计提出了更高的挑战和要求，还需要在混沌工程的思维和框架之下做更多的一些思考和实践。另外需要注意，虽然Gartner将混沌工程放到了这个预发布环节，但实际上不仅仅是在预发布系统中才会有，最早提出这一方法论的Netflix是会在线上环境持续的进行，这听起来很吓人，但使用真实环境带来的收益肯定也是非常高的。
• Fuzzing
又被叫做模糊测试（Fuzz Testing），这可能是一种最古老的安全测试技术。通过把自动或半自动生成的随机数据给到一个程序并监控它的异常（crash等）来判断是否存在安全漏洞。常常被用于文件格式解析、网络协议解析等程序的安全测试中，经过30多年的发展，这项技术逐步结合了动态分析、静态分析、插桩、覆盖引导、符号执行等技术。在谷歌Project Zero、腾讯BladeTeam等安全研究团队所发现众多影响广泛的漏洞中，Fuzzing都是不可或缺的漏洞检测技术。但是传统的Fuzzing机制并不是为了快速，而是为了尽可能的提高代码覆盖（一个最新的尝试），所以速度往往是个很大的问题，一波Fuzzing下来好几天甚至是个把月都是很经常的事情，这个速度可能无法适配DevOps。因此如何在DevSecOps之下做Fuzzing是当前一个很好的话题，不久前谷歌刚公开的CIFuzz以及RSA创新沙盒比赛中ForAllSecure公司的参赛产品-下一代Fuzzing解决方案“Mayhem”都是不错的尝试。但是这里可能依然有些问题需要解决好，比如使之能够让开发同学更易于使用、更有效的样本构造、扫描深度和时长的平衡、分布式管理等等。
• 集成测试
方法可能类似于SAST、DAST、IAST等，只是测试所针对的目标和范围不同。
【Release（发布）】
• 软件签名
【Prevent（预防）】
注：早期版本中该过程被称为“Configure”，新版改为“Prevent”。这部分的理论和实践还有待发展和细化。
• 签名验证
• 完整性检查
• 纵深防御措施
Defence-in-Depth（简称“DiD”），这是一个来源于传统军事理论的内涵极大的词语，在信息安全领域，它假定单个的安全措施和机制都会失效或被绕过，所以需要采用分层的方式，使用独立的一个个措施来层层的进行防御。是安全建设领域广泛采用的一种思路，有关它的详细内容这里不做展开，可以参考美国国土安全部发布的最佳实践《Improving Industrial Control SystemCybersecurity with Defense-in-Depth Strategies》。
【Detect（检测）】
• RASP
运行时应用自我保护（Runtime ApplicationSelf-Protection），被Gartner在2014年列为应用安全领域的关键趋势。不同于传统的应用外的安全措施（如外层的防火墙），它将安全能力像疫苗一样注入到应用程序中并与之融为一体，能够自动化的实时监控、检测或阻断实际产生的安全攻击，使应用程序具备自我保护能力。在网络和系统边界日益模糊的今天，使最重要的应用本身具备自我安全保护能力这一个方向有极大的吸引力。它的一些底层技术实现可能会跟某些IAST很类似，比如PHP中使用扩展来Hook、Java环境中采用Java Agent机制来Hook等。国内开源且比较知名的方案是百度的OpenRASP。但是要注意的是，该方案带来巨大收益的同时也因为修改了运行时环境的底层，可能会对应用的性能、兼容性、稳定性等造成或多或少的影响，在评估和实现方案时需要重点考虑和应对。
• UEBA/网络监控
用户和实体行为分析（User and Entity Behavior Analytics），依然是Gartner所创造的安全领域的技术词汇。通过对用户以及系统实体在数据层面的异常行为利用机器学习的方法来发现网络安全、IT办公安全、内外部的业务安全等风险，如数据泄露、入侵、内部滥用等的安全问题。在安全领域，异常分析是一个最重要的能力，传统方法更多依赖于经验形成的专家规则，在某些时候这种特别有用，但是另外一些情况下规则又容易被绕过（特征以及阀值设置等）。UEBA最近几年也是伴随着机器学习的热炒比较火，国内也有一些公司出过一些不错的报告，比如《UEBA客户使用指南》等。很多人相信这个技术会深刻改变传统安全领域。实际的UEBA应用场景中，早期有监督学习方式最重要的其实是样本和数据工程，但是可能因为安全是个很敏感的行业，业界极少会有这方面的交流分享，这可能也客观上导致了相关技术的发展成熟度其实并没有那么高（相比于机器学习在其他领域的应用）。近几年有一些无监督学习的尝试，从公开出来的情况看，想要可持续可运营的上线应用，仍需要摸索和发展。
• 渗透测试
安全与否不应该靠主观感受，而应该多多借助于背靠背的演习和不断的渗透测试来证实。
Respond（响应）
• 安全编排（Security Orchestration）
Gartner在2017年提出了安全编排自动化和响应（SOAR，Security Orchestration,Automation and Response）的概念。这一技术定义安全事件分析与自动化响应工作流程。采集各种运营团队关心的安全检测系统数据，对他们进行分析与分类，利用最资深安全分析人员的专家经验，自动化的来定义、排序和驱动按标准工作流程执行的安全事件响应活动。Gartner后来又从理论上发展出了更细致的定义，安全编排与自动化（SOA，Security Orchestration andAutomation）、安全事件响应平台（SIRP，SecurityIncident Response Platform）和威胁情报平台（TIP，ThreatIntelligence Platform）三种技术/工具的融合。这一概念未来还会快速演化和发展，甚至内涵都有可能会变化，但是都将是致力于解决DevOps下如何快速准确的响应和预测安全事件。
安全编排这个概念，简单来说，在一个实际有效的安全响应和安全运营过程中，会有很多日常的分析、响应等的工作，这些工作以前大都靠人以及人的经验来驱动，这样的方式弊端很大，特别是现在的应用、数据以及安全系统越来越多和复杂，因此整个的过程需要采用自动化的剧本来代替人肉驱动。举个简单的例子，有一个敏感信息检测策略需要运营。发现疑似之后，要先确认这个资产是否已经经由业务和安全评估过（比如某些业务就是要在页面中公开展示身份证号），如果没有评估过需要找到这个资产上安全风险的实际处理人，然后需要联系他来确认到底是不是真的存在风险，这个联系根据风险级别不同，有些是邮件有些是IM有些紧急的是电话，如果他一段时间联系不上，事情要升级知会他的上级，另外如果存在风险则需发送安全工单跟进处理闭环，业务处理完毕（如下线）后还要跟踪他是否有正确归类结束工单，工单还需要进行审核以确定该风险是否被解决，最终产生统计运营数据。你会发现整个流程如果完全依赖于人，这里的质量根本无法持续保障。如果这些都定义成自动化的剧本，可控性和可持续性会极大增加。特别是随着最近几年，老牌的信息公司和安全公司如IBM、微软、FireEye、Splunk等对新创SOAR解决方案公司展开很多收购，也让这个安全领域越发受到更多企业的关注。
• RASP/WAF 防护
一些RASP方案除了在上面的检测环节以外，还可以直接做响应比如拦截等，这就可以在此阶段起作用。相对于RASP这个新事物，传统的WAF（Web Application Firewall，Web应用防火墙）早已被大量的部署使用。不同于私有协议的应用，互联网时代Web形态的业务大量存在，而刚好它利用的又是一种公开的通用的HTTP(S)协议，因此WAF应运而生并且一直以来发挥着重要的作用。它假定应用中肯定有漏洞存在，在这种情况下依然可以阻断实际产生的某些攻击尝试和行为如入侵服务器、数据拖库、盗取用户信息等。传统的专家规则、前些年的机器学习以及最新的词法语法分析等技术陆续被用于升级WAF系统，以提升覆盖率并且降低误报率。另外除了应对传统的Web漏洞攻击、CC攻击以外，WAF也逐渐发掘出了反爬虫、打击羊毛党等的场景，将安全能力从漏洞防护扩展到了业务安全领域。
如前文所讲，RASP这种技术方案来做阻断之类的响应时也有一些实际的问题和困难需要去不断解决和完善，而传统的WAF因为无法感知应用逻辑（某个攻击请求真的被应用执行了么？）也会存在误报等的问题，在未来，打造成熟的基于RASP技术结合的WAF可能是一个趋势。
• 混淆
【Predict（预测）】
• 漏洞相关性分析
属于软件漏洞管理的范畴，也被称为Application VulnerabilityCorrelation（AVC）。Gartner在2017年的一份报告中认为这个领域即将迎来重大的关注和发展。它背后的逻辑其实还是挺简单的，漏洞的发现肯定无法依靠单一的一种工具和方式，而是会由如上文的SAST、DAST、IAST、RASP以及人工渗透测试等各种各样的手段以及工具来完成。但也会产生新问题，比如这些方式和工具存在着重复扫描、难以协同等。在这种情况下，就催生出了AVC这个方案。理想中的AVC方案可以管理所有的安全工具，通过标准化数据格式等方式以使他们之间更高效的协作，以此来更高效的发现和管理所有环节的漏洞。这里Gartner以CodeDx做为首选供应商，它的目标是通过自动关联和漏洞管理来缩短安全测试所需时间、降低误报、降低安全测试成本，使团队专注于开发即可。
• 威胁情报 IoC/TI STIX TAXII
按Gartner在2013年的定义，威胁情报（Threat Intelligence）是基于证据的知识，包括场景、机制、标示、含义和可操作的建议。这些知识是关于现存的、或者是即将出现的针对资产的威胁或危险的，可为响应相关威胁或危险提供决策信息。这其中关键的信息就是失陷标示（Indicators of Compromise，IoC）如攻击行动所使用的木马名称、文件指纹、进程信息、恶意域名、C&C服务器IP等。
为了统一威胁情报的表达标准，兴起了结构化的威胁信息表达（Structured Threat Information Expression，STIX），一种用于交换网络空间威胁情报的语言和序列化格式。借助STIX，可疑、攻陷和溯源的所有方面的内容都可以使用对象和描述性关系来清晰地表达。STIX信息可以直观地表示给分析人员，或者存储为JSON格式以便快速机器可读。STIX的开放性允许与现有工具和产品集成，或者用于特定分析师或网络需求。此外为了方便不同的组织和机构之间共享威胁情报，也诞生了情报信息的可信自动化交换（TrustedAutomated Exchange of Intelligence Information，TAXII）,一种基于HTTPS的应用层协议，是为支持使用STIX描述的威胁情报交换而专门设计。最后，2015年创建的ATT&CK（对手战术、技术及通用知识库）是一个反映各个攻击生命周期的攻击行为的模型和大型知识库，很好的利用它可以显著增强威胁情报能力，发现和防范更多更专业的黑客攻击行为。
随着越来越多的高级持续性威胁（Advanced Persistent Threat，APT）攻击事件被持续研究和曝光，威胁情报这个领域也在蓬勃发展。
【Adapt（适应）】
注：这部分的理论和实践还比较单薄，有待发展和细化。暂且按住不表。
除此之外，伴随整个流程通过对系统内外行为、日志、RASP系统监控到的异常、API网关、性能日志、安全事件等的持续的监控和分析完成闭环，不断的复盘改进从而自我完善持续提升安全风险管控能力。
腾讯与其他的所有公司都不同。这么多年的发展过程中，它的自研业务涉猎广泛几乎覆盖到了互联网所有的业务形态，重隐私要求高性能的通讯软件IM、快速试错的各种SNS功能、保守的支付金融等都融合到一家公司里，这使得作为支撑业务发展的技术呈现出了巨大的复杂性和挑战。安全技术也是如此，并且在DevOps时代，这一点或许还会持续。随着文章开头所提到的以腾讯CI、TEG智研平台等一系列的DevOps工具链的产生和发展，越来越多的业务开始尝试DevOps，在这一过程中也遇到了一些与已有的安全保障体系结合的困难和挑战，展开了DevSecOps的探索和实践。
3.1、DevSecOps工具链
虽然对于整个DevSecOps过程及工具链可以有一些更简化的理解和示意，但为了能够从业界最新的思考和实践中获得收益，也按照目前Gartner所给出的十大关键环节来展示公司内已有的一些工具/机制。（因涉及过多内部信息做了大量删减）
【Plan（需求和设计）】
• 公司安全规范/安全评估/威胁建模
• 安全培训
• 编码安全规范
【Create（编码/编译）】
• 安全开发库
• 安全相关的基础设施&框架机制
• IDE中的代码质量工具
• 代码review
• 安全加固的统一编译构建环境
• 安全加固的腾讯软件源
【Verify（测试/验证）】
【Preprod（预发布）】
• SAST 静态代码扫描“啄木鸟”
• 内部开源代码自动安全检查
• DAST “洞犀”/“金刚”
• IAST “洞犀”
– 结合流量代理技术
– 结合RASP和DAST技术
• APP加固
• Fuzzing
– 团队持续关注适时启动，reisk在《Fuzzing平台建设的研究与设计》与《持续Fuzzing在DevSecOps中的应用》中思考了很多，不再赘述。
• 混沌工程
【Release（发布）】
• 后台服务发布，安全加固的统一服务发布平台
• APP发布，证书和软件签名/发布
• 镜像安全扫描
• 安全加固的腾讯tlinux内核
【Prevent（预防）】
• 安全可追溯的运维访问
• 零信任安全网关
【Detect（检测）】
• 网络流量安全分析
– 相关内容《流量分析在安全攻防上的探索实践》一文对部分工作做了很好的说明
• 洞犀-上线后安全扫描
– 高危服务：针对内外网上的高危服务（如可被直接入侵、数据泄露等）进行全端口的持续监测，对于其中可蠕虫可入侵类的风险提供30秒内的发现能力。部分机房的外网开放风险可“一键防护”（基于宙斯盾的阻断能力），帮助运维同学快速的临时止损。参见《拥抱DevOps-“洞犀”高危服务扫描方案》
– Web漏洞：会有大量的Web业务并不进行上线前的安全扫描，因此洞犀系统会对外网所有的Web请求进行采集、去脏、去重等处理，识别出有效的CGI及参数（从万亿提取出百万量级CGI）。通过替换内置账号登录态（包括QQ、微信等）来发起安全扫描。
• 金刚-上线后安全扫描
– 也会有公司App不在上线之前做安全扫描，因此金刚系统与应用宝合作，会自动拉取公司的App进行安全扫描并跟进漏洞处理完成。有个外部可用的金刚服务可供测试。
• 洋葱（入侵检测系统）
– 利用公司服务器母盘中洋葱Agent采集到的进程、连接、可疑文件等信息，外加网络流量中的信息，采用专家规则和UEBA方式来发现入侵行为，是公司反入侵领域最强大的基石系统。部分内容参考《披荆斩棘：论百万级服务器反入侵场景的混沌工程实践》
• RASP方案TRASP
– 通过分析应用的运行行为以及上下文来发现Web应用安全威胁，并精准定位到漏洞源，由于与应用融为一体，可实时监测、阻断攻击，使应用自身拥有自保护的能力。可以实时检测发现针对web系统的各类入侵行为，包括SQL注入、命令注入、任意文件上传、任意文件读取、代码执行等。
• 腾讯安全应急响应中心（TSRC）漏洞奖励计划
– 提供资金激励吸引外部安全研究人员帮助腾讯发现更多潜在安全风险和漏洞
– 提供其他公司快速搭建SRC平台的 开源版本以及 SaaS版本，目前已经有10 知名公司使用
• 腾讯蓝军渗透测试
– 内容敏感不列出，持续进行。
– 获pony点赞《【原创】腾讯有个技术军团，“疯起来”连自己都打》，更多公开信息见lake的《网络空间安全时代的红蓝对抗建设》，蓝军领队wqzhong的《以攻促防：企业蓝军建设思考》
【Respond（响应）】
• 安全事件应急响应小组
– 7*24小时安全事件应急响应，第一时间响应，降低或消除事件影响
• 宙斯盾（DDoS防护）
– 见文章《军备竞赛：DDoS攻击防护体系构建》《浅谈DDoS攻防对抗中的AI实践》
• 门神（WAF）
– 见文章《WAF建设运营及AI应用实践》
【Predict（预测）】
• 安全服务中心
• 安全事件工单系统
• 威胁情报：TSRC安全情报平台，主动及时感知外部安全情报
– 提供100 知名软件的官方更新情报，5分钟内发现，30 外部公司使用
Adapt（适应）
• 待实践
整个信息产业发展到今天，软件系统日益庞大复杂，从业人员日益增多。单纯的依靠安全岗位这一角色来保证研发的系统不出现安全问题是很不现实的，这也是为何业界不断的爆出黑客入侵、数据泄露等安全事件的本质原因。于当下，安全不仅仅是安全工程师的责任，而应该成为一个组织整体的最高目标之一，需要每一个工程师的参与。安全和研发团队都要参与到DevSecOps研发模式的不断建设和优化中来，不断的推进DevSecOps理论和工具链的向前发展，不断的提供更好更便利的安全能力并且尽可能的通过自动化、自助化等方式为研发工程师赋能，使大家都能够承担起应有的安全责任，才能进行更好的安全管控。
最后，此文也会随着业界以及腾讯自身对于DevSecOps的研究探索和实践持续的更新。
附录：更多参考资料
[1].DevOps业界理论和实践
SREin google https://landing.google.com/sre/
DevOpsin amazon，https://aws.amazon.com/cn/devops/what-is-devops/
AWSre:Invent 2015 | (DVO202) DevOps at Amazon:A Look at Our Tools and Processes，https://www.youtube.com/watch?v=esEFaY0FDKc
DevOpsin aliyun，https://develop.aliyun.com/devops
DevOpsin 腾讯云，https://cloud.tencent.com/product/coding
AzureDevOps， https://azure.microsoft.com/zh-cn/solutions/devops/
DevOpsin RedHat， https://www.redhat.com/zh/topics/devops
IBMDevOps Insights， https://www.ibm.com/cn-zh/cloud/devops-insights
Akamaifor DevOps，https://www.akamai.com/cn/zh/solutions/performance/devops.jsp
GitHubActions， https://help.github.com/cn/actions
DevCloudin 华为，https://support.huaweicloud.com/productdesc-devcloud/devcloudpdtd00001.html
GartnerDevOps Mar 2019，https://blogs.gartner.com/christopher-little/2019/03/01/devops-mar-2019/
Stateof Devops 2019，https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
DevOps工具链，https://marketplace.atlassian.com/categories/devops?utmsource=wacmarketplace_landing
DevOpsChats，一个高质量的文集，https://devops.com/category/devops-chat/
DevOps书籍：《PracticalDevOps》
IaC书籍：《Infrastructureas Code: Managing Servers in the Cloud》
PuppetLabsDevOps状态报告@2015，https://puppet.com/resources/report/state-of-devops-report/
研发运营一体化（DevOps）能力成熟度模型，http://www.ccsa.org.cn/cgi-bin/ccsa.cgi?q=DevOps &m=all&ps=20&fmt=long&wm=wrd&sp=1&sy=1&wf=2221&ul=&tmplt=
[2].安全和DevSecOps业界理论和实践
敏捷软件开发，http://www.ambysoft.com/essays/agileLifecycle.html
DevSecOpsin RedHat，https://www.redhat.com/zh/topics/devops/what-is-devsecops
高质量DevSecOps文集，https://devops.com/category/blogs/devsecops/
谷歌团队《BuildingSecure & Reliable Systems》，https://static.googleusercontent.com/media/landing.google.com/zh-CN//sre/static/pdf/SRS.pdf
AgileApplication Security: Enabling Security in a Continuous Delivery Pipeline，https://www.amazon.com/Agile-Application-Security-Enabling-Continuous/dp/1491938846
DevSecOpssolutions in Sonatype ， https://www.sonatype.com/devsecops-solutions
研发运营一体化（DevOps）能力成熟度模型 第6部分安全管理，http://www.ccsa.org.cn/workstation/projectdisp.php?ul=ccsa&type=project&autoid=6745
DoDEnterprise DevSecOps Reference Design，https://dodcio.defense.gov/Portals/0/Documents/DoD Enterprise DevSecOps Reference Design v1.0_Public Release.pdf?ver=2019-09-26-115824-583
