1.2　DevSecOps简介

上一节我们用一个图简单描述了从传统研发模式到DevOps模式的转变。然而，传统DevOps主要考虑速度和质量，并没有考虑信息安全。所以，在DevOps比较成熟的情况下，信息安全就变成了研发效能继续改进的瓶颈。DevSecOps的最终目的就是通过安全左移到开发测试团队，使安全评审阶段的时长变短，从而进一步缩短交付周期（如图1-4所示）。并且它可以在更早的阶段发现并修复安全漏洞，从而减少上线前发现安全漏洞的返工成本。

1.2.1　从DevOps到DevSecOps

DevSecOps是Gartner在2012年就提出的概念，其原始术语是DevOpsSec。2017年RSA峰会之后，DevSecOps开始成为世界热门话题。DevSecOps延续了DevOps的理念，其设计与执行仍然处于Agile的框架之下。DevSecOps的目标是将安全嵌入到DevOps的各个流程中（需求、架构、开发、测试等），从而实现安全的左移，让所有人为安全负责，将安全性从被动转变为主动，最终让团队可以更快、更安全地开发出质量更好的产品。

所谓安全左移，在实践中就是为了让团队对他们开发的内容负责，通过将安全等工作（比如测试安全）从部署前的安全评审阶段左移到更早的阶段，从而更早、更快地发现并解决安全问题，而不是等到几天后部署时才发现，或者几个月后再发出渗透测试报告。DevSecOps的出现并非偶然，它是软件持续交付演进的必然产物。在这种新型软件交付模式下，安全行为会散落在软件交付的各个阶段，而安全的职责也会落在各个阶段的参与者身上，而不再是主责落在安全团队身上。DevSecOps可以给研发效能提供诸多好处，主要表现在以下三个方面（见图1-5）：

1）交付更快：DevSecOps通过自动化安全工具扫描，无感地左移了部分传统模式中在上线前最后阶段进行的安全扫描工作，使整个交付周期变得更短，交付速度因此变得更快。比如在图1-5中，由于安全评审阶段时长的减少（T7），交付周期从DevOps模式下的T1，变成了DevSecOps模式下的“T1–T7”。

2）节省成本：DevSecOps由于在SDLC前期阶段发现并且修正安全隐患和漏洞，避免了传统模式中在上线前最后阶段进行安全扫描发现高危安全漏洞后进行的返工，从而从流程上节省了成本。比如在图1-5中，在上线前发现高危安全漏洞返工修复安全漏洞后，整个开发、测试和安全评审流程又要重新走一遍，因此额外消耗的成本就是T2时间下的人力。在DevSecOps模式下，由于安全左移到了开发或者测试阶段，因此，如果高危安全漏洞在开发阶段被发现，那么额外耗费的人力也仅仅是开发时长T4下的人力，节省下来的是“T2–T4”时长下的人力。而如果高危安全漏洞是在测试阶段被发现的，那么返工额外消耗的人力就是“T4 + T5”下的人力，因此节省下来的就是“T2–T4–T5”下的人力。

3）控制风险：DevSecOps减少了开发团队对安全部门/团队的依赖，通过安全左移让开发团队具备发现和修正部分安全隐患和漏洞的能力。

另外，在传统模式下，安全部门/团队往往扮演“警察”的角色为企业的安全提供保障，因此有时会因为安全隐患或者风险从而阻止或者延迟开发团队交付上线。基于这种关系，因为大家的目的不同，开发团队和安全团队的关系往往并不是那么融洽，有时甚至会产生矛盾。然而，DevSecOps的目的是通过将安全左移最终让所有人为安全负责。因此，将不再有安全“警察”的角色来监督开发团队，而是开发团队为自己开发的产品的安全性负责。

虽然DevSecOps是DevOps演进的必然结果，但是在DevSecOps实践落地的过程中，仍然面临来自技术、流程、人和文化诸多方面的困难和挑战（如图1-6所示）。其中技术挑战主要来源于两个方面：

1）由于DevSecOps是一个全新的概念，因此市场上可选择的开源和商用工具并不太多。

