2.1　DevSecOps现状调研

DevSecOps自从2012年被提出，到2017年开始流行，之后又经历了数年的发展，在世界范围内得到了一定的推广。在业界，随着一些DevSecOps社区的建立，以及安全公司对于DevSecOps重视程度的提高，每年会有相关的DevSecOps报告被公布，用以调研和分析目前DevSecOps的现状，比如企业对于信息安全的重视程度、相关DevSecOps工具使用的情况，以及DevSecOps在企业内的发展情况等。

2.1.1　DevSecOps的行业调研

2020年，DevSecOps社区发布了他们一年一度的第七次社区调查报告[1]，对共计10多个国家的5045名IT从业者做了问卷调查并对调查结果做了分析，此报告是从安全角度看DevOps实践的权威材料。

在实践DevOps时，不同行业对安全的重视程度也不同。对安全最为关注的金融和科技行业，其受访从业人员占到了整体受访者比例的一半以上。另外，其中超过一半的受访者（55%）所在的开发团队每周需要进行至少一次发布部署，说明快速发布已经成为大部分企业的业务需求。然而，在传统模式下，安全管控往往成为快速发布的瓶颈。在巨大的业务交付压力下，安全也成为最容易被舍弃的环节，并且安全问题造成的返工也会大大增加整体的研发成本。DevSecOps正像报告中所指出的那样，这种安全左移的模式巧妙地解决了安全和速度的矛盾，帮助开发团队保持竞争力。这种积极主动的方式不仅降低了安全问题的冲击和成本，而且使得一切井然有序，不至于在出现问题时到处救火。

然而，根据最近三年的调查显示，有接近一半的开发者承认他们没有时间去处理安全问题。在实际工作中，真实数据甚至要远远高于调研数据。这个比率连续三年保持不可思议的稳定，再次验证了安全是一个被大部分人口头上非常重视，但往往在实践中选择性无视的一个话题。如果速度不是建立在安全和可用的基础之上的话，那么安全隐患将是注定的。因此，对于DevOps实践，需要在各个环节进行安全要素的引入。

然而在实际工作中，DevOps成熟度较好的团队往往更加重视应用安全工具的使用、安全流程的建立，以及安全相关培训的开展。在应用安全工具的使用和自动化程度（开发流水线的集成）上，DevOps成熟度较好的团队在应用安全的各个领域（WAF/SAST/DAST/IAST/SCA等）都领先于DevOps不够成熟的团队。甚至在某些应用安全工具的使用上（比如说容器安全工具、动态安全测试工具、交互式安全测试工具和第三方组件安全扫描工具），这个比率大于2倍。

报告中对第三方开源软件的安全管控也做了详细的调研。报告中显示，开源软件隐藏的安全问题从2018年开始已经连续三年呈下降趋势，但是这类问题仍然很多并且出现得很频繁。另外，DevOps成熟度越高的团队对由开源软件引起的安全问题会更加重视，更愿意使用Software Bill of Materials (SBOM)来保证他们应用系统里开源软件的安全，也将开源软件安全使用规范集成到SDLC中进行自动化。

Synopsys于2020年8月发布关于DevSecOps和开源管理的调查报告[2]，对第三方开源的安全管控进行了更加详细的调研和分析。这份报告调研了1500多名IT从业者，其中包括：

1）79%的开发人员和21%的安全人员。

2）对于访谈者所在的公司，100人以上规模的占到了近70%，其中250人以上的公司占到了42%。

3）访谈者65%来自亚洲（中国、日本和新加坡）、18%来自欧洲（英国、德国和芬兰）、17%来自美国，每个国家至少有50个访谈者。

报告显示（图2-1）：33%被访谈的IT从业者所在的团队具备DevSecOps能力并且已经在业务范围内大规模推广和使用；30%被访谈的IT从业者所在的团队拥有有限的DevSecOps能力并且正在推广中；另外37%被访谈的IT从业者所在的团队正在研究、试点或者根本没有DevSecOps实践。总之，63%的开发团队已经或者正在实践和推广DevSecOps，由此可见DevSecOps正在开始大规模推广，并且增速很快。另外，42%访谈者所在的企业拥有专业的安全团队，负责软件开发过程中的应用安全。

