DevSecOps详解及案例分享

前言

绝大部分的网络攻击事件都会伴随着对系统、软件当中漏洞的利用；因此，可以说软件开发者身处网络安全的斗争前线，也毫不为过。然而，现实来看，由于过去对网络安全的忽视，造成软件开发人员安全意识的缺乏，使得我们的软件中总是存在着大量的漏洞——甚至是一些极其轻易就能被利用却产生严重后果的漏洞。

另一方面，互联网业务也在高速发展，各大企业都期望从这大流量的趋势中，高速发展自己的业务——这就对软件开发效率又产生了极高的要求。从最早的瀑布流开发模式，到为了顺应时刻变化的需求的敏捷开发模式，再到如今通过运营反馈再高速迭代产品DevOps开发模式，开发速度在不断提升——尽管安全问题始终在这些模型当中，经常只是处于“被提及”的位置。

如果缺乏安全管控，迭代速度的增加以及频繁的配置变更反而会大量增加企业的业务风险；随着近年来各个国家对网络安全的重视提升，各类合规的要求也在越发完善——安全在软件开发中就显得举足轻重。软件开发安全生命周期开始将安全进行了“左移”：在越早期将安全融入软件开发之中，软件产生的问题、以及问题造成的影响就越有限；而在去年新思科技的BSIMM11的报告中，就开始提及不仅在“安全左移”，更是“安全无处不移”的观点。

但是，无论是“安全左移”，还是“安全无处不移”，“开发”和“安全”似乎依然是割裂的。DevOps理念中，需要开发和运营相互结合，从而基于需求和应用反馈快速迭代——既然如此，关键的安全为何不能融入这个体系中呢？DevSecOps自然就在这样的形势下应运而生：将安全与开发、运营融合，让DevOps部门（也就是现在的DevSecOps部门）贯彻安全开发的流程，自己在开发过程中发现漏洞、修复漏洞，而不再依赖于安全部门进行；从而在快速迭代开发中确保安全的同时，减少因跨部门沟通产生的各种矛盾。

需要注意的是，DevSecOps是从软件开发方角度的理念，并非是安全供应商的“产品”。安全供应商的价值，在于为自己甲方提供DevSecOps落地过程中的安全经验、安全产品。本报告并非完全从软件开发方角度出发，为软件开发方的DevSecOps落地进行指导；而是从DevSecOps工具角度出发，为软件开发方在DevSecOps落地中对相关安全工具的选购，提供一些建议。

关键发现

• 安全不仅需要左移，更需要“平铺”；正如DevOps中的持续集成与持续交付（CI/CD），还需要持续安全（Continuous Security）。
• DevSecOps基于DevOps，但是DevOps开发模式并非对所有场景都是最优解；传统的瀑布流开发模式以及敏捷开发模式依然会大量并行存在。企业在进行相关产品产品的选购时，先要与业务、开发部门等沟通，选择最适合自己的开发模式，再决定选择DevSecOps产品，或者是其他软件开发安全产品。
• 传统的软件开发安全工具都能在DevSecOps中有自己的价值——但是由于DevSecOps本身有DevOps平台作为基础，传统的软件开发安全工具能否在不同环境中接入各类DevOps平台，是考验DevSecOps工具供应商的一大挑战。
• 当前采用DevSecOps的客户可以分为三种类型： • 自身已经基本完成DevOps转型，需要加入安全元素，完成DevSecOps； • 原有的瀑布开发或者敏捷开发模式中已经通过安全开发工具赋能，在向DevOps转型的过程中，将安全并行，完成DevSecOps； • 原有的瀑布开发或者敏捷开发模式中安全能力不足，准备向DevOps转型的同时，建立安全文化，融入安全能力，直接完成DevSecOps建设。
• DevSecOps需要软件开发方自上而下进行推动，是将安全融入开发运营体系之中，缺乏合适的管理和流程制度，最终依然是DevOps Security，而不是DevSecOps。
• 从当前来看，将相关DevSecOps工具接入DevOps平台是主流；但是未来来看，DevOps平台会逐渐升级成为DevSecOps平台——可能是DevOps平台侧加强安全工具的能力，也可能是安全厂商侧基于开发安全平台赋予软件开发能力。

▶ DevSecOps理念

从瀑布开发到DevSecOps

瀑布开发模式最早起源于工业生产，由于一个项目一个阶段接一个阶段往下发展，像瀑布一样而得名。瀑布开发模式在上世纪很长一段时间内作为几乎唯一的IT项目开发模式。就像其名字一样，瀑布开发模式需要将项目按阶段推进；因此，瀑布开发模式需要每一个阶段的目标都在开发之初就被详细定义，然后当一个阶段彻底完成后，才能进入下一阶段。从概念上来看，将每一个阶段都实现，那么最后项目的成果必然是完美的。

但是瀑布开发模式有着很明显的缺点——就是项目前期必须将每一阶段都完整定义才能推动整个开发；同时进入下一个阶段以后，很难对之前的阶段产生的问题进行修改。然而，在现实当中，往往会有大量的需求改变情况——这和瀑布开发模式需要明确项目目标的情况相悖。因此，当瀑布开发模式遇上需求变化多的场景时，效率会非常低下。

这个情况下，敏捷开发模式就出现了。敏捷模式强调的是快速的反复迭代，以应变复杂的需求变化。通过小组化的开发方式，加速完成项目开发。

敏捷开发模式极大地解决了瀑布开发模式中难以应对的需求变化，以及开发后期出现的问题很难解决的问题。但是，无论是瀑布开发模式还是敏捷开发模式，其核心都依然是在软件的功能都否实现的基础上——而企业的最终目的是盈利，也就是业务能否按期望的，甚至高于期望的方式运作。这就需要开发团队和业务团队等更紧密的结合，要求产品的迭代不仅仅基于功能，更要基于业务需求。