2）现有的很多DevSecOps工具也并不成熟（比如误报率、专业性要求高等问题），所以也增加了DevSecOps工具在推广和使用过程中的难度。

相比来自技术的挑战，人和文化方面的挑战则影响更大。对于程序员来说，他们的主要工作是写代码，所以很多程序员可能缺乏相关的安全意识，并且简单地认为安全不是他们的职责，而是安全团队的职责。美国威胁检测公司Threat Stack针对北美大中小企业200多名安全、开发和运维专业人员的一项调查和报告表明，DevSecOps仍然停留在理论阶段。造成这种情况的主要原因一是信息安全知识和能力并没有得到普及，二是缺少高层的支持，业务领导者甚至对此并不鼓励。报告中指出，只有27%的运维团队和18%的开发团队配备了安全专家；超过44%的开发人员没有接受过任何安全编码的培训；42%的运维人员没有接受过基本安全实践方面的培训。因此，就算有些开发人员有安全方面的意识，但他们可能不具备安全编码和修复安全漏洞的能力，所以需要相关的安全培训。然而，信息安全毕竟是一门独立的学科，因此也增加了程序员的学习成本。最后，与DevOps刚出现时一样，作为一个全新的概念，DevSecOps的理念还没有得到普及，因此很多时候得不到高级管理层的支持。报告中也指出，52%的公司承认会削减安全措施，以便在截止日期前完成业务目标。68%的受访企业CEO不允许因为安全问题让业务交付变慢。从这个报告可以看出，如果没有管理层自上而下的支持，DevSecOps的推动会非常缓慢，甚至停滞不前。

针对以上种种挑战，DevSecOps也给出了对应的最佳实践（见图1-7），以便进一步在企业里进行推广。比如在技术层面，DevSecOps最佳实践强调自动化信息安全，甚至将安全扫描进一步左移到IDE阶段，更早发现并修复问题，从而节省成本。另外，安全指标也可以作为质量门禁，用来保障交付的安全性。人和文化层面强调持续培训和安全意识的培养，以及DevSecOps负责人和开发团队里DevSecOps“专家”等新角色的定义（详细内容请查看第2章）。流程层面强调定期的代码审查、红蓝对抗，通过DevSecOps度量发现研发过程中的瓶颈，以及评估DevSecOps改进的效果（详细内容请查看第8章）。

1.2.2　从SDL到DevSecOps

1. SDL

传统的基于瀑布和敏捷开发的研发模式下，有很多软件安全开发的管理理论方法，比如BSIMM（Building Security In Maturity Model）、SAMM（Software Assurance Maturity Model）等。其中，一个由微软发明并向业界推荐的行之有效且被IT/互联网行业大量使用的最佳安全实践，被称为安全开发生命周期（Security Development Lifecycle，SDL），这套方法论和其中的最佳实践已经成为一些行业事实上的标准，国内外各大IT和互联网公司都在基于这套理论和实践，结合自己的研发实际情况进行研发安全管控。从图1-8中我们可以看到整个过程，需要注意的是，SDL本身并未关注运维，为了弥补这个缺陷，微软也推出了OSA（Operational Security Assurance）。SDL在研发、测试之外定义了安全的角色，通过流程上的保证，使安全人员及其工作能够嵌入到研发过程的各个环节中，以此来降低产品中出现安全漏洞的风险。

2. DevOps对SDL的挑战

DevOps出现之后，问题也随之出现。传统意义上的DevOps只关注开发、测试、运维及其之间的协作，安全（Security）是被排除在外的。随着业务的复杂度以及商业价值的增加，安全问题已然成为企业发展战略的关键组成部分。DevOps中频繁的交付以及其他行为方式的改变事实上已经成了双刃剑，对旧有的SDL这类研发安全管控思想、流程和工具形成了很大的挑战，也让研发安全问题越发不可控。DevOps对传统安全SDL的挑战，目前来看主要体现在如下几个方面。

（1）弱化的设计过程使安全评估难以展开