报告根据调研的数据建议企业应该在SCA和IAST上进行更多的投入，因为SCA和IAST可以与开发流水线进行集成以实现自动化，从而更好地与DevOps进行融合。另外，报告也建议一套完整的DevSecOps工具栈应该包括SAST、DAST、IAST和SCA，从而使得代码的质量和安全问题可以在SDLC的前期更早地被发现。虽然图2-1中显示33%和30%的团队分别已经或者正在推动DevSecOps，但是图2-2显示安全工具最高的使用率也仅仅只有45%，说明应用安全工具仍有待推广。

关于开源软件管理规范，调研显示72%的企业有公布的开源规范。然而，图2-2中显示只有38%的企业使用了SCA工具对开源安全进行管控。那剩下的62%的企业对开源安全是如何管控的呢？难道只是依赖于开发人员自觉遵守？这一点也正好验证了SCA工具的使用仍然处于早期阶段。

报告对开发团队从发现严重的开源安全漏洞到修复的平均时间也做了相关的调研（图2-3）。调研显示，只有16%的团队可以在一周内修复严重级别的开源安全漏洞，而一半以上的团队需要2～3周的修复时间，甚至有34%的团队需要一个月甚至更长的时间进行修复。越长的安全漏洞修复时间意味着在更长的时间窗口中，此应用/系统会暴露在黑客的潜在攻击以及数据泄露的风险之下。

比如，2017年3月，一个Apache Structs框架里的高危安全漏洞被发现并公布。就在同一天漏洞公布之后，安全研究员在网络上立即发现了大量的尝试攻击。另外，也是在同一天，如何利用此漏洞攻击Apache Structs的信息被一些黑客在流行网站上发布。成千上万的企业被攻击，甚至包括许多及时打好补丁升级的公司。由此可以看出，对于那些需要很久才会将SCA扫描出来的开源安全漏洞修复的企业，其潜在的安全风险和被黑客趁机攻击的风险是非常大的。

调研报告最后对正在寻求安全开发的企业提出建议：

1）首先，需要对目前团队安全开发的成熟度等级做一个分析和判断。

2）参考安全开发时间，确定需要改进的核心部分，比如第三方开源补丁和自动化安全测试。

3）根据以上评估的结果，制定并实施高效的低成本的安全开发改进实践计划。

文章《2021年CVE漏洞趋势安全分析报告》[3]对最近几年CVE的分布和影响范围做了分析，并且通过数据预测2021年安全漏洞的趋势和重点高风险资产。自2010年后，CVE漏洞数量是持续增长的，其中2020年的CVE数量已经是2010年CVE数量的5倍之多。

虽然2020年的漏洞在统计数量上是最高的，但实际情况是更多的漏洞主要集中在2017年的CVE编号上。这说明了互联网整体服务软件更新相对要落后，从而导致具有潜在安全隐患的软件未能及时更新升级补丁。报告中也针对CVE对于应用软件的影响进行了统计，排在前几位的分别是Apache、MySQL、Nginx、Tomcat和OpenSSH。除此之外，Jenkins也是互联网中最常见的中间件软件，另外还有数据库、远程管理协议和容器等工具。

在大体了解了行业内DevSecOps的发展现状后，如何更好地进行实践落地，还需要对企业本身的现状有充分的了解和清晰的认识。

2.1.2　企业现状调研

古有孙子曰“知己知彼方能百战不殆”，这句话的含义同样也适用于DevSecOps的推动工作。DevSecOps的推动本质上可以理解为对企业现有研发运营体制的一次变革，通过一套系统化的项目推动，逐一击破传统研发运营体制中的各项瓶颈，通过大量的自动化工具引入及职能的左移，帮助企业实现产品的快速、持续、安全交付。那么对于企业来说，了解自身的情况，知道当前自身所处的位置，发现问题并深刻理解当前的瓶颈所在，即成为企业开展实施DevSecOps工作的第一个步骤。我们可以将其拆分为多个维度——技术现状、人员现状、流程现状。其目的是为后期的DevSecOps工作开展提供基础的数据量化支撑，同时帮助团队更好地了解自己，暴露问题。