于是，DevOps就成了新的解决问题的钥匙。一方面在文化和制度上，将业务和开发团队结合，分为计划、编码、构建、测试、发布、部署、运营、监控八个步骤的闭环，基于业务需求与反馈，更加频繁、快捷地对软件设计进行修改升级；另一方面在技术上，通过自动化能力，实现持续集成、持续交付（CI/CD）。

即使是传统的瀑布流开发模式，安全也始终都是需要考虑的因素之一。“安全左移”的理念要求让安全更早地进入开发流程，从而为整个软件定下安全的基础，减少后期因为修复安全问题产生的成本。DevOps模式同样需要安全，在将开发团队和业务团队等结合的同时，也需要加入安全的因素，DevSecOps就应运而生。

DevSecOps的价值

根据Gartner的定义，DevSecOps是指将安全尽可能无缝、无感知地集成进IT和DevOps开发当中；在不减少敏捷度和开发者效率，或者要求开发者离开现有工具链环境的情况下，达成这个目标。

数世咨询认为，DevSecOps的关键点在于“无缝”、“无感知”上，同时要求安全因素对开发环境的影响要尽量小，甚至没有影响。尽管“安全左移”确实地将安全在尽可能早的阶段加入到软件开发进程当中，但是安全与开发依然属于分裂的情况。开发人员很多时候依然处于“安全并非重要”的状态下，从而在开发过程中忽略安全性，将安全交给安全部门人员去完成，反而产生了跨部门沟通的问题。

在敏捷开发，甚至DevOps模式下，快速迭代与持续交付标志着开发速度会变得更快，修改与产出也会更加频繁。频繁的变化往往会带来更多的安全隐患。DevSecOps制度与环境的建立，能让安全元素融入到整个开发环境当中，不只是左移，而是将安全贯穿整个开发进程。不仅仅是持续集成和持续交付（CI/CD），更需要做到“持续安全（Continuous Security，CS）”。

另外，提升开发人员的安全意识和安全开发能力固然是一项重要的工作，但是安全本身也确实会减缓开发的速度，因此“无缝”、“无感知”能让开发人员更容易接受安全文化、安全工具的加入。

因此，DevSecOps的关键价值，就是在不影响企业开发效率的情况下，将安全融入到现有DevOps的开发流程当中，“安全”与“业务”两手抓。

DevSecOps的误区

尽管说DevSecOps开发模式能在确保开发效率的同时，融入安全，使得开发出的软件、应用更加安全可靠，但是在DevSecOps的落地层面，有两个误区需要注意。

DevSecOps并非总是最优选择

这几年来，DevSecOps屡屡被提及，“DevSecOps”作为热词被很多安全人员，甚至IT人员所津津乐道。但是，DevSecOps并非总是最优选择。

DevSecOps从DevOps演化而来，强调将安全融入了DevOps的开发模式中。因此，DevSecOps无论是从开发理念、文化，还是从技术架构角度，都是基于了DevOps模式。

虽然从上文来看，DevSecOps是为了解决瀑布开发模式和敏捷开发模式中产生的弊端演化而来，但是三种开发模式实际上是各有所长：

• 瀑布开发：尽管瀑布开发面对需求改变频繁的情况会相当低效。但是反而言之，当开发项目庞大，开发目标和各阶段任务明确的时候，瀑布模式依然是非常有效的模式。
• 敏捷开发：敏捷开发强调了小团队的快速开发，快速迭代，适用于针对快速推出成品，实现功能的场景。
• DevOps：DevOps的核心在于将开发和运营相结合，最终实现的不只是产品的功能性，而是业务的实用性。通过开发和运营之间的闭环，基于新的信息，持续交付。

因此，尽管说DevSecOps是近年来讨论比较多的开发模式，但是企业依然需要根据自身的环境、不同项目的特性，选择最合适的开发模式，传统的瀑布开发、敏捷开发以及软件安全开发生命周期依然适用。

DevSecOps并非DevOps Sec

DevSecOps需要做的是将安全尽量“无缝”、“无感知”地融入到开发体系当中，正如Gartner对DevSecOps的图解一样，安全是在每一环节当中都存在的——而非依然作为孤岛存在。DevSecOps是将安全能力融入到DevOps中，而不是将安全人员融入到DevOps中。

如果只是单纯地认为在DevOps架构之中，再加入安全工具，以及安全工具的集成平台、管控平台，那显然是不足的。只是在技术环境中加入安全技术，如果无法在流程当中将安全融入，或者依然需要大量依赖于安全人员解决相关的安全问题（尤其是开发阶段），那么安全依然是独立于DevOps流程之外的元素，成为了DevOps Sec，而非DevSecOps。

DevSecOps应该将安全人力从开发流程当中解放出来。安全人员可能需要在某些特定的时点介入，形成安全规范或者进行安全工作——如项目的安全需求、软件的渗透测试等；而在更多的时候，通过提前配置的规则，让安全能够自动化地在开发流程当中赋能。在提高开发和运营人员的安全意识与安全能力后，通过简单易用的安全工具，让安全成为流程的一部分，而非额外的行为。

DevSecOps对安全开发的反思

如果完全贯彻DevSecOps的理念与方式，安全就可以在整个软件的开发过程中得到保障。但是，正如上文提到的那样，DevOps并非总是软件开发流程的最优解——那么如果使用瀑布式开发与敏捷开发模式，安全是否就会不如DevSecOps那样行之有效？

数世咨询认为，并非如此。即使企业不适用DevOps作为开发方式，依然可以借鉴DevSecOps的一些安全理念，融入到自身的开发流程当中：

持续安全

为了将安全尽早融入开发当中，“安全左移”成为了关注点。通过“安全左移”，企业能够最早在项目建立的时候，就考虑到相关的安全需求、合规因素，从而定下整个项目的安全标准。然而，安全是一个持续性的过程。虽然说“安全左移”是因为传统意义上安全作为附加因素带来的改革，但是随着开发脚步的变快，尤其是在敏捷开发中的快速迭代要求下，传统的“右侧”安全也需要进一步的提升。正如DevSecOps将安全融入到DevOps的每一个环节一样，持续安全的概念也应该渗入瀑布式开发和敏捷开发当中。