敏捷时代所倡导的“代码即设计”导致开发人员在设计上花费的时间大大降低。许多DevOps团队更是进一步升级了这个思想，比如硅谷创业家Eric Rise在其著作《精益创业》中提出了“精益创业”（Lean Startup）的理念。其核心思想是，开发产品时先做出一个简单的原型——最小化可行产品（Minimum Viable Product，MVP），然后通过A/B测试等方式收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。如果是失败的尝试，则尽快让它停止。这样会导致两个关键的问题，一个是安全人员要不要/有没有必要参与到其中，另一个是安全人员根本无法参与到设计阶段，无法进行传统的针对设计方案的威胁建模、风险分析和消除等工作。

（2）高速的交付让安全过程无从下手

敏捷模式的研发过程可以将发布降低为1～2周，如果认为这个频次还能够承受的话。DevOps模式下则更加极端，比如亚马逊在整个2014年部署变更了5000万次以上，平均每秒部署2次变更。在这个强度之下，传统的SDL实际上已经无法落地。

（3）云、微服务、容器等技术需要新的安全能力

云技术，特别是基础设施即服务（IaaS）和平台即服务（PaaS）等技术的快速发展，深刻地改变了我们进行系统架构和设计的思维模式。云环境中包含了众多的开发、运维、管控及安全等功能和产品，如账户管理、数据存储、加密和密钥管理、审计、故障处理、监控等服务和API。举个例子，现在很多云都有Serverless服务，如何使用它来评估安全风险和安全责任呢？使用云，就意味着必须接受共享责任模型（SRM）或者一些云服务厂商认为的“责任共担模式”，需要了解云技术供应商和自己的责任范围以及确保云技术供应商是否执行了所要求的安全能力。

微服务是许多成功实施了DevOps的案例中的一部分，亚马逊和NetFlix在围绕微服务构建系统和组织方面取得了巨大成功。但是微服务也有一些缺点，如操作复杂（单个微服务很容易理解，但是它们之间的相互关系和治理可能会超出人的理解能力）、攻击面分析困难（单个的攻击面可能很小，但是整个系统的攻击面可能很大，并且基于操作复杂的问题不容易看清楚）、边界不清晰（相比传统三层结构的Web网站，数据流分析难以应用在微服务架构中，因为不容易确定信任边界）、审计困难（除非使用统一的日志记录和审计机制，否则审计系统中众多的微服务会是一件非常困难和高成本的事情）等。

容器特别是Docker的发展和使用，也是DevOps的一个重要实践，它改变了传统的部署方式，与微服务等更容易结合。但是容器类技术也会带来另外的问题，比如资产识别问题（可能会遗漏，需要从基于OS或虚拟机的粒度增加到容器粒度，但是容器的使用又很灵活，快速的大量创建和销毁会使之成为很大挑战）、安全系统兼容问题（比如一些主机入侵检测系统HIDS可能需要能够支持容器）、引入新的安全风险（如内核溢出、容器逃逸、资源拒绝服务、有漏洞的镜像、泄露密钥等），这都需要使用新的方法来应对，详情请参考第9章。

（4）安全的职责分离原则被挑战

在传统思维中，职责分离（Segregation of Duties，SoD）是一个基本的要求。特别是，审计和合规领域极其关注这一要求。试想一下，一条流水线可以从代码直接通到服务器上去运行，如何平衡这种便利性和安全性？此外，这一点也可以扩展到变更的安全管理上。每天有那么多变更，怎么对这些变更进行有效管理？万一有恶意变更呢？有关变更的安全管理，有个案例可以很好地说明这一情况：骑士资本集团（Knight Capital Group）的一次失败变更使其在45分钟内就亏损了4.6亿美元。最终它因破产而被收购。

诸如此类的挑战，以及SDL本身固有的一些问题（如各个角色信息不对称、孤岛效应、意识不足、配合沟通困难、延误放大等），使得在DevOps潮流之下SDL逐渐变得困难重重。甚至有些悲观的看法认为SDL无法适应DevOps的出现。微软可能也感受到了这一压力，并提出Secure DevOps的概念和实践予以应对。

3. 安全领域更深的思考