1. 调研方式

针对企业内部的调研，建议采用以下若干种方式或组合，再结合企业自身情况，进行灵活处理。

1）资料采集：收集企业内部各业务线、产品线的文档材料，例如业务范围、用户量、关联的监管要求、技术指标、研发文档、人员情况和供应商情况等，便于对业务与产品线的组成架构做出初步了解及分类。

2）问卷调查：对研发团队、测试团队、运维团队的情况进行调研，可以采用问卷调查的方式，根据业务与产品线的分类进行实际情况调研。例如，在金融机构当中负责某类外汇产品交易系统的IT团队，从业务研发、测试到运维都属于同一业务线分类，则该问卷调查的结果处理与分析也可按照此分类进行。问卷调查的范围应当包含技术、人员、流程的多维度现状收集，具体问卷内容可参考本节下面的技术现状、人员现状和流程现状中的问题清单。

3）人员访谈：对于重点业务或产品团队，或在问卷调查后仍然对现状有诸多疑问的团队，建议采取与相关人员面对面访谈的形式，可以一对一或一对多，要求准备一个深入的问题清单，用来获取有关现状问题和潜在解决方案的整体特征信息。例如，当发现该业务或产品团队的代码质量长期处于问题多发状态，但团队成员并未采取任何及时措施时，进行一次人员访谈也许能够帮助企业更深入地了解其背后原因。

4）对问卷与访谈结果的集中讨论：即对整体问卷与访谈的结果进行整理后，针对各类特征信息、现状问题等进行集中式分析。对于跨部门、跨业务线、跨产品线的同类特征问题，可以把相关人员召集在一起，对现状问题进行思考，找出痛点和讨论潜在的解决方案。例如，某些产品由于对市场时效性敏感，对产品的更新及发布频率有较高的需求，但往往正是由于在追求速度的同时忽视了诸多潜在的安全问题，部分产品团队甚至长期将安全审查视为他们的瓶颈所在。针对该类问题，则可以对多个跨产品线的团队进行集中式讨论分析。

5）深入团队调研：对于诸多无法用言语、文字进行书面清晰描述的问题，可以派遣人员短期深入相关团队，在其实际工作环境下共同工作一段时间，以便更加深入地了解团队问题、要求和应用环境。

6）对潜在需求的分析：用户需求是一切业务与产品的生存核心，DevSecOps的实施方案也必须要考虑到对未来需求转化的影响。在项目实际推进过程中，不进行合理管理和安全控制的需求变更往往给项目带来过高的成本和无法预料的风险。因此对于软件开发工程来说，一套合适的需求变更管理流程和规范是不可或缺的。所以，对当前业务及产品团队的需求管理方式及未来潜在需求的分析也是必不可少的调研环节。

7）最佳实践/用例的总结：在企业当前各业务及产品团队中，各自必定都有适合其场景的项目实施方法，对于在调研中明显展现出较强交付或安全能力的团队，可以对其团队经验进行总结，对诸多经验进行归纳分析形成最佳实践或用例。这对DevSecOps的实施方案编写具有积极意义。

2. 技术现状

技术现状一是业务或产品线本身技术的情况，包括其使用的技术框架、开发语言、依赖环境、数据库环境等（表2-1）。二是研发、运维及安全相关自动化现状，包括各类自动化整合工具、代码测试工具、安全扫描工具等（表2-2）。

①运营事件：在产品或业务系统运营过程中，在用户使用期间，遇到各种问题或故障（例如服务中断、逻辑错误、数据出错、异常报错等），可以使用专门的工具或渠道，向IT团队寻求帮助。我们通常称这种工具创建的帮助请求（Support Request）为运营事件。