无感知安全

一旦安全的存在感过于突出，反而容易形成“安全孤岛”——开发人员会认为相关的漏洞、后果是安全人员需要解决的问题，从而将大量冗余的工作转移给了安全人员，“安全”在开发中成为了独立的存在因素。“开发”与“安全”之间的分割，不仅造成了沟通的困难，导致项目进度减缓，更可能使得最终项目的安全性大大降低。事实上，如果安全成为了孤岛，即使将安全因素在早期阶段植入到了项目中，在实现层面，安全依然是每个阶段的“附加”属性。

安全如果能够无感知，就能在开发流程中让开发人员本身实现大部分的安全需求，同时减少因沟通产生的矛盾，极大提升开发效率。通过使开发安全工具变得易用，让开发人员自己可以快速解决各种开发环境中存在的问题，最终最小化安全对开发产生的影响。

安全文化

安全文化并非DevSecOps的专属。事实上，从“安全左移”就已经开始将安全文化融入开发流程当中。无论是“持续安全”，还是“无感知安全”，本质上都是通过技术、流程等外在因素，形成在一个安全意识缺乏的情况下的安全开发环境。但是，DevSecOps的关键在于安全文化的建立——需要从开发到运营的人都自发、自愿地将安全结合到项目中，将安全作为一种日常存在。

只有形成了将安全作为日常的文化，才能让安全融入到开发的各个环节，才能做到持续安全。

▶ DevSecOps工具关键能力

DevSecOps安全工具

根据Gartner的相关报告，如果只是从工具的价值实现角度来看，DevSecOps工具和传统的开发安全工具、以及应用安全工具基本可以互通。原有的开发安全工具以及应用安全相关工具依然可以在DevSecOps当中得到应用。

从数世咨询来看，以下DevSecOps工具当下值得关注：

• 安全需求分析：在安全领域，攻防的区别在于攻击者只需要找到一个攻击点就可以成功，而防御者必须防范大部分区域。在一个软件开发项目中，开发人员，甚至是安全人员本身，都可能由于缺乏对整体项目的把控，对安全的要求、基线、相关合规情况都不够了解。这就需要安全需求分析从整体上对软件项目的合规标准、潜在威胁等方面进行一个总体的评估与分析，建立相关安全要求，制定明确的安全规范。除了通过咨询的方式，进行安全需求分析，搭建威胁模型之外，对于一些不是特别复杂的软件开发项目，也有模板可以直接使用。
• 安全测试：安全测试是确保开发软件最终是否安全可靠的关键部分。当安全测试从传统软件开发模式变化到DevSecOps模式的时候，需要考虑到和CI/CD的集成，因此测试工具的集成能力与自动化能力就尤为重要。另一方面，由于DevSecOps追求的高效性，安全测试的速度也会成为影响整体开发效率的因素。现在的安全测试主要有以下三种类型： • SAST：静态应用安全测试又称白盒测试，是指在不运行程序本身的情况下，仅通过分析程序的语法、结构、过程、接口等来检测程序的安全性。一般可用于DevOps流程的编码、构建与测试环节。 优势：代码检查更具有可视性、能精确定位到漏洞位置 劣势：误报率高、对集成系统中产生的漏洞难以检测 • DAST：动态应用安全测试又称黑盒测试，在无需了解程序源代码与逻辑结构的情况下，对程序进行安全测试。一般可用于DevOps流程的测试与发布环节。 优势：攻击者视角测试更贴近现实情况、无需源代码 劣势：覆盖面较小、一定程度依赖人员安全能力、无法定位漏洞具体位置 • IAST：交互式应用安全测试又称灰盒测试，结合了SAST和DAST技术的优点，能够模拟验证代码中的已知漏洞是否确实能够在运行的环境中被攻击者使用。通过部署探针或者流量监测等方式，持续分析程序测试时的实时数据，发现程序中存在的漏洞。 优势：易于集成CI/CD、低误报高检出、低安全专家投入 劣势：插桩模式难以检测业务逻辑漏洞、流量模式的数据容易被污染降低检测效果

三种安全测试分别有其优劣势，尽管说当下IAST热度最高，而且从使用特性来看也最为适合DevSecOps场景，但是SAST与DAST依然在DevSecOps有很高的安全价值。

• 模糊测试：模糊测试是一种介于手工渗透测试与完全自动化测试之间的安全性测试。通过将准备好的随机或者半随机生成的数据输入程序，通过监视程序的异常状态，发现潜在漏洞。
• 软件成分分析（SCA）：开源软件的兴起大大提升了开发者的开发速度。尤其是近年来，越来越多的企业对开源软件采取了开放的态度，软件项目中超过一半的代码都来自于开源组件。但是，开源软件依然有着大量的安全隐患，从“心脏滴血”到Equifax的数据泄露，其中都有开源软件供应链的因素。因此，在整个开发过程中，软件成分的分析就尤为重要。企业需要首先明确自己的软件项目中都有哪些开源组件，然后才能进一步指导这些开源组件是否还在被维护、当前版本是否存在漏洞等问题。可以说，软件成分分析是当前软件开发安全中不可或缺的能力。
• 运行时应用自保护（RASP）：DevOps的一大关键是将开发和运营结合到了一起，因此当进入DevSecOps的时候，需要关注的不再只是开发安全，还需要考虑到程序上线以后的运营安全。RASP的概念最早在2012年由Gartner提出，通过将安全能力内置到应用自身，通过程序的上下文，判断威胁并采取措施。传统的WAF只能从边界对应用程序进行防护，但是无法知晓边界内部的情况，同时因为WAF的规则配置等问题，容易引起大量误报，RASP的加入则可以补足这些缺陷。但是，RASP也会存在一些问题，比如由于直接内置于程序，或者于程序直接关联，因此可能会影响程序的性能。RASP依然是在逐渐成熟的技术，从应用防护层面来看，值得持续关注。
• 安全工具集成中心：尽管说最好的DevSecOps是在确保安全的基础上，尽可能减少安全，以及安全人员在开发和运营过程中的存在感，但是当前来看显然还有很长一段路要走。事实上，以企业的转型角度来看，从之前的瀑布式开发模式或者敏捷开发模式，转向DevOps开发模式，在技术架构上已经实属不易；将安全工具迁移到新的环境，更是一项艰巨的任务。因此，虽然无缝、无感知的安全是DevSecOps的目标，在实现过程中显然无法一蹴而就。那么，目前来看，就需要一个安全工具的集成中心，能融入到CI/CD管道中，协助开发人员管理和使用相关的安全工具，而不是在大量“额外”的安全工具中手足无措。