传统的SDL类的方式管控了多年，但还是有持续不断的大小公司被入侵和数据泄露等安全事件发生。面对发展势头猛烈的DevOps研发思想和实践，传统的SDL已经渐感力不从心。无数的事实告诉我们一个道理，安全人员的角色不能仅仅是兜底，况且实际情况是根本无法兜底，所以需要引入一个重要的思维变化，即如亚马逊首席技术官Werner Vogels等人所反复讲的那样，安全需要每个工程师的参与。安全不再是安全团队单独的责任，而是整个组织所有人的一致目标和责任，这样才能更好地对研发过程中的安全问题进行管控。这并不是安全团队推脱责任的说辞，实际上这对安全团队的思维方式、组织形式和安全能力建设等提出了更高的要求。想要每个工程师在安全意识和安全能力上都达到专业安全人员的标准是不可能的，因此如何将安全要求和安全能力融合到DevOps过程中来，如何让安全赋能，从而让整个组织既享受DevOps带来的好处，又较好地管控安全风险，变成了一个重要问题。这些思考也导致了DevSecOps思想的诞生以及一系列解决方案的尝试。

1.2.3　DevSecOps的指导原则

1. 安全左移

安全左移（Shift Security Left）是DevSecOps时代非常关键的一个思路转变。传统模式下把所有的安全检查都放在发布之前是根本跟不上DevOps下持续交付的发布速度的，所以需要更多地关注研发流程的“左”边，在更早的环节（设计、编码、测试）进行安全介入和管控。但安全工作必须从工程师的角度出发，制定更加轻量级、可迭代的措施，并以有效、可重复和易于使用的方式实现自动化。这个想法虽好，但并不是那么容易落地，主要原因是安全人员数量并不充足，所以需要让开发和运维人员承担更多的安全责任。这需要安全人员对他们进行更多的安全培训（意识和能力），还有就是提供有效的工具来帮助构建更安全的系统。

这一思想诞生了众多的尝试，比如需求和架构设计中的快速安全评估机制以及简易威胁建模方法论和工具集等。例如PayPal曾在2016年的RSA大会上分享：他们每个团队都必须进行初步的风险评估，并在每一个新应用或微服务开始工作时填写一份自动化的风险调查问卷。又如沉寂多年的源代码安全扫描手段和工具重新被重视，在IDE中做更好的集成以提供更好的体验等。为了更快地开发代码，敏捷或DevOps团队大量使用开源组件、库或框架等代码，根据全球最大的开源组件中央仓库服务提供商Sonatype的研究报告，应用的源码中大约80%的代码是开源的组件、库或框架代码，由此也引发了开源组件安全以及供应链攻击等视角，同时诞生了一些安全工具和解决方案。还有一些人开始重新思考如何更高效地将安全融入到单元测试、集成测试等测试环节。总之，围绕这一原则，已经产生并将继续探索安全的解决方案。

2. 默认安全

默认安全（Secure by Default）这一思维至关重要。拿编码环节来说，持续的快速构建也意味着需要快速地产生代码，而如何快速地产生安全的代码变得越发重要。在开发人员能力短期无法发生质变（或不停地有人力交接、新人加入）的情况下，通过提供默认安全的开发框架或者默认安全的组件可以很好地防止低级错误。比如Web开发人员肯定知道，一些新的开发框架中都内置了一些安全机制或者安全操作库，比如得益于框架内置的anti-CSRF Token安全机制，在一个基于CodeIgniter框架并且打开了该项配置的应用中可能很难找到CSRF漏洞。再比如当使用Go或Rust语言构建系统时，基本上也杜绝了C/C++中常见的缓冲区漏洞及攻击，这是语言特性中默认安全原则的体现。当然，默认安全的原则并不仅限于代码，Web接入层上默认覆盖的WAF、默认安全配置的云/容器/数据库/缓存等基础系统和服务、统一的登录鉴权认证服务、KMS（密钥管理系统）、保护关键数据的票据系统、零信任（Zero Trust）架构等，都是默认安全的很好实践。这也要求安全团队应参与到整个系统架构、基础设施等的建设中，反过来也会要求更多的组织架构保障以及安全与研发团队之间的沟通协作能力。