②信息安全事件：信息安全事件是指由于人为原因、软硬件缺陷或故障、自然灾害等情况对网络和信息系统或者其中的数据造成危害，对业务甚至社会造成负面影响的网络安全事件。依据《中华人民共和国网络安全法》《GB/T 24363—2009信息安全技术　信息安全应急响应计划规范》《GB/T 20984—2007信息安全技术　信息安全风险评估规范》《GB/Z 20985—2007信息技术　安全技术　信息安全事件管理指南》《GB/Z 20986—2007信息安全技术　信息安全事件分类分级指南》等多部法律法规文件，根据信息安全事件发生的原因、表现形式等，将信息安全事件分为网络攻击事件、有害程序事件、信息泄密事件和信息内容安全事件四大类。

更多关于问题清单示例中DevSecOps工具的详细情况，可参考2.3节。

3. 人员现状

DevOps通过合并开发和运维实践，消除隔离，统一关注点，提升团队和产品的效率和性能，DevSecOps则是将大量的信息安全工作左移，与之结合形成一种全新的安全理念与模式，其核心理念为安全是IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发到运营整个业务生命周期的每一个环节。因此，对企业当前各团队人员现状的调研尤为重要。

人员现状的调研大致可以分为两个维度，一是人员组成的现状，二是人员文化与安全意识的现状。通过人员现状的调研，可以为后期DevSecOps框架中项目运营模型的建立提供数据支撑。

（1）人员组成的现状

在传统SDL模式下，软件产品或软件工程团队中通常包括以下几类角色：产品策划或业务分析师、产品经理或项目经理、架构师、开发人员、测试人员、运维或实施人员等。随着产品规模的不断膨胀和软件开发技术的持续发展，软件开发的分工和组织也变得越来越复杂。不同团队之间对于同一角色的工作职责也会随着产品和技术的变化而不同。人员组成现状调研的目的首先是了解当前企业中各团队人员的分工情况，其次需要理清各团队人员职责的差异，最后则是要分析在软件研发过程中结合当前现状可能存在的瓶颈或缺陷。我们可以遵循以下思路：

1）当前各团队中有哪些角色？

2）每个角色的分工是什么？

3）角色分工的职责内容是否存在问题或不足？

4）各角色分工之间的沟通效率如何？

5）该人员组成是否适应产品快速迭代与交付需求？

（2）人员文化与安全意识的现状

在任何项目实施过程中，人都是其中的重要组成。就如产品的设计离不开产品策划与分析师，项目管理离不开产品或项目经理，技术实现离不开架构师、开发人员等。任何一个企业都不能单纯依靠技术和工具来支撑业务甚至作为业务本身。公司的核心价值还是人，而一群人的行为就形成了文化。所以通过DevSecOps改变人的思维模式、做事和协作方式，通过员工以及他们的专业知识和经验来实行DevSecOps转型，才能使得企业的研发效能可以长远改进。因此，在项目的前期调研中对人员的文化与安全意识现状了解透彻，对未来在项目中如何补足这方面短板并促进DevSecOps转型成功起到了积极作用。我们可以遵循以下调研思路：

1）当前各团队成员是否具备敏捷开发的意识？

2）各成员对DevSecOps技术栈中的各类工具是否熟悉？

3）人们在产品或项目开发、测试、运维等各环节的安全意识如何？

4）团队成员对于DevSecOps转型的意愿是否强烈？

5）团队成员是否具备代码安全开发的能力或安全漏洞的修复能力？

4. 流程现状

DevSecOps的实施包含了文化、流程、组织结构、技术等多方面的协作，其最终目标是引入一套框架，解决持续快速交付和信息安全之间的矛盾（图2-4给出了传统软件开发的流程）。那么，对企业当中现有团队的工作流程进行调研，可为后期流程的改进提供依据，并尽可能地解决各类流程与管理上的瓶颈问题。同样，我们建议调研遵循以下思路：

1）要详细了解与记录当前的软件项目开发流程：具体包含哪些步骤，每个步骤又包含哪些环节，它们在软件开发的整个生命周期或流程比例中所占的比重又有多大？

2）当前软件开发流程是否为各团队的统一标准，不同团队是否存在同一流程的执行偏差？

3）当前流程是否存在任何影响产品发布效率的瓶颈问题？

4）各团队成员严格执行了当前流程的每一环节吗？流程中又如何做到自身监管？

5）当前流程是否存在一些安全漏洞或机制上的不足？