DevSecOps安全工具的关键能力

虽然DevSecOps中的安全工具很多，但是从这些工具的本质来看，都需要有以下三个关键能力，才能成为DevSecOps中的一部分。

集成能力

安全工具首先要能融入DevOps环境，才有机会形成DevSecOps。不同的企业会使用不用的DevOps环境，尤其对于一些大型企业，其开发环境会更为复杂。安全工具如果不能集成到客户所需要的环境下，那么就无法真正融入DevOps开发流程，使用也就无从谈起。这是当前从瀑布开发和敏捷开发向DevSecOps转型中，传统的开发安全工具同样需要转型的一步；但是，在未来，随着DevOps的使用方增多、DevOps环境本身的集成能力与兼容能力增强、以及安全厂商对安全工具的反复打磨，这一点的影响力将逐渐减小。

自动化能力

在DevOps流程中，自动化能力尤为关键。CI/CD的实现本身离不开强大的自动化能力，而如果安全能力需要融入到CI/CD当中，就必然需要有同等级别的自动化能力作为支撑。过于依赖人工的安全工具，不仅会大大提高人员的安全能力要求，使得安全专家的投入增加，还容易严重减缓整个DevOps的开发效率，造成开发、运营人员对安全的抵触情绪。自动化能力是使安全“无缝”、“无感知”的基础。

业务结合能力

除了技术环境之外，不同行业的开发安全需求也不一样，尤其在合规需求方面。如果在软件开发的设计之初就需要将安全因素融入，那么一定需要对相关行业的合规要求，以及相关软件面临的主要威胁的深入理解和研究才能达成。安全厂商在相关行业、领域的积累，能够创建最贴合客户自身情况的威胁模型，从而对整体的开发安全性进行分析与建设；尤其对于一些提供安全开发模板的厂商，在相关行业里的积累越是丰富，其给出的模板就贴近安全的需求。

易用性

“自动化”是安全工具能否在流程上融入DevOps的关键，但是具体最后的使用效果，还需要工具的易用性。现在安全厂商大部分的DevSecOps工具都主要集中在开发侧，对软件中存在的漏洞进行检测；而在DevOps的闭环当中，还需要兼顾到运营侧的使用，才能做到持续安全的效果。由于开发人员、运营人员、以及企业中相关的业务方才是最终产品上线与使用中的直接利益方，他们更需要对软件有直接的管理——因此管理、使用中的安全就值得关注。

尽管DevSecOps的团队中也需要安全专家进行协同，但不是企业专门为DevSecOps配置一个完整、专业的安全团队——安全的赋能不是靠安全人员的堆砌实现。因此，DevSecOps模式中，非安全人员能否使用安全工具，即安全工具对非安全人员能否易用，就成了最终DevSecOps中安全能否落地的关键。

▶ DevSecOps实践案例

由于DevSecOps是开发方的概念，在本报告的案例中，我们选取了其中两家DevSecOps的实践方，和他们进行了沟通，学习了他们自身DevSecOps的落地实践，以及相关厂商的安全工具对他们DevSecOps的落地。

案例一：某互联网金融公司A实践案例（本案例由悬镜安全支撑）

场景介绍

某互联网金融公司A成立于2006年，获得中国人民银行颁发的《支付业务许可证》，以支付为核心，提供理财，购物、生活、信贷、航旅等多样化场景的金融理财与消费支付服务，为企业客户提供完善综合的支付解决方案。由于兼具一定的互联网属性，A公司需要在业务发展的过程中，对自身的业务系统、应用程序进行快速迭代。在这样的环境下，A公司在三年前决定使用DevOps的开发模式，加速自身的开发流程。

在之前开发模式下，由安全部门发现漏洞并提出修复。但是由于安全和研发是跨部门沟通，开发部门未必愿意接受修复意见；并且在企业快速发展的背景下，各部门都有自己的业绩压力，开发部门更容易将安全意见理解为一个业务层面的需求，从而对这个需求进行反驳和挑战。为了将安全融入快速迭代的开发模式，减少安全与业务、研发的摩擦，A公司引入了DevSecOps模式，并成功落地。

DevSecOps落地实践

A公司认为，DevSecOps的成功实践有四个核心元素：有效的文档、好用的工具、强大的自动化能力、以及人性化的安全意识培训。

A公司在DevSecOps文档上的实践可以分为以下三个步骤：

• “自上而下”统一安全观念：企业一般的业务流程，是由业务部门提出需求，产品人员基于需求做出相关设计，再和研发进行沟通做出成品。因此，当安全融入到这个流程中时，A公司选择先和业务部门沟通，明确安全合规要求以及安全隐患对业务的影响；再通过基于安全的业务需求，和产品部门沟通安全设计——在业务部门和产品部门都接受了安全的融合后，研发和运维也就自然能推动安全的落地。
• 因此，在A公司的DevSecOps落地过程中，不仅仅是企业管理结构的“自上而下”的推动，更是企业自身内部业务流程上下游之间的“自上而下”推动。
• 提出规范：在确定将安全融入开发流程后，需要制定相应的规范：具体哪些代码是违规的、哪些漏洞是需要修复的、开发的程序都应该遵守哪些规范等等。没有相对应的规范，修复行为就会显得很唐突，无据可依。因此，企业的安全规范不仅需要制定，更要确保让业务、产品和研发部门知晓，并严格遵守。
• 安全工作责任化：在确定规范后，需要将不同职位的工作责任化，确定业务、产品、研发需要履行的安全责任，确保出现安全问题后，能够追溯到责任方。同时，将工作职责文档化输出，根据不同职位的具体工作内容和业务场景，简洁、扼要地明确各职位需要完成的安全要点。