实践中，与“零信任”等安全思维很相似，默认安全表面上看起来好像很简单，其实背后所需要做的工作却极为复杂。真正想要尽可能地分析系统并且使各个环节做到默认安全，是一件长期和不那么容易的事情。虽然回报巨大，但它要求从根本上改变安全部门与研发部门协同工作的方式，需要两者更紧密地合作起来，一方面增强应用安全和软件设计相关的知识，提升安全编码能力；另一方面要以易用和安全的方式将安全防护措施融入开发框架、模板、系统架构中，并且还要有持续有效的检查和监控机制。此外，研发人员及管理人员需要做出承诺，要把上述默认安全的框架和系统用起来。如果安全不是所有人的一致目标，则很难真正实施默认安全。

3. 运行时安全

运行时安全（Runtime Security）并不是什么新话题，但是在越来越快的发布速度之下，倒逼着安全的考量除了上述的左移和默认安全以外，更加需要特别关注和加强上线后运行时的异常监控和攻击阻断能力的提升，需要有更加及时、快速、自动化的风险监控、发现、阻断、恢复等手段和机制。类似于致力于提升系统整体可用性的各种Monkey（混沌工程），安全机制也需要有类似的机制和能力，重点在识别内外部的安全风险上。

再比如与应用运行时环境嵌入更紧密的运行时应用自我保护（Runtime Application Self-Protection，RASP）技术，虽然也有一些问题，如部署比较麻烦、兼容性问题、性能问题等，但是借助云、容器等成熟的大规模基础设施和技术，通过优化完全有可能提供更优雅、更易于接受和使用的方案，能够带来更快、更精准、更细致入微的安全检查及防护能力。此外，对于很多安全风险来说，情报来源管理和自动化分级分析是第一步，然后才是如何更快地检测，以及如何快速地对问题进行响应。特别是，为了提升安全响应效能，不能仅仅从单点来考虑，还要从全网及整个系统架构层面来考虑，将分散的检测和响应机制整合起来，这也导致了Gartner在2015年提出安全编排、自动化和响应（Security Orchestration, Automation and Response，SOAR）的概念，以更好地完成运行时的风险响应问题。

4. 安全服务自动化/自助化

在DevSecOps中，安全并不是特殊或者拥有某种高权限的存在，与其他所有研发环节和工具一样，不能因为安全而中断DevOps的流程。如果你的安全服务没有实现自动化，那么就无法称为DevSecOps。整个研发流程都在围绕流水线运转，而不应该让研发人员投入过多的精力在安全工具本身。因此，安全团队应该向研发人员提供可使用且易于理解的安全工具，让这些工具自动进行配置和运行，保证这些工具能以合适的方式融入到流水线中，融入各个流程中，成为DevSecOps工具链中的一环，且使用角度跟其他工具没有大的区别。总而言之，须确保安全测试和检查服务能够自动化和自助化，并且提供快速且清晰的反馈。业界有一些研究和尝试，比如漏洞代码自动修复（如MIT的CodePhage、GitHub发布的针对开源漏洞组件自动修复的Dependabot）等技术，虽然目前来看有些成熟度可能还不高，而且存在一些困难，但这些方向绝对是正确的，是一种贯彻DevSecOps思想的尝试。但是这里也要小心陷入另一个误区，我们需要清晰地认识到，如同所有风险类管控一样，信息安全的管控本身一定是层层防御的机制，对于很多以营销为目的的所谓新技术一定要全面了解、多方对比才能做出判断，不太可能指望一个方案就一劳永逸地解决所有安全问题，达到100%安全，这是不切实际的空想！如同软件研发领域的系统可用性没有100%（一般我们说要做到4个或5个9）一样，安全也没有100%。

5. 利用基础设施即代码

基础设施即代码（Infrastructure as Code，IaC）思想和工具是成功构建、实施DevOps的关键之一，安全管控也要积极地利用这些能力。利用它们可以确保大规模场景下配置、环境和系统行为等的一致性，通过版本控制、代码审计、重构、动静态分析、自动测试等手段，采用持续交付流水线来验证和部署基础设施，确保标准化、可审核且使之更安全，减少攻击者发现和利用运维漏洞的机会。在出现安全漏洞或应急事件时，直接使用IaC的一些机制可以快速、安全、可靠地修复漏洞或部署缓解措施。另外，特别要保护这些基础设施，保护持续集成和持续交付流水线等研发流程中的关键系统，避免流水线系统被恶意控制（比如曾爆出的有关SaltStack自动化运维工具的漏洞对业界就造成了不小的影响）。总之，DevOps模式下对于安全保护的要求会更高，因为对攻击者而言至少目标是更加明确了。

