好像学了很多次，有点体系，但细节一直很少，多作记录吧。
【Plan（需求和设计）】
• 偿还安全债务
类似于系统研发过程中因为各种各样的原因会出现很多技术债务，其实也会出现安全债务，需要认识到风险并且制定计划逐步偿还。举个真实的例子，某业务的登录设计采用Email账号+密码方式，这种单因子的方案肯定是不安全的，研发团队也注意到了该风险，上线了额外的扫码确认机制以完成安全的双因子登录认证。但是由于对推动客户开启的困难性以及该风险的重要性的低估等原因，并未有什么手段或计划去提醒或者强制客户开启该安全的登录方式，一直到最后爆发了大规模性的“撞库”进而产生了很多的恶意登录和利用发送垃圾消息，引起了广泛的关注造成不小的影响才慌忙应对，紧急修改产品流程强制客户开启。研发团队中肯定要有相应的角色能够承担产品流程和架构上的安全评估和设计并且持续评估和跟进推动问题的解决。
此外，老生常谈的话题肯定也少不了，包括安全意识、能力（编码规范、测试规范、等）等的制订、培训和考核。要注意，仅仅是漫无目的的教和学通常来说并不是十分有效，建立某种教考结合的方式是有必要的。研发人员至少要了解到各种各样可能的安全风险，而不能完全没有听说。
• 度量与指标
管理学中有一个说法：“你如果无法度量它，就无法管理它” (“It you can’t measure it, you can’t manage it”)。DevOps推进需要良好的度量方式，研发安全管控也是一样的道理。有些比较容易想到的指标可能并不是最优的，比如单纯根据漏洞数量来评判研发人员的安全能力乍一听有道理但是细想肯定有问题。有些人不写代码，有人写的多有人写的少，有人接手和维护了大量的已有系统老代码，单纯看漏洞数量势必会让辛勤解决安全问题的人吃亏，变成了“不做就不会错”，这显然不是一个好的导向。这些基础问题由于并不是那么炫酷，关注和探讨的人反而不多，个人觉得这是一个重要问题。一般来说，这里包括了安全系统的覆盖率，使用率，漏洞发现率，每千行代码的漏洞数量，漏洞修复速度等等方面，可用于评估研发团队的安全成熟度。
• 轻量有效的威胁建模
除了传统意义上的威胁建模方法论和工具以外，快速的安全自查checklist、安全知识库等都是一些有益的探索。目的都是要把需求和设计的安全评估推上持续构建的快车道。让这个过程不至于变的名存实亡。
• 安全流程和安全工具的使用培训
【Create（编码/编译）】
• IDE安全插件
各类的安全漏洞扫描、开源组件版本检查甚至是代码质量代码风格等的工具可以让研发人员在编码时就发现和消除一些潜在的安全风险。在DevSecOps时代，这个需要大力的投入，如果做的好，可以大大减轻后续环节的工作量。不过这里也面临一些挑战，比如针对源码静态分析的误报率问题，再比如某些安全漏洞准确的检测方案极度依赖编译或构建过程等等。有一些资源可以去参考，比如VSCode的插件商店等。
【Verify（测试/验证）】
自动化测试是必不可少的。安全领域会衍生出以下专用安全工具需要融入到流水线中。
• SAST
静态应用程序安全测试（Static Application Security Testing），是指针对源代码进行静态分析从中找到安全漏洞的测试方式，有些工具也会依赖于编译过程甚至是二进制文件，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确度。也被称为白盒测试（White-Box Testing）。常见的工具包括老牌的Coverity、Checkmarx、FindBugs等，比较新的CodeQL和ShiftLeft inspect。一般来说，优点是能够发现代码中更多更全的漏洞类型、漏洞点可以具体到代码行便于修复、无需区分代码最终是变成Web应用还是App、不会对现网系统环境造成任何的影响。但缺点也不少，比如研发难度高、多语言需要不同的检测方法、误报率很高、不能确定漏洞是否真的可利用、不能发现跨代码多个系统集成的安全问题等。传统的SAST因为始终不能很好的解决误报率问题，并且因为研发模式的问题，导致研发人员很难在编码结束之后又要花费非常长的时间来做确认漏洞的工作（其中可能大部分的都是误报），所以在一些行业并未大规模的应用，但是DevOps时代，结合CI的过程，上述一些新型的工具开始广泛利用编译过程来更精确的检测漏洞降低误报率，并且极小的CI间隔也让误报率问题带来的负担大大降低。
• DAST
动态应用程序安全测试（Dynamic Application Security Testing），是指在测试或运行阶段分析应用程序的动态运行状态。在不需要系统源码的情况下，通过模拟黑客行为构造特定的输入给到应用程序，分析应用程序的行为和反应，从而确定该应用是否存在某些类型的安全漏洞。也被称为黑盒测试（Black-Box Testing）。常见的工具包括针对Web应用商业和开源的Acunetix WVS，长亭科技X-Ray、w3af等，也包括一些针对电脑或终端App等的应用。这些工具的优点是从攻击者视角可以发现大多数的安全问题、准确性非常高、无需源码也无需考虑系统内部的编码语言等。但缺点也很明显，需要向业务系统发送构造的特定输入有可能会影响到系统的稳定性和写坏数据、因参数合法性、认证、多步操作等原因难以触发从而导致有些漏洞发现不了、漏洞位置不确定导致修复麻烦、某些可能非常耗费资源（如基于安卓虚拟机等）或者耗费时间（又不能影响环境运行又要发送大量请求并且等待响应）等。从腾讯的实际情况来看，DAST技术依然是最可靠的漏洞检测技术，发现了大量的真实安全漏洞。传统的依赖人手动来提交的方式依然无法适应DevOps，所以结合了下文IAST手段的全自动化的方式越来越多的被发掘和使用。
• IAST
交互式应用程序安全测试（Interactive Application 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
软件成分分析（Software Composition Analysis）。如前文所指出，越发快速的开发意味着开发者要大量的复用成熟的组件、库等代码。便捷的同时也引入了风险，如果引用一些存在已知漏洞的代码版本该怎么办？如何检查他们？这衍生出了SCA的概念和工具。有一些针对第三方开源代码组件/库低版本漏洞检测的工具也被集成到IDE安全插件中，编码的时候只要一引入就会有立即的安全提醒，甚至帮你修正引入库的版本来修复漏洞。有一点需要留意，有些编码语言或方式的检测方法会很简单（如nodejs等带有包管理类功能），但有些可能并不容易（如c/c++等）。
【Preprod（预发布）】
部分的措施在某些情况下会融合到上一个阶段“Verify”中。
• 混沌工程（Chaos Engineering）
简单来说，这套方法论认为分布式系统中的各种故障和问题都是不可避免的并且随着复杂度不断提升已经不太可能通过上线之前的测试来发现，但是系统架构要确保在这种情况下依然能够提供稳定持续的服务。混沌工程方法论通过在分布式系统中自动注入各种预设的故障来增强系统可用性以及自动的发现脆弱的环节并改进。这是一个很大的话题，我们不做详细展开。这里举个例子，Netflix公司的“Chaos Monkey”项目，就像一只淘气的猴子跑进了你的机房里面乱打乱踢，随机产生了诸如进程被杀死、服务器断网、机架掉电等各种各样的故障和问题，你的系统需要确保在这样的情况依然可以提供持续稳定的服务。这个相当于系统可用性建设中的自动化演习，只不过它把这种演习直接做到了系统架构中，可以随时随地随机的在预发布环境甚至是线上环境中展开，以此逼迫系统面对故障时彻底的自动化恢复以及可以尽早的发现和解决可用性问题，此外混沌工程还关注异常时的度量等信息以供分析人员使用。有关这个详情推荐参考其官方著作《混沌工程：Netflix 系统稳定性之道》。
在安全方面虽然有一些公开项目比如“Security Monkey”，但只是一个传统意义上的监控机制，还有待持续发展。要把一些安全的异常或自动化的攻击测试融入到线上系统架构中以不断的锤炼提升系统处理过程中的安全性，举些例子比如本来是一个正常的对数据库的查询，但是一旦这些请求替换成了“拖库”的行为，应用本身可否安全的处理？甚至我们假设系统中的安全漏洞无可避免，这种情况下有无办法发现或杜绝“拖库”行为？这些其实反过来都对系统的安全架构和设计提出了更高的挑战和要求，还需要在混沌工程的思维和框架之下做更多的一些思考和实践。另外需要注意，虽然Gartner将混沌工程放到了这个预发布环节，但实际上不仅仅是在预发布系统中才会有，最早提出这一方法论的Netflix是会在线上环境持续的进行，这听起来很吓人，但使用真实环境带来的收益肯定也是非常高的。
• Fuzzing
又被叫做模糊测试（Fuzz Testing），这可能是一种最古老的安全测试技术。通过把自动或半自动生成的随机数据给到一个程序并监控它的异常（crash等）来判断是否存在安全漏洞。常常被用于文件格式解析、网络协议解析等程序的安全测试中，经过30多年的发展，这项技术逐步结合了动态分析、静态分析、插桩、覆盖引导、符号执行等技术。在谷歌Project Zero、腾讯Blade Team等安全研究团队所发现众多影响广泛的漏洞中，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 System Cybersecurity with Defense-in-Depth Strategies》。
Detect（检测）
• RASP
运行时应用自我保护（Runtime Application Self-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 and Automation）、安全事件响应平台（SIRP，Security Incident Response Platform）和威胁情报平台（TIP，Threat Intelligence 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 Vulnerability Correlation（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的开放性允许与现有工具和产品集成，或者用于特定分析师或网络需求。此外为了方便不同的组织和机构之间共享威胁情报，也诞生了情报信息的可信自动化交换（Trusted Automated Exchange of Intelligence Information，TAXII）,一种基于HTTPS的应用层协议，是为支持使用STIX描述的威胁情报交换而专门设计。最后，2015年创建的ATT&CK（对手战术、技术及通用知识库）是一个反映各个攻击生命周期的攻击行为的模型和大型知识库，很好的利用它可以显著增强威胁情报能力，发现和防范更多更专业的黑客攻击行为。
随着越来越多的高级持续性威胁（Advanced Persistent Threat，APT）攻击事件被持续研究和曝光，威胁情报这个领域也在蓬勃发展。
【Adapt（适应）】
注：这部分的理论和实践还比较单薄，有待发展和细化。暂且按住不表。
除此之外，伴随整个流程通过对系统内外行为、日志、RASP系统监控到的异常、API网关、性能日志、安全事件等的持续的监控和分析完成闭环，不断的复盘改进从而自我完善持续提升安全风险管控能力。
三、DevSecOps试水
腾讯与其他的所有公司都不同。这么多年的发展过程中，它的自研业务涉猎广泛几乎覆盖到了互联网所有的业务形态，重隐私要求高性能的通讯软件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业界理论和实践
SRE in google https://landing.google.com/sre/
DevOps in amazon，https://aws.amazon.com/cn/devops/what-is-devops/
AWS re:Invent 2015 | (DVO202) DevOps at Amazon:A Look at Our Tools and Processes，https://www.youtube.com/watch?v=esEFaY0FDKc
DevOps in aliyun，https://develop.aliyun.com/devops
DevOps in 腾讯云，https://cloud.tencent.com/product/coding
Azure DevOps， https://azure.microsoft.com/zh-cn/solutions/devops/
DevOps in RedHat， https://www.redhat.com/zh/topics/devops
IBM DevOps Insights， https://www.ibm.com/cn-zh/cloud/devops-insights
Akamai for DevOps，https://www.akamai.com/cn/zh/solutions/performance/devops.jsp
GitHub Actions， https://help.github.com/cn/actions
DevCloud in 华为，https://support.huaweicloud.com/productdesc-devcloud/devcloudpdtd00001.html
Gartner DevOps Mar 2019，https://blogs.gartner.com/christopher-little/2019/03/01/devops-mar-2019/
State of Devops 2019，https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
DevOps工具链， https://marketplace.atlassian.com/categories/devops?utmsource=wacmarketplace_landing
DevOps Chats，一个高质量的文集，https://devops.com/category/devops-chat/
DevOps书籍：《Practical DevOps》
IaC书籍：《Infrastructure as Code: Managing Servers in the Cloud》
Puppet LabsDevOps状态报告@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
DevSecOps in RedHat，https://www.redhat.com/zh/topics/devops/what-is-devsecops
高质量DevSecOps文集，https://devops.com/category/blogs/devsecops/
谷歌团队《Building Secure & Reliable Systems》，https://static.googleusercontent.com/media/landing.google.com/zh-CN//sre/static/pdf/SRS.pdf
Agile Application Security: Enabling Security in a Continuous Delivery Pipeline，https://www.amazon.com/Agile-Application-Security-Enabling-Continuous/dp/1491938846
DevSecOps solutions in Sonatype ， https://www.sonatype.com/devsecops-solutions
研发运营一体化（DevOps）能力成熟度模型 第6部分安全管理，http://www.ccsa.org.cn/workstation/projectdisp.php?ul=ccsa&type=project&autoid=6745
DoD Enterprise DevSecOps Reference Design，https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583
[3].安全和DevSecOps业界理论和实践
敏捷软件开发，http://www.ambysoft.com/essays/agileLifecycle.html
DevSecOps in RedHat，https://www.redhat.com/zh/topics/devops/what-is-devsecops
高质量DevSecOps文集，https://devops.com/category/blogs/devsecops/
谷歌团队《Building Secure & Reliable Systems》，https://static.googleusercontent.com/media/landing.google.com/zh-CN//sre/static/pdf/SRS.pdf
Agile Application Security: Enabling Security in a Continuous Delivery Pipeline，https://www.amazon.com/Agile-Application-Security-Enabling-Continuous/dp/1491938846
DevSecOps solutions in Sonatype ， https://www.sonatype.com/devsecops-solutions
研发运营一体化（DevOps）能力成熟度模型 第6部分安全管理，http://www.ccsa.org.cn/workstation/project_disp.php?ul=ccsa&type=project&auto_id=6745
DoD Enterprise 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
DevSecOps在携程的最佳实践，https://mp.weixin.qq.com/s/yOykOPU9wn77doz95s5LeA
DevSecOps-Toolchain，https://github.com/zemmali/DevSecOps-Toolchain/blob/master/DevSecOps-Toolchain.jpeg
DevSecOps：打造安全合规的 DevOps 平台，https://developer.ibm.com/zh/articles/cl-lo-devsecops-build-a-devops-platform-for-security-compliance/
DevSecOps in Synopsys，https://www.synopsys.com/zh-cn/software-integrity/solutions/by-security-need/devsecops.html
DevSecOps with GitLab，https://about.gitlab.com/solutions/dev-sec-ops/
DevSecOps in cicso，https://blogs.cisco.com/tag/devsecops
DevSecOps in Baidu，https://mp.weixin.qq.com/s/YQmdDs4FdcwWlhkmfWYSoQ
Netflix的DevSecOps最佳实践，https://mp.weixin.qq.com/s/o21aESHLQnVKW_S5_rVb0w
Putting Security Into DevOps，https://cdn.securosis.com/assets/library/reports/Security_Into_DevOps_Final.pdf