漏洞需要尽早修复，事后修复会产生更高的成本。如果修复工作直接交由运维进行，由于运维人员本身并不理解底层架构或者业务逻辑，可能在修复部分漏洞时，影响到其他相关系统，对业务产生负面的效果。因此，漏洞的修复最好由研发按照产品的逻辑，自行去采取相关的措施——这就需要有好用、方便的工具，协助研发检测漏洞并修复。

另一方面，来自安全厂商的相关安全工具还应该兼具一定的“合规情报”能力——即安全工具本身不仅能对漏洞严重程度、业务的影响状况进行优先级的评估，更需要综合最新的法律法规要求、监管机构指示等信息，对漏洞的严重性以及修复优先级提出建议。

独立的安全意识培训视频或者课程依然是安全的另一个“孤岛”，企业员工在接受培训或者听课的时候缺乏对风险的直观感受。在A公司建立DevSecOps文化的过程中，尝试将相关的安全意识培训项目和自身的业务场景相结合，在整个DevSecOps流程中植入相关课程和测试，让相关人员在工作情境下直接培养安全意识，从而形成对风险更加具象的认知。

有效的文档、好用的工具、人性化的安全意识培训、以及与DevOps一脉传承而来的自动化能力，是A公司对DevSecOps落地的重要经验。

厂商价值

A公司当前在DevSecOps流程中使用了白盒、黑盒、以及灰盒的安全测试工具。其中，灰盒检测工具使用的是悬镜安全的灵脉IAST产品。

在A公司最初选择检测工具时，首先尝试了白盒测试。通过自动化能力，白盒测试能在晚上下班时间的工作间隙自动进行；实现夜间检测，白天生成报告。但是，A公司在白盒测试的使用过程中，发现了相当高的误报率；由于依赖研发人员修复，这大大减缓了开发速度和研发人员的工作效率。尽管A公司在这个过程中针对高误报率进行了多次小组讨论，根据误报率的情况整理分析高误报漏洞的类型、必须修理的漏洞类型、以及需要重点关注的漏洞。由于始终无法达到满意的效果，所以A公司需要更高效的检测工具。

A公司之后尝试了黑盒测试工具。黑盒测试通常依赖于爬虫寻找测试点，由于难以遍历所有的逻辑路径，导致漏报率过高。同时，黑盒测试工具的链接爬取时间过长，造成敏捷性不足，无法融入整个DevOps体系中，效果依然不佳。

在经过多次讨论和分析后，A公司基于高检出、低误报的特性，决定开始尝试灰盒检测工具。在灰盒工具的使用中，A公司考虑的是灰盒工具能否和现有平台对接、能否达到验证效果，最终消除人工介入，实现全自动敏捷安全保障过程。

工具和平台的对接不仅仅是能否兼容，能否融入CI/CD管道这样简单，还有一些可用性的细节，比如程序的“性能熔断机制”——当检测工具占用CPU使用率过高，会影响测试环境，乃至整个开发环境的时候，是否能自我终结进程，确保整个平台的稳定？灰盒的检测工具使用方式，以及工作流的融合是否能让不同职能的人都接受，不影响他们的工作进程？

另一方面，如果工具检测出的漏洞数量超过质量红线的要求，那产品必然不能上线，会被要求修复。然而，传统的安全测试产品误报率比较高，这使得从表面的检测结果看，质量红线不断被突破，但实质上排除了误报后的检测 结果可能是合格的。因此，安全人员不得不花费大量的精力去排查漏洞的真实性，这会大幅降低应用生产效率。A公司基于这个问题，提出的需求是：在某些具体场景下，必须零误报。

在以上需求下，悬镜安全和A公司的安全人员一起，与A公司的业务、产品、研发人员进行沟通交流。在IAST产品的实践过程中，不仅根据A公司的业务需求，基本实现了特定场景下，零误报的目标，同时兼顾了各职能在细节层面的需求。悬镜安全根据A公司自身开发体系，将灵脉IAST检测工具与现有的工具链结合，协助客户构建完善、统一、可跟踪、可度量的敏捷开发安全体系。使得研发和测试人员在完成应用功能测试的同时，即可透明实现深度业务安全测试，有效覆盖90%以上的中高危漏洞，防止应用带病上线。在软件自动化测试方面，灰盒测试工具的落地帮助A公司完成了一块关键的拼图。

客户评价

在安全赋能到不同岗位的时候，员工就会感到自己有职责做好安全工作。当技术人员愿意使用DevSecOps产品，并且他们用得顺手的情况下，自然就能建立企业的安全文化。因此，安全厂商不应该只考虑安全能力，更应该帮助企业考虑如何把安全能力落地。在我们公司的场景下，悬镜安全愿意和各个部门主动沟通交流，形成合作，协助提升人员的安全意识，并在细节上不断完善，最终实现了灰盒测试工具在我们DevSecOps环境中的落地。在未来，我们会和悬镜安全探讨并进行更多的合作。

光大银行总行DevSecOps落地实践（本案例由奇安信提供）

场景介绍

近几年，金融业数字化转型，光大银行作为全国性股份制商业银行之一，业务不断寻求创新。而随着微服务、容器等新技术的应用，IT基础架构发生了巨大的变化，交付模式也迎来巨大变迁，因此，光大银行从传统的瀑布式开发模式向DevOps敏捷开发和持续交付模式迁移。而为了适应新的开发运营一体化场景， 光大银行同步推进DevSecOps安全体系，并探索最佳落地实践。

DevSecOps实践

光大银行于2019年底开始DevSecOps的落地实践，从传统的瀑布流开发模式向DevOps模式进行迁移。鉴于两种开发模式之间的差异，同时需要从银行整体IT发展情况考虑，光大银行选择了数个项目作为试点项目，对DevOps开发模式进行尝试。