6. 利用持续集成和交付

对于安全来讲，从某些角度来说，快速的持续交付也会带来某些“好处”，因此要充分利用这些好处。比如，源代码安全扫描机制有一个很大的局限性问题，就是误报率高，并且在不同场景下误报率不稳定，对于特定的代码误报率更高。从本质上说，更快速的变更意味着每次变更的范围更小且独立性更强，轻量级的变更更容易被理解和检查，所需的测试会更快，错误也会更容易被发现，发现问题时修改起来也更简单。当然，如果代码更加标准化（如代码风格、代码规范、框架及架构等），这一点会更有利。有一些研究结论也表明，对于研发安全领域，轻量而频繁的变更可能让系统变得更安全。

7. 需要组织和文化建设

DevOps与DevSecOps并不像某些ERP软件系统那样，买一套回来部署，然后用起来就解决问题了。DevSecOps体系需要工具链提取痛点（需求）、购买/研发系统并部署、推广使用以及建立度量这样一个正向循环以持续发展，并由一个个业务部门逐步试用摸索经验，然后推广变成整个公司的研发方法论，在这个过程中也需要辅以研发文化的建设。这个过程还需要结合各个公司的实际情况来具体问题具体分析，以一步步解决问题、提升研发效能的方式来制定适合自己的DevSecOps实践方案。比如谷歌会有专门的组织架构及员工角色SRE（Site Reliability Engineering），联合他们的专业安全团队来共同实践DevSecOps。

除了以上原则外，最后还有一点需要留意，就是要特别关注安全建设的衡量和实际效果的评估和改进。安全不是一蹴而就的，要结合内外力量来避免虚假的安全感。一些措施如经常性的红蓝军对抗渗透测试、针对外部安全研究人员的漏洞奖励计划、完善的安全事件复盘等，都是已知的一些不错的实践。

1.2.4　DevSecOps实践

目前DevSecOps实践还处在快速摸索和发展阶段，Gartner在2019年的一篇文章中给出了一个经过调研和分析之后的比较全面的实践清单（在DevOps工具链的基础上增加了Sec工具链实践），如图1-9所示，它由一系列关键路径和持续的关键步骤中的措施和机制组成，周而复始地运转。它的关注点主要是研发过程中的安全漏洞及其引发的各类风险的管控。

1. Plan（需求和设计）

1）偿还安全债务：类似系统研发过程中的技术债务，DevSecOps也会出现安全债务。需要认识到风险并且制定计划逐步偿还，否则早晚有一天会造成严重的安全事故，引起广泛的关注，这时再慌忙应对、紧急挽救，造成的损失将无法挽回。因此，研发团队需要持续评估和跟进以推动安全负债的解决。

2）度量与指标：推进DevSecOps需要良好的度量方式。正确地选用指标和合理地使用度量，可以帮助团队得到持续的反馈，进而得到持续的改进。DevSecOps度量可以从不同维度发现研发流程的瓶颈和验证改进的成果，第8章会进行详细描述和讨论。

3）轻量有效的威胁建模：除了传统意义上的威胁建模方法论和工具以外，快速的安全自查清单、安全知识库等都是一些有益的探索。目的都是将需求和设计的安全评估推上持续构建的快车道，让这个过程不至于变得名存实亡。

4）安全流程和安全工具的使用培训：DevSecOps工具可以帮助团队发现问题，但最终解决安全问题的还是人。对于没有足够的意识和能力进行安全漏洞修补的团队成员，相关的安全工具和安全知识的培训还是非常有必要的。

2. Create（编码/编译）

IDE安全插件：即各类安全漏洞扫描、开源组件版本甚至是代码质量、代码风格检查等工具，可以让研发人员在编码时就发现和消除一些潜在的安全风险。在DevSecOps时代，这些需要大力投入，如果做得好，可以大大减少后续环节的工作量。不过这里也面临着一些挑战，比如针对源码静态分析的误报率问题，再比如某些安全漏洞的准确检测方案极度依赖编译或构建过程等。

