目录
1.前言
时常看到devops、devsecops可以一直没有用心研究过，今天对其做一个小小的研究与总结。
2.devops
devops的中文含义是development & operation，也就是开发与运维。它是软件开发领域的一个专业术语，是一种研发模式。此研发模式的特点是交付快、与运维的粘合度高，将写码、测试、反馈融为一体，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
腾讯内部以腾讯CI、k8s等为代表的DevOps平台不断发展和完善，也有越来越多的业务开始尝试使用这种研发模式。
devops开发模式与传统的瀑布开发和敏捷开发都有所不同，在我看来，它是基于敏捷模式改造的，通过全自动化的产品将产品开发中所需的写码、测试、部署融合为一体，进而提高整个研发效率，进而提高产品竞争力，具体如下图：
瀑布模式相比较而言效率比较低，而且倘若项目出现问题需要否掉的话，代价相比较而言是最大的。因为瀑布型理论上只有三个决策点，每一个决策点之前都面临着十分大的工作量，若突然否掉项目的话是十分耗费财力物力的。
敏捷模式相比较于瀑布模式效率就高了不少，它在决策阶段把项目分成了一个一个小部分，然后写一个模块测一个模块接着部署一个模块。
devops模式有点像一个加强版的敏捷模式，它通过自动化平台将写代码、测试、部署融为一体，使得开发人员能很快的得到反馈，极大的提高了交付效率，这种开发模式将开发人员、测试人员、运维人员的工作紧紧的结合在一起，也提高了工作效率。devops模式的出现就是为了以最快的速度产出一个最小的具有商业价值的产品然后让决策者进行判断是否要继续完善。
特别说明一下，并不是说你使用了一些CI或CD平台，就是做到了DevOps。实际上想要真正成功实施DevOps并从中获得优势，可能是需要改变整个产品设计、研发流程、系统架构以及思考方式，需要建设成熟的研发基础设施等工作的，这一点极其重要！举个最简单的例子，如果你的系统还不能做到自动化测试，直接上DevOps可能会死的很惨。因此，DevOps本身的实践也是一个过程，需要结合自身研发的痛点来有针对性的逐步发展。不过通常来说，CI和CD可能是迈向DevOps的第一步。
3.devsecops
DevSecOps是完全遵循DevOps的思想，将安全无缝集成到其中的一种研发模式。传统的SDL是一种基于瀑布模式或者敏捷模式的安全开发管理方法。它的缺点是只关心开发与安全检测这两个方面，是跟运维完全隔开的，说白了就是我只关心我的产品是否安全，功能是否齐全，我不关心产品卖出去后对方的运维工程师的运维成本与难度，如果运维有难度反馈回来我们接着按照SDL去改，而Devsevops解决了这个问题，它使得拥有SDL开发模式的安全度的同时又兼顾与运维ops的联动，最大限度解决问题。
3.1 SDL
图：SDL过程实践，这是官方发布的中文版本，其中的“要求”对应“需求”，“实施”对应“编码”
SDL只是在研发与测试的各个阶段加入了安全要求的技术点，是通过安全工程师的的参与来降低产品中出现安全漏洞的风险，不过忽略了运维工程师。
3.2 devops对SDL的挑战
DevOps出现后随之而来有了新的问题，DevOps只关注研发、测试、运维这三个方面，没有安全的容身之地，而随着业务复杂度的增加，安全问题愈加严重，而SDL与DevOps八字不合。这就意味着仅使用DevOps的话，安全性不太容易得到保障。DevOps对传统安全SDL的挑战目前看主要体现如下等几个方面：
• 弱化的设计过程使安全评估难以展开
• 高速的交付让安全过程无从下手
• 云、微服务、容器等技术需要新的安全能力
• 安全的职责分离原则被挑战
于是devsecops应运而生：
一句话说，devsecops就是遵循devops的思想并将安全无缝融入到其中。
3.3 DevSecOps原则
1.安全左移
大多数情况，安全检测都局限在产品上线前的某几周里进行集中的产品安全测试，在高发布的需求下，安全工程师根本没有办法完成如此庞大的任务量，因此需要更多的关注研发流程的“左”边，在更早的环节中（设计、编码、自动测试）也要进行安全介入和管控。
解决方案：
1.使用源码安全扫描工具
2.使用开源组件进行开发
2.默认安全
短时间内在人员安全能力无法进行质变的前提下，通过提供默认安全的开发框架或者默认安全的组件可能很好的防止犯低级错误，比如框架内置的anti-csrf token安全机制，你在一个基于CodeIgniter框架并且打开了该项配置的应用中可能很难找到CSRF漏洞。
默认安全的原则并不仅仅限于代码，Web接入层上默认覆盖的WAF、默认安全配置的云/容器/数据库/缓存等基础系统和服务、统一的登录鉴权认证服务、KMS（密钥管理系统）、保护关键数据的票据系统、零信任（Zero Trust）架构等等，都是默认安全的很好实践。
这也要求安全团队要参与到整个系统架构、基础设施等的建设中。反过来也会要求更多的组织架构保障以及安全与研发团队之间的沟通协作能力。
3.运行时安全
在越来越快的发布之下，安全的考量除了左移和默认安全以外，更加需要特别关注和加强上线后运行时的异常监控和攻击阻断能力提升，需要有更加及时快速自动化的风险监控、发现、阻断、恢复等的手段和机制。安全机制也需要有提升系统可用性的机制和能力，其重点在识别内外部的安全风险上。
4.安全服务自动化/自助化
实现安全服务的自动化，向研发人员或者运维人员提供易于使用的安全工具，不能过多按扰DevOps的各个流程，要让一切看起来流畅且井然有序。
总而言之，需确保安全测试和检查服务能够自动化和自助化并且提供快速且清晰的反馈。界有一些研究和尝试比如漏洞代码自动修复（MIT的CodePhage，GitHub发布的针对开源漏洞组件自动修复的Dependabot）等技术，虽然目前看有些成熟度可能还不高，这些方向虽然困难但绝对是正确的，是一种贯彻DevSecOps思想的尝试。
5.基础设施即代码
我的理解是利用代码或者说shell脚本来一键配置所有的基础设施，利用其确保大规模场景下配置、环境和系统行为等的一致性，通过版本控制、代码审计、重构、动静态分析、自动测试等手段持续交付流水线来验证和部署IaC设施，确保标准化、可审核并且使之更安全，减少攻击者发现和利用运维漏洞的机会。
6.利用持续集成和交付
从本质上说，更快速的变更意味着每次变更的范围更小且独立性更强，轻量级的变更更容易被理解和检查，所需的测试也会更快，错误也会更容易发现，发现问题时修改起来也更简单。当然，如果你的代码更加标准化（如代码风格、代码规范、框架及架构等），这一点会越有利。有一些研究结论也表明，研发安全领域，轻量而频繁的变更可能让系统变得更安全。从腾讯以往的漏洞数据来看，一些老旧的站点确实存在着大量的漏洞不断的被发现。
7.需要组织和文化建设
DevOps以及DevSecOps并不像某些ERP软件系统那样，买一套部署，然后用起来就解决了。对于一些想要践行的公司来说，DevSecOps工具链需要去提取痛点（需求）、购买/研发系统并部署、推广使用以及建立度量这样一个正向循环才能持续发展，并由一个个业务、部门逐步试用推广变成整个公司的研发方法论，在这个过程中也需要辅以研发文化的建设。这个过程还需要结合各个公司的一些实际情况来具体问题具体分析，以一步步解决问题提升研发效能的方式来制定适合自己的DevSecOps实践方案。比如谷歌会有专门的组织架构及员工角色SRE（Site Reliability Engineering）联合他们的专业安全团队来共同践行DevSecOps，而腾讯因为历史上业务和技术发展情况的不同，组织架构上可能需要通过内部的开源协同方式来聚集一些团队共建DevOps及DevSecOps。
除了以上原则外，最后还有一点需要留意。就是要特别关注安全建设的衡量和实际效果的评估和改进，安全不是一蹴而就，要结合内外力量避免虚假的安全感。一些措施如经常性的红蓝军（Red Teaming）对抗渗透测试（Pen Testing）、针对外部安全研究人员的漏洞奖励计划（Bug Bounties）、完善的安全事件复盘等都是一些已知的不错实践。
4.devsecops各个环节实践
目前DevSecOps的实践还是在快速摸索和发展阶段，Gartner在2019年的一篇文章中，给出了一个它经过调研和分析之后认为的一个比较全面的实践清单（在DevOps的工具链基础上，增加Sec工具链实践）如上图，由一系列关键路径和持续的关键步骤中的措施和机制组成，周而复始的运转。
1.plan阶段（需求与设计）
需求与设计阶段需要完成以下工作：
1. 安全债务解决者
某业务的登陆页面本来是有双因子认证的，但由于客户那边觉得麻烦或者风险低估等原因导致没有开启这个模块，可后面出了安全问题，这种安全问题我们其实已经想好了解决方案，只是因为其他原因无法及时实施而已，这种安全问题我们称之为安全债务。
这时候应该有专人负责这种事件，他应该在出问题的时候让客户强制开启双因子认证模块并及时跟进效果并获得反馈。
2. 度量与指标
建立一个合适的度量单位和指标来对研发人员的安全能力进行评级与管理。
3. 轻量有效的威胁建模
除了传统意义上的威胁建模方法论和工具以外，快速的安全自查checklist、安全知识库等都是一些有益的探索。目的都是要把需求和设计的安全评估推上持续构建的快车道。让这个过程不至于变的名存实亡。
4. 安全流程和安全工具的使用培训
对研发人员进行适度的培训，让其更有自发的安全意识，目标是使其能更多的自我发现安全问题。
2.create阶段（编码）
编码阶段需要注意的点：
1. IDE上安装安全扫描相关的插件
各类的安全漏洞扫描、开源组件版本检查甚至是代码质量代码风格等的工具可以让研发人员在编码时就发现和消除一些潜在的安全风险。
DevSecOps时代，这个需要大力的投入，如果做的好，可以大大减轻后续环节的工作量。不过这里也面临一些挑战，比如针对源码静态分析的误报率问题，再比如某些安全漏洞准确的检测方案极度依赖编译或构建过程等等。有一些资源可以去参考，比如VSCode的插件商店等。
3.verify阶段（验证）
需要将以下方向的专用工具融入到自动化测试的流水线上：
1. SAST-静态应用程序安全测试
也被称为白盒测试（White-Box Testing）。常见的工具包括老牌的Coverity、Checkmarx、FindBugs等，比较新的CodeQL和ShiftLeft inspect。
优点：速度快、发现漏洞更全、漏洞点可以具体到代码段因此方便修复、无需区分最终代码最终会变成web还是app、不会对现有网段产生任何影响
缺点：误报率高、研发难度高不同的语言审计逻辑不一样、不确定每个漏洞是否真实可以利用、不能发现跨代码多个系统集成的问安全问题、与实战相差比较大不一定能抵御真实环境中的所有问题
2. DAST-动态应用程序安全测试
也被称为黑盒测试。在不知道源代码的前提下尽全力寻找产品的安全问题并对其加以利用。
优点：准确度很高、无需源码、贴近实战
缺点：容易对网段产生破坏、漏洞位置不确定导致修复起来比较麻烦、可能非常耗费时间与资源、有一些需要多步操作的漏洞可能无法发现，但这种漏洞对于拿不到源码的黑客来说也很难有利用价值
3. IAST-交互式应用程序安全测试
也被称为灰盒测试。将黑盒测试与白盒测试结合在一起，并进行全自动化扫描且能融入产品线的一种测试方式，开源软件有百度的openrasp-iast。具体方法可以理解成在程序的关键模块或者函数上进行”插桩“，根据程序的反馈来检测程序漏洞。agent和扫描器端全部在web服务器上，当web服务器接收到来自外界到访问时，自动触发漏洞扫描。通过在服务端部署agent程序，收集、监控Web应用程序运行时函数执行、数据传输，并与扫描器端进行实时交互，高效、准确的识别安全缺陷及漏洞。相比较传统的扫描器只扫描payload来说，确实更加准确。
openrasp-iast 是被动扫描模式，不会使用爬虫技术去获取URL信息。那么它更像是一个辅助黑盒测试的工具，根据用户发送的请求执行对应的扫描程序，例如用户发送的请求拼接了某个sql查询，那么就会对这个请求进行记录然后进行sql注入漏洞扫描。
参考文章：灰盒测试IAST
对IAST对补充：rasp
RASP（Runtime Application Self-protection）是指在程序运行时对程序行为进行保护，可以看做是一个精确到函数级别的WAF，Web 应用防火墙放置在 Web 应用程序外层，拦截所有它认为可疑的输入而并不分析这些输入是如何被应用程序处理的。RASP 会精确分析用户输入在应用程序里的行为，根据分析结果区分合法行为还是攻击行为，然后对攻击行为进行拦截。 RASP 不依赖于网络流量分析，因此避免了新协议解析，字符解码，复杂的正则表达式匹配以及基于签名的威胁鉴别等麻烦。
4. SCA-软件成分分析
我们在引入成熟的组件或者库的时候不会很确定这些组件是否有漏洞，这时候就需要一些针对库/组件的漏洞检测工具了，将这些漏洞工具集合在IDE安全插件中能避免部分有漏洞的组件/库存在于我们的项目中。
4.preprod阶段（预发布）
预发布前需要完成以下的步骤：
1. 实施混沌工程类型的测试
混沌工程方法论通过在分布式系统中自动注入各种预设的故障来增强系统可用性以及自动的发现脆弱的环节并改进可以最大限度的测试程序的健壮性。
2. fuzzing
fuzzing常常被用于文件格式解析、网络协议解析等程序的安全测试中，它的优点在于高代码覆盖，缺点是速度慢。当前的痛点在于如何使得fuzzing的速度与devops的版本发布速度匹配，不久前谷歌刚公开的CIFuzz以及RSA创新沙盒比赛中ForAllSecure公司的参赛产品-下一代Fuzzing解决方案“Mayhem”都是不错的尝试。
3. 集成测试
将所有的模块组装成整体进行测试，有点类似于黑盒测试。
4.Release阶段（发布）
1. 软件签名
给软件加上软件签名。
5.Prevent阶段（预防）
我的理解是发布后自己对其的又一次测试：
签名验证
完整性检查
纵深防御措施
要按照层级去配置防御工事，假定单个的安全措施和机制都会失效或被绕过，所以需要采用分层的方式，使用独立的一个个措施来层层的进行防御，不能仅仅依赖边界防御。
RASP
它的一些底层技术实现可能会跟某些IAST很类似，比如PHP中使用扩展来Hook、Java环境中采用Java Agent机制来Hook等。国内开源且比较知名的方案是百度的OpenRASP。但是要注意的是，该方案带来巨大收益的同时也因为修改了运行时环境的底层，可能会对应用的性能、兼容性、稳定性等造成或多或少的影响，在评估和实现方案时需要重点考虑和应对。
UEBA/网络监控
用户和实体行为分析（User and Entity Behavior Analytics），通过对用户以及系统实体在数据层面的异常行为利用机器学习的方法来发现网络安全、IT办公安全、内外部的业务安全等风险，如数据泄露、入侵、内部滥用等的安全问题。
渗透测试
6.Respond阶段（响应）
运维工程师对可能发生的安全事件进行响应，例如分析防火墙或者RASP日志与使用自动化的安全运营平台：
1. 安全编排
Gartner在2017年提出了安全编排自动化和响应（SOAR，Security Orchestration, Automation and Response）的概念。这一技术定义安全事件分析与自动化响应工作流程。采集各种运营团队关心的安全检测系统数据，对他们进行分析与分类，利用最资深安全分析人员的专家经验，自动化的来定义、排序和驱动按标准工作流程执行的安全事件响应活动。Gartner后来又从理论上发展出了更细致的定义，安全编排与自动化（SOA，Security Orchestration and Automation）、安全事件响应平台（SIRP，Security Incident Response Platform）和威胁情报平台（TIP，Threat Intelligence Platform）三种技术/工具的融合。这一概念未来还会快速演化和发展，甚至内涵都有可能会变化，但是都将是致力于解决DevOps下如何快速准确的响应和预测安全事件。
安全编排这个概念，简单来说，在一个实际有效的安全响应和安全运营过程中，会有很多日常的分析、响应等的工作，这些工作以前大都靠人以及人的经验来驱动，这样的方式弊端很大，特别是现在的应用、数据以及安全系统越来越多和复杂，因此整个的过程需要采用自动化的剧本来代替人肉驱动。
2. RASP/WAF 防护
一些RASP方案除了在上面的检测环节以外，还可以直接做响应比如拦截等，这就可以在此阶段起作用。相对于RASP这个新事物，传统的WAF（Web Application Firewall，Web应用防火墙）早已被大量的部署使用。不同于私有协议的应用，互联网时代Web形态的业务大量存在，而刚好它利用的又是一种公开的通用的HTTP(S)协议，因此WAF应运而生并且一直以来发挥着重要的作用。它假定应用中肯定有漏洞存在，在这种情况下依然可以阻断实际产生的某些攻击尝试和行为如入侵服务器、数据拖库、盗取用户信息等。传统的专家规则、前些年的机器学习以及最新的词法语法分析等技术陆续被用于升级WAF系统，以提升覆盖率并且降低误报率。另外除了应对传统的Web漏洞攻击、CC攻击以外，WAF也逐渐发掘出了反爬虫、打击羊毛党等的场景，将安全能力从漏洞防护扩展到了业务安全领域。
如前文所讲，RASP这种技术方案来做阻断之类的响应时也有一些实际的问题和困难需要去不断解决和完善，而传统的WAF因为无法感知应用逻辑（某个攻击请求真的被应用执行了么？）也会存在误报等的问题，在未来，打造成熟的基于RASP技术结合的WAF可能是一个趋势。
3. 混淆
7.Predict阶段（预测）
1. 漏洞相关性分析
漏洞的发现肯定无法依靠单一的一种工具和方式，而是会由如上文的SAST、DAST、IAST、RASP以及人工渗透测试等各种各样的手段以及工具来完成。但也会产生新问题，比如这些方式和工具存在着重复扫描、难以协同等。在这种情况下，就催生出了AVC这个方案。理想中的AVC方案可以管理所有的安全工具，通过标准化数据格式等方式以使他们之间更高效的协作，以此来更高效的发现和管理所有环节的漏洞。这里Gartner以CodeDx做为首选供应商，它的目标是通过自动关联和漏洞管理来缩短安全测试所需时间、降低误报、降低安全测试成本，使团队专注于开发即可。
2. 威胁情报 IoC/TI STIX TAXII
威胁情报（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）攻击事件被持续研究和曝光，威胁情报这个领域也在蓬勃发展。
8.Adapt阶段（适应）
暂无
5.腾讯对于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（适应）】
• 待实践