从光大银行角度来看，软件开发是一个全过程的体系，而安全也是一个全过程的体系——因此每一步都需要有安全措施，开发的每一步都应该有安全性。因此，无论是传统开发模式，还是敏捷的开发模式，或者到DevOps的模式下，安全都是不可缺少的，只是不同模式中安全的落地方式可能有区别——因此，DevOps到DevSecOps是一个自然而然的过程。

而在实践过程中，除了在流程层面面临传统开发模式到更灵活的开发模式的转变外，同时在技术层面，由于技术栈的高复杂性，也需要厂商协助，将各种工具的链路打通，融入CI/CD管道，并且对安全工具进行统一的管理。尤其对于光大银行而言，如何融入现有的流程和体系，是需要考虑的问题。

厂商价值

奇安信现阶段为光大银行提供的DevSecOps工具可以分为两个部分：源代码安全以及开源软件安全。

源代码安全方面，通过源代码安全云测平台，将代码卫士等多个源代码扫描工具集成到统一的管理中台，平台应采用“分布部署，集中管理”方式，通过统一的Web管理界面直观显示源代码安全扫描情况。使用者可以通过Web界面发起源代码检测任务，同时也可以通过配置检测策略实现自动化周期性发起源代码检测任务，以及查看、审计、生成报告。

在部署层面，通过接口将源代码检测工具集成到光大银行现有CI/CD系统，在现有DevOps流水线中实现自动化源代码扫描；与行内代码版本管理系统SVN进行集成，自动获取代码并进行源代码检测；与行内缺陷跟踪系统，将源代码检测结果导入到缺陷跟踪系统中；并将代码扫描工具与光大银行统一认证系统对接，进行统一登录，在对现有系统最小影响的情况下实现DevSecOps落地。

图 代码安全云测试平台

由于开源软件的发展，光大银行现有的代码中更多成分是由开源软件组成的，因此开源软件安全在开发过程中尤为重要。尤其是近年来开源成为趋势，因此管理方面由之前的白名单策略转向黑名单策略，但是管理颗粒度依然有限；由于缺少开发框架，对开源组件的治理较为匮乏，只能靠流程控制，无法从技术手段评估开源内容。

奇安信在光大银行开发测试私有云中部署一套本地化的开源卫士系统，将企业端管理平台、管理端分析中心以及后台知识库分布式部署。基于该系统，光大银行建立了项目-组件-漏洞之间的关联关系以及开源软件安全漏洞情报机制，实现在开源软件漏洞公开的初期掌握最新的漏洞情报和影响范围，极大提高了开源软件的风险排查及响应速度。此外，光大银行基于商业软件搭建了专门的制品库管理系统，对制品库中的开源软件定期扫描，并建立黑白名单管控机制，要求开源组件引入前必须经过相关部门安全审查评估和备案。

在DevSecOps落地场景中，开源检测对接光大银行CI/CD系统，在光大现有的DevOps流水线中建立开源组件自动化扫描能力，让开源卫士无缝融入到行内现有的研发流程中，实现日常开发自动化检测。

图 开源软件安全治理体系

客户评价

在传统瀑布式开发模式向Devops转型过程中，奇安信协助我行引入了源代码审计和开源软件治理工具，综合考虑了我行研发流程、开发测试工具链，在DevOps的基础上加入了安全工具链，实现了我行Devsecops的能力整合，将安全能力从原来的上线阶段提前到了开发阶段，提前发现问题，降低修复成本，实现了安全的左移。

案例三：某大型制造企业C案例（本案例由默安科技提供）

场景介绍

企业C是制造业进行数字化转型的典范，积极开展高新技术研究和产业化探索，在《2020中国企业500强》和2020年《财富》世界500强排行榜中的排名十分靠前。在加快业务转型升级的同时，如何确保数字化业务系统的安全性是该企业实现快速发展的当务之急。

客户DevSecOps需求

企业C开发项目很多，但是开发质量参差不齐，许多业务上线后发现存在各类安全漏洞。不但开发人员耗费大量时间和精力进行修复，同时业务系统被攻击的安全风险还可能影响正常的对外服务，造成企业名誉受损和经济损失。

企业C需要能在快速开发的节奏下防范安全事件的发生，减少系统上线前的应用安全漏洞、降低漏洞修复成本。企业C规划建设完整的开发安全体系，并且要求安全工具能与Jenkins、Jira等平台无缝集成，实现高效测试。同时，建立并实行开发人员能力培养计划，从根源上减少应用安全风险。

厂商解决方案

默安科技根据企业C的开发项目管理体系，将自身的SAST、IAST检测工具与现有的工具链整合，协助客户制定和完善开发过程中的相关流程与规范，辅以安全培训提升人员安全开发能力，构建完善、统一、可跟踪、可度量的开发安全体系。

•开发安全过程管理流程：默安科技围绕企业C某信息系统的标注与认证、访问控制、会话管理、日志管理、安全审计、文件资源等安全需求进行设计，分析可能存在的安全风险并提供应对措施，完善安全需求设计。

此外，结合该企业内部的人员培养体系，提供安全测试规范手册，为安全测试人员提供测试指导。安全测试人员通过查阅该指南可快速掌握Web、iOS客户端、Android客户端安全测试，提升安全开发意识，提高开发效率。

• 安全工具的集成：默安科技根据企业C现有的Jenkins开发管理流程，将自身的SAST与IAST整合到现有工具链中，完善敏捷开发平台的安全管理，为开发、测试和安全管理人员提供自动化工具，实现代码问题提前发现、及时改进与闭环跟踪。
• 开发安全项目知识转移：默安科技还协助企业C根据开发安全项目成果，建设文档管理系统，统一管理各类制度、技术规范、项目材料，提升内部团队沟通协作效率。同时，组织相关开发、安全人员进行针对性的安全培训赋能，培训内容包括开发安全意识、安全设计与编码、安全需求评估等，帮助其提升安全开发能力。