3. Verify（测试/验证）

这个阶段的相关应用安全工具需要被集成到流水线中以实现自动化，从而使开发团队不仅不需要承担额外的工作，而且可以快速得到安全测试扫描的结果，从而制定相关策略。

1）静态应用安全测试（Static Application Security Testing，SAST）：是指针对源代码进行静态分析，从中找到安全漏洞的测试方式，有些工具也会依赖于编译过程甚至是二进制文件，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确度。也被称为白盒测试。

2）动态应用安全测试（Dynamic Application Security Testing，DAST）：是指在测试或运行阶段分析应用程序的动态运行状态。在不需要系统源码的情况下，通过模拟黑客行为给应用程序构造特定的输入，分析应用程序的行为和反应，从而确定该应用是否存在某些类型的安全漏洞。也被称为黑盒测试。

3）交互式应用安全测试（Interactive Application Security Testing，IAST）：是由Gartner公司在2012年提出的一种新的应用程序安全测试方案。IAST寻求将外部动态和内部静态分析技术结合起来，以达到上述目标。常见的IAST有代理和插桩两种模式。代理模式是在PC端浏览器或者移动端App设置代理，通过代理拿到功能测试的流量，利用功能测试流量模拟多种漏洞的检测方式。插桩模式（分为主动和被动插桩）是在保证目标程序原有逻辑完整的情况下，在特定的位置插入探针，在应用程序运行时，通过探针获取请求、代码、数据流和控制流等，基于此综合分析和判断漏洞。

4）软件成分分析（Software Composition Analysis，SCA）：越快速的开发意味着开发者要大量地复用成熟的组件、库等代码。便捷的同时也引入了风险，如果引用了一些存在已知漏洞的代码版本该怎么办？这就衍生出了SCA的概念和工具。一些针对第三方开源代码组件/库的低版本漏洞检测工具也被集成到IDE安全插件中，编码的时候只要引入就会有安全提醒，甚至修正引入库的版本来修复漏洞。

4. Preprod（预发布）

1）混沌工程（Chaos Engineering）：这套方法论认为分布式系统中的各种故障和问题都是不可避免的，并且随着复杂度不断提升已经不太可能通过上线之前的测试来发现，但是系统架构要确保在这种情况下依然能够提供持续稳定的服务。混沌工程方法论通过在分布式系统中自动注入各种预设的故障来增强系统可用性，以及自动发现脆弱的环节并改进。在安全方面虽然有一些公开项目比如“Security Monkey”，但也只是一个传统意义上的监控机制，还有待发展。应将异常或自动化攻击测试融入线上系统架构中，从而不断地锤炼以提升系统处理过程中的安全性。

2）Fuzzing：又称为模糊测试（Fuzz Testing），这可能是一种最古老的安全测试技术。通过把自动或半自动生成的随机数据输入一个程序并监控它的异常来判断是否存在安全漏洞，常常被用于文件格式解析、网络协议解析等程序的安全测试中。但是传统的Fuzzing机制实施并不是为了提速，而是为了尽可能地提高代码覆盖，所以速度往往是个很大的问题，导致可能无法适配DevOps。因此如何在DevSecOps之下做Fuzzing是当前一个很好的话题。

3）集成测试：方法类似于SAST、DAST和IAST等，只是测试针对的目标和范围不同。

5. Prevent（预防）

1）完整性检查：完整性检查器可以检测任何关键的系统文件是否已被更改，从而使系统管理员可以查找未经授权的系统更改；也可以检查存储的文件或网络数据包，以确定它们是否已被更改。

2）纵深防御措施：即Defence-in-Depth（DiD），这是一个来源于传统军事理论的内涵极大的词语，在信息安全领域，它假定单个安全措施和机制都会失效或被绕过，所以需要采用分层的方式，使用一个个独立的措施来层层进行防御。这是安全建设领域广泛采用的一种思路。

6. Detect（检测）