安全能力价值

默安科技在本案例中主要为企业C提供了以下的安全价值：

• 满足国家网络安全法、等级保护制度关于主机、数据、应用安全的合规监管要求；
• 协助建立开发安全管理体系，细化立项、需求、设计、编码、测试、上线各阶段的开发安全工作流程与职责，规范执行开发安全设计、安全编码与检测、提升应用安全防护能力，保障业务安全性和可靠性；
• 将安全漏洞发现前置到编码和测试阶段，不仅提升了系统安全性，还极大地降低安全修复成本；
• 在对现有业务影响最小化的前提下，统筹建设、合理规划，完成安全工具平台建设，实现安全漏洞自动化的发现与线上闭环管理，提升了开发团队的工作效率。

客户评价

“默安科技的DevSecOps解决方案协助我们完成了从0到1的开发安全体系建设，不仅满足了网络安全法、等保2.0等法规标准的要求，降低了业务上线后的安全合规风险，同时默安科技的安全工具还能与现有Pipeline流水线无缝对接，执行自动扫描，提前发现并处置大量安全漏洞，提升漏洞修复效率，缓解业务上线后的安全运维压力。”

——该制造企业CISO

案例四：某银行D案例（本案例由北京智游网安（爱加密）提供）

场景介绍

某银行D成立已有二十余年，是某地级城市直属的国有控股股份制商业银行，现有员工一千多名，下设支行超过50家。网点遍及该市及各县区，提供现代金融服务。

客户DevSecOps需求

之前的开发维护管理流程繁琐复杂，各个环节相互依赖，人工管理效率低下，无法有效

及时地对开发流程进行管控，需要更高效的开发模式。

而在安全方面，D银行缺少安全威胁库、安全需求库、安全设计库、安全组件库、安全用例等开发安全管控所需的基础知识库建设和积累。因此，D银行在面对一个新的项目时，难以快速地进行威胁建模分析，进而无法形成安全需求乃至安全设计、安全用例等，即使转向更高效的DevOps开发模式，也很难保障开发软件的安全。

另一方面，由于开发安全管控人才的缺乏，D银行对安全活动评价及审计的专业能力不足，无法确认安全的实施效果并进行有效改进。

因此，D银行不仅需要一套新的更敏捷化的体系加速自己的开发，更需要一系列能够支撑这套体系的安全技术架构。同时，基于D银行自身的业务需求以及技术环境，通过知识库及技术措施的支持，自动化进行安全需求识别，生成安全设计及安全用例，并对测试中发现的安全问题进行闭环管理。

厂商解决方案

爱加密在D银行的解决方案可以分为三个方面：

• DevSecOps平台建设：DevSecOps平台包含了各阶段流程的梳理、评审机制的建立、相关资源库的建设，通过数据接口收集各阶段安全数据、开发数据及漏洞样本，打造覆盖应用开发安全建设和使用全生命周期的智能安全管控平台。平台中的知识库具有丰富安全威胁库、安全基线库、安全需求库、安全设计库、安全组件库、安全用例等，并有机制保障能定期更新升级。适用范围能够覆盖Android、iOS、Web、后台应用等。 同时，兼具针对移动端的自动化检测平台，以及集成网络扫描、主机扫描和数据库扫描为一体的基于爬虫引擎的扫描工具。对上线后的app及web系统还有持续的风险态势检测，及时发现运行过程中发的威胁，并将威胁进行上报，上报后的威胁情报，建立威胁情报库，情报库后续持续优化完善整体开发过程的知识库，不断的丰富知识库的覆盖全面度和准确度。

• 安全工具融合：爱加密将D银行现有的安全工具进行整体融合，嵌入到开发的各个环节，使开发者在开发过程中自动对代码进行安全扫描，提示开发者代码的安全问题，及时让开发者进行修改。 在系统提交测试环节时，自动化检测系统会分析系统类型，提交到不同的系统中进行自动化检测，同时检测每个系统的安全检测基线，对于不满足基线要求的系统自动打回要求修改等。 安全工具融合后，不再作为独立的安全系统存在，而是自动的嵌入到整体流程中，在流程的流转过程中进行自动的安全处理，并将发现的问题进行反馈整改等工作。
• 安全咨询建设：爱加密基于D银行的实际情况制定安全开发生命周期管理体系，并结合试运行情况进行优化调整。通过构建通用威胁模型，从开发生命周期的角度制定系统开发全生命周期安全控制流程，明确开发生命周期各阶段中安全控制工作的介入时间点与所需完成的工作内容，制定IT项目安全评审流程，建立安全控制点和控制活动，构建安全评审各阶段工具及模板，与现有IT 管理流程和变更流程融合，将安全控制要求和控制活动植入现有流程中，补充完善应用安全开发规范和移动安全开发规范，应对安全漏洞的代码规范，补充完善安全需求测试用例，补充完善代码审计工具中安全规则。

安全能力价值

爱加密的解决方案为D银行提供了以下的安全价值：

• 基于D银行现状调研评估，针对银行现有的信息安全隐患与问题进行分析、治理，提供有效解决方案。
• 开发和集成各种安全工具，减少人工检测评审，通过自动化能力提高应用开发的安全性，降低成本。同时，基于一个平台对安全工具进行统一化管理。
• 安全需求完善，从相关安全标准、行业法规、监管需求和业内常见最佳实践等多方面进行综合完善；针对与来自行业、国家监管架构、市场要求及系统应用对应业务要求分析，确定系统或软件的安全需求。
• 安全编码，针对系统源代码从程序结构、系统脆弱性以及安全缺陷等方面进行安全审查及检测，指导开发人员采用安全的编码方法，制定安全编码规范和标准。
• 实现开发安全平台内的安全数据集成、分析和安全指标可视化。

客户评价

通过对Devsecops平台的建设及持续的咨询及驻场服务，目前该平台已在D银行完整的执行，帮助唐山银行解决以下痛点问题：

1、开发维护管理流程繁琐复杂，各个环节相互依赖，人工管理效率低下，不能有效、及时进行管控。