1）RASP：即运行时应用自我保护（Runtime Application Self-Protection），被Gartner在2014年列为应用安全领域的关键趋势。不同于传统的应用外的安全措施（如外层的防火墙），它将安全能力像疫苗一样注入到应用程序中并与之融为一体，能够自动化实时监控、检测或阻断实际产生的安全攻击，使应用程序具备自我保护能力。在网络和系统边界日益模糊的今天，使重要的应用本身具备自我安全保护能力这一个方向具有极大的吸引力。它的一些底层技术实现可能会与某些IAST类似，但是该方案带来巨大收益的同时也因为修改了运行时环境的底层，可能会对应用的性能、兼容性和稳定性等造成或多或少的影响，在评估和实现方案时需要重点考虑和应对。

2）UEBA/网络监控：用户和实体行为分析（User and Entity Behavior Analytics）依然是Gartner所创造的安全领域的技术词汇。基于用户以及系统实体在数据层面的异常行为，利用机器学习方法来发现网络安全、IT办公安全、内外部的业务安全等风险，如数据泄露、入侵、内部滥用等安全问题。在安全领域，异常分析是一个最重要的能力，传统方法更多依赖于经验形成的专家规则，在某些时候这种特别有用，但是在另外一些情况下规则又容易被绕过（特征以及阈值设置等）。

3）渗透测试：安全与否不应该靠主观感受，而应该多多借助于背靠背的演习和不断的渗透测试来证实。

7. Respond（响应）

1）安全编排（Security Orchestration）：这一技术定义安全事件分析与自动化响应工作流程。采集各种运营团队关心的安全检测系统数据，对它们进行分析与分类，利用最资深安全分析人员的专家经验，自动化地定义、排序和驱动按标准工作流程执行的安全事件响应活动。安全编排又可以详细定义为安全编排与自动化、安全事件响应平台和威胁情报平台三种技术/工具的融合。这一概念未来还会快速演化和发展，甚至内涵都有可能发生变化，但是都将是致力于解决DevOps下如何快速、准确地响应和预测安全事件。

2）WAF防护：相对于RASP这个新事物，传统的WAF（Web Application Firewall，Web应用防火墙）早已被大量地部署和使用。不同于私有协议的应用，互联网时代Web形态的业务大量存在，而刚好它利用的又是一种公开的通用的HTTP(S)协议，因此WAF应运而生并发挥着重要的作用。它假定应用中肯定有漏洞存在，在这种情况下依然可以阻断实际产生的某些攻击尝试和行为，如入侵服务器、数据拖库、盗取用户信息等。传统的专家规则、前些年的机器学习以及最新的词法语法分析等技术陆续被用于升级WAF系统，以提升覆盖率并降低误报率。另外除了应对传统的Web漏洞攻击、CC攻击以外，WAF也逐渐发掘出了反爬虫、打击羊毛党等的场景，将安全能力从漏洞防护扩展到了业务安全领域。

8. Predict（预测）

1）漏洞相关性分析：属于软件漏洞管理，也被称为Application Vulnerability Correlation（AVC）。漏洞的发现肯定无法依靠单一的一种工具和方式，而是会由上文的SAST、DAST、IAST、RASP以及人工渗透测试等各种各样的手段和工具来完成。但这也会产生新问题，比如这些方式和工具存在重复扫描、难以协同等问题。在这种情况下，就催生出了AVC方案。理想中的AVC方案可以管理所有安全工具，通过标准化数据格式等方式使它们之间更高效地协作，以此更高效地发现和管理所有环节的漏洞。

2）威胁情报：按Gartner在2013年的定义，威胁情报（Threat Intelligence）是基于证据的知识，包括场景、机制、标示、含义和可操作的建议。这些知识是关于现存的或者是即将出现的针对资产的威胁或危险的，可为响应相关威胁或危险提供决策信息。其中关键的信息就是失陷标示（Indicators of Compromise），如攻击行动所使用的木马名称、文件指纹、进程信息、恶意域名、C&C服务器IP等。

除此之外，伴随整个流程，通过对系统内外行为、日志、RASP系统监控到的异常、API网关、性能日志、安全事件等的持续监控和分析，完成闭环，不断地复盘改进，从而自我完善，持续提升安全风险管控能力。