2、缺少开发安全管控所需的基础知识库建设和积累，如：安全威胁库、安全需求库、安全设计库、安全组件库、安全用例等。

3、面对一个新的项目不能快速的进行威胁建模分析，不能快速形成安全需求乃至安全设计、安全用例等，效率低下成为推进的阻力。

4、缺乏开发安全管控的专业人才；对安全活动评价及审计的专业能力不足，导致无法确认实施效果及进行有效改进。

▶ DevSecOps工具市场指南

能力点阵图

DevSecOps市场调研

• 入选本次DevSecOps工具能力点阵图的安全厂商有12家，分别为：安恒信息、梆梆安全、海云安、开源网安、棱镜七彩、默安科技、奇安信、思客云、孝道科技、悬镜安全、云弈科技、智游网安（爱加密）。其中DevSecOps产品收入为主营业务收入的企业有三家分别为：思客云、悬镜安全、棱镜七彩。
• DevSecOps在数世咨询定义的市场成熟度，概念市场、新兴市场、发展市场与成熟市场四个阶段中，位于新兴市场阶段。在数世咨询发布的《中国网络安全能力图谱》中属于“业务场景”维度中的“开发安全“技术领域。

• 根据调研，国内最早DevSecOps工具出现在2014年，从2018年开始有大量安全厂商进入这个领域。
• 据本次调研统计，2020年国内DevSecOps市场规模约在3.41亿元左右，综合各家提供商的判断，预计2021年将达到5.47亿元左右，2022年将达到7.66亿元左右。

• 据调研目前DevSecOps交付模式可分为四种：单一标准化产品、定制化及运营产品、集成模式以及订阅式服务。其中主要以“单一标准化产品”交付的比例占62%、以“定制化运营产品”形式交付占25%，集成模式和订阅模式分别占7%和6%。DevSecOps的定制化需求主要由于客户的技术环境的多样性、DevOps转型的支持，以及客户自身技术与业务环境下的特殊需求。

• 如下图所示，国内各行业用户对DSO的投入情况，排名前三的为：金融(36%)、互联网企业(8%)、国防(8%)。考虑到应用场景，金融和互联网由于快速迭代与开发和运营的场景结合要求较高的原因，对DevSecOps需求较高。但是，由于除了几家大型互联网公司，其他大部分互联网公司的预算成为其向DevSecOps转型的绊脚石；而金融行业除了本身业务线多，会有许多需要DevOps开发模式的场景之外，本身有足够的预算投入到DevSecOps也是关键原因。

• 从客户的分布来看，DevSecOps的投入区域最高的是华东区域，占38%，高于华北的29%，同时华南占到了19%。一般而言，安全产品的客户分布占比最高的往往都是华北；而在DevSecOps方面，华东地区成了最高区域。其原因在于金融行业是DevSecOps的主要先行客户，其在华东（长江三角洲）地区有大量客户群体；同样，由于广州、深圳的金融产业，华南地区在DevSecOps的占比也相对较高。

• DevSecOps的推动因素主要有两点：开发安全越来越深入人心，以及DevOps的发展。DevSecOps的发展离不开DevOps转型的进程，当越来越多的企业开始关注DevOps的时候，在安全合规、安全开发的影响下，DevSecOps落地自然会更加迅速。
• 阻碍DevSecOps落地的因素同样有两点：DevOps本身转型的难度，以及开发理念和制度的转变。尽管说DevOps的发展能推动DevSecOps的落地，但反过来说，DevSecOps的落地也受限于DevOps的发展——虽然DevOps在越来越受到关注，技术也在越来越完善，但实际上能进行DevOps实践的企业依然有限。另一方面，DevSecOps不仅仅是安全左移，同时还需要从开发到运营进行整个结构的文化与制度的建设，企业自身内部的推动也会成为DevSecOps的落地难点。

未来趋势

虽然说DevOps概念的出现并不算短，但是国内具体实践也不过是在这两三年内开始。企业在本身对DevOps的转型缓慢，也就造成了当下DevSecOps发展处于早期状态。事实上，许多企业依然处于DevSecOps的试点状态，或者建设中状态。未来一两年而言，DevSecOps的发展未必会呈现一个井喷的状态——正在考虑转型的企业很可能依然会选择观望，而正在转型中的企业也需要时间检验自己的转型情况，衡量是否进一步往DevSecOps方向发展。而在一两年后，当转型中的企业逐渐看到DevSecOps带来的收益时，会进一步推动自身DevSecOps体系的完善，而其他观望的企业也会开始向DevSecOps转型，扩大整体DevSecOps的市场。

当然，DevSecOps也不会成为唯一的开发模式，瀑布开发模式对大型项目依然适用；而敏捷开发模式对于一些需要快速迭代，同时并不需要运营的接入的开发团队而言依然有很大的优势。因此，未来的开发安全会是传统开发安全需求和DevSecOps需求并行的情况。在一些企业中，也完全会存在多种开发模式在不同项目中同时存在的情况。

当DevOps的技术更成熟的时候，也会有越来越多的中型，甚至小型企业开始使用DevOps的开发模式，但是这些企业很有可能无法再为自身的DevOps开发环境专门配置相关的安全工具——无论是成本因素，还是人员技术能力因素。而在安全越发受到重视的情况下，DevOps平台也有望往新的方向发展：直接在DevOps平台中预配置一定的安全能力，将DevOps平台演化为DevSecOps平台——这也是当下一类客户的需求：从自身缺乏安全管控的传统开发模式，通过直接建设DevSecOps平台，达成安全与开发的双向转型需求。因此，长远来看，DevOps平台有可能直接被DevSecOps平台所替代，这一演化可能是安全厂商从安全出发，加强开发、运营侧的平台能力；也可能是DevOps平台开始逐渐加入一定安全能力；当然，DevOps平台与安全厂商合作，打造DevSecOps的解决方案也会是一个方向。

作者：

技术应用分析师：潘颉阳

产业市场分析师：左晶