咸阳网站开发公司,哈尔滨市做网站优化,网站支付体现功能怎么做,广安们内网站建设作者 | liumiaocn责编 | 徐威龙封图| CSDN 下载于视觉中国2019年DORA发布了DevOps的研究报告#xff0c;迄今为止这已经是DORA的第八次报告的发布。相较于往年的报告#xff0c;2019年的报告全篇只聚焦于一个要素#xff1a;安全。在2018年DORA提供了一个包含五个步骤的模型… 作者 | liumiaocn 责编 | 徐威龙封图| CSDN 下载于视觉中国2019年DORA发布了DevOps的研究报告迄今为止这已经是DORA的第八次报告的发布。相较于往年的报告2019年的报告全篇只聚焦于一个要素安全。在2018年DORA提供了一个包含五个步骤的模型来帮组企业更好地开展或者推进DevOps的实践而将安全与DevOps实践进行融合的时候往往发现会存在很多困难这份报告将会从多个方面对安全的融入进行展开分析。接下来让我们来看一下这份报告能够给我们带来哪些启迪。研究人员随着理念的推广DevOps不再只停留在词汇和概念的程度上已经得到了普遍的接受和认可。与2018年类似这份报告的主导者仍然是puppet和splunk除此之外加入了一个新的成员circleci很有趣的事情是主要作者仍然是下面的四位连头像都没有变化唯一的区别是是Michael Stahnke从puppet的director of engineering变成了circleci的VP。不过这些对读者来说并不那么重要大家所关心的是他们的产出所能带给我们的启发。安全融入所带来的挑战安全是一个非常重要的概念需要给予足够的重视这个想法深入人心但是在很多项目进行安全实践相关的融合时都会发现这个想法显得过于理想化观念上的重视和事实上的轻视在实际的实践中同时被展现了出来。安全增强相较于功能特性的增强对于企业来说并不能时时清晰可感它更像保险只有安全事故出现的时候才会觉得后悔所以特性增强一般会排在首位其次才是安全增强而实际上排名“其次”的第二名永远都得不到足够的重视后面我们也将会使用一些数据来佐证这个观点。在这份报告中对企业在实施DevOps转型时如何进行安全融入、以及安全融入对企业的产出的影响都在报告中给出了结论。内容概要1、DevOps的实施会对安全带来正向影响一般来说需要在DevOps实践中进行安全融入的企业都是那些已经走过初期阶段企业DevOps的实践已初见成效需要在整个企业内部进行展开这种情况之下自然需要在安全上进行进一步的强化。解读在2019年的调查报告中DevOps实践很好的团队之中有高达22%的比例达到了安全集成的最高级别。DevOps的CAMS在安全的融入方面同样起效可靠性、可预测性、可测量行和可观测性不仅仅带来了安全的环境更为重要地是将这一切结合了自动化之后所带来的安全事件响应速度的效率提升。好的DevOps文化能够支持更严格的安全策略的贯彻执行在有着Sharing分享的文化的团队之中团队使用通用的工具合力完成共同的目标安全也自然成为了一种共同的责任在这种文化之下“部门墙”会相对更为容易跨越在问题出现的时候自然也会得到最早地解决。2、在软件交付中深度集成安全使得团队更加自信根据调查报告显示安全级别达到最高级别的受访者有82%对公司的安全有足够信心而没有进行安全集成的受访者中这一比例仅达到38%这一调查结果充分显示在软件交付中深度集成安全使得团队更加自信。解读集成安全并不只是简单的“左移”而是需要从整体上进行解决比如强调跨团队的协作、增强自动化在检测和预防方面起到的作用同时需要打破部门之间的知识孤岛使得成员都能够参与进来。在安全改进方面使用的最为广泛的几种实践如下所示团队协作基于威胁模型分析安全团队和开发团队增强合作应对安全威胁工具集成安全工具集成到开发的流水线中可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。安全需求从功能性和非功能性综合考虑将安全相关的需求列到产品任务清单中。人工评审从安全专家的角度对于自动化测试进行评估重点包括那些具有较高风险的代码变更内容比如认证和加密相关部分。基础框架安全与基础框架相关的安全策略需要在部署之前进行评审。重点所有的这些内容大多数公司都知道应该做但是往往因为种种原因却没有去做这是一种普遍的情况。3、在软件交付生命周期集成安全会带来积极结果调查报告发现生产环境的按需部署效率提升安全集成级别较高的受访者所在公司在按需进行生产环境部署方便达到了61%的比率而安全级别较低的受访者所在公司在这一比例仅能达到49%。修复时间相差不大调研之前的假定认为安全集成级别较高的公司能够更快部署、更快修复安全性问题但是实际反馈结果显示在修复问题的时间方面目前相差无几。安全改善效率更高安全集成级别较高的公司能够在进行功能特性交付的时候更加有效的强化安全改善在发现交付只生产环境处理安全问题时的处理更有效率。解读在软件交付生命周期中安全集成地越深入交付团队对于团队共同安全责任的理解更加清晰同时对于对于潜在的对于业务的风险也会降低地更多安全问题也会得到更多的重视。4、中间过程可能会是混乱和难熬的正像DevOps个别的成功推广开来碰到的问题一样中间的阶段和过程可能是混乱无序、非常难熬的。在项目刚开始的时候很多未知的问题和障碍还未出现还没有大面积普及的情况下往往较为顺利的看到了预定的结果但是很快随着集成的深入很多问题就会出现这就是非常难熬的中间阶段。安全集成也是这样往往解决了一个问题就会引入一个新的问题我们不知道这漫长的中间阶段到底有多长不过根据经验来看一般比想象的要短但是难熬的日子往往觉得很漫长。比如如下是2018-2019年的中间阶段的企业的比例构成解读在难熬的中间阶段安全的融入所需要的协作、沟通甚至有时会拖慢交付的速度安全审计的问题会增加这些都会带来额外的工作和注意力需要组织级别同时相应地根据情况进行变化以适应但是这都是中间阶段所需要处理的细节问题。抱着必定得到拯救的信心坚持下去吧光明就在前方除此之外我们也别无选择。而从2018和2019年连续数据也能够佐证这一观点虽然整体在不断成熟但是除去做的非常完善的和尚未起步的连续两年卡在中间的企业都高达79%说明DevOps演化还将是一个长期的过程。数据来源1、区域整个亚洲占到整体调研数据的19%解读按照国家来确认中国的反馈占到这19%的8%所以这份调研报告所能体现出中国在其中的比例大概为1.5% 19% * 8 % 所以这又是一份基本不能代表2019年中国DevOps最新发展状况的数据但是对于整体的发展趋势可以有所了解。2、行业与规模科技与金融仍然撑起半壁江山而零售/通信/教育/医疗/政务/健康/保险/制造等主要行业也达到40%左右整体行业均有涵括非盈利的机构依然能够占到1%的比例。2019年对组织大小的判断继续延续2018年的方式定义在年度营业收入使用annual revenue将组织进行划分10亿美元以上的组织占到28%相较于2018年略有提高相较于2018年低于100M$营收的公司44%的比例下降至30%其余规模的组织比例也较为均衡。3、角色受访者仍然以管理人员偏多ICIndividual Contributor仅占26%这一比例很巧合地跟2018年完全一致其他成员的比例也大体相差无几。4、DevOps团队随着DevOps理念和实践的不断推广与DevOps团队相关的工作人员也开始逐年递增以下是到2018年DevOps团队的占比情况在2019年由于团队的人员的职责进一步细化在2019年显示的DevOps团队仅占22%。解读看似下降的比例但是考虑到如下三部分都属于DevOps的范围比例已经为22% 4% 2% 28%Site reliability engineering4%Release engineering2%DevOps22%同时在2019年重点融合的安全相关的部分也同样可以认为是DevOps团队的延伸所以结合起来仍然在进一步上升名称可能有所变化但是方式和职责明显是更为细化和清晰。Information security / security operations6%Compliance audit1%DevOps实践中的安全集成1、DevOps的演进模型中的安全集成在2018年的报告中提出了企业在DevOps演进时的5个阶段的模型如下所示我们可以看到在第4阶段中通过自动化安全策略配置来帮助DevOps在安全方面升至第5阶段而第5阶段的一个关键实践就是自动化的事件响应同时安全团队在设计和开发的阶段都进行融入都是第5阶段需要做的事情。2、安全集成的模式和实践经验DORA八年的DevOps调研结果显示当运维需求集成进软件交付流程中更快的部署、更少的错误、更省时的修复、更少的手工作业都是可以期待的同样在安全集成的时候在如下方面将会有哪些影响也是我们所关注的主要的软件交付性能指标安全问题的响应组织发现安全问题的方式对待审计的态度和方式解读成功的DevOps实践可以将本来形同水火的开发团队和运维团队变的亲密无间同样事情在进行安全的集成也是类似的好的安全集成可以将互相看不惯的开发运维团队和安全团队变得不分彼此这样安全问题才会真正成为每个人下意识会去关注的。3、安全集成的困难之处安全实践在实际的项目中往往扮演着一个“麻烦制造者”的角色安全往往被视作部署的瓶颈它往往发生在交付周期的最后阶段这些检查往往是手工的所以往往是造成延迟的重要原因而一旦查出安全问题往回意味着开发、测试和运维团队需要对应一些额外的未被计划的工作这往往使得已经延迟的交付进一步加深。在现实的世界中往往新的特性快速地投放才是重中之重带着一些未解决的安全问题先行将特性上线的做法也并不罕见这种情况下当时的想法一般会是“在下一个版本中一定要堵住这个有风险的安全漏洞”但是一旦上线出于各种原因就忘记了还有一个洞没有补导致安全相关的技术债务不断积累。在加上漫长难熬的DevOps演进的中间阶段安全的集成在实践中举步维艰。但是在这个过程之中我们还是能够发现一些无论是DevOps演进还是安全集成时都会通用的实践经验逐步改善的中间过程中间阶段需要处理的问题非常广泛和复杂在流程上需要组织跨团队协作以解决手工评审等步骤同时需要通过自动化来增强管控和追踪性。协作和分享早期可以通过协作与分享不仅仅包括信息的分享还包括责任的共担很好地进行改善的环节。自动化在演化的过程中团队可以使用自动化来解决很多痛点比如自动部署、比如自动事件响应和自服务能力。4、DevOps vs DevSecOps这份调研报告中特意提到了一个词DevSecOps但是DORA认为安全应该只是DevOps实践中的一个部分但是通过DevSecOps能够广泛引起企业对于安全的重视是值得称道的。5、安全集成的现状2019年度对于统计的数据进行分析之后发现处于非常低的阶段Level 1Level 1 Level 5的说明在后续章节展开的受访者只有6%达到最高安全级别Level 5的比例达到22%而在通过对于DevOps演进进行分析也能够发现安全集成在整体起到越来越重要的作用。6、DevOps演进 安全集成2019年度关于安全集成和DevOps演进的结论:DevOps演进能够更好地推进安全实践的落地对于希望对于安全进行改善的组织继续践行DevOps是一个不错的主意。安全集成级别1、安全集成的级别界定方法对于受访者安全级别的界定2019年度是通过对于问卷的内容进行设计来达到的首先需要确认安全在软件交付周期的哪些环节被引入需求设计构建测试部署根据受访者在上述环节安全被引入的状况来界定安全集成的等级Level 1: 无集成在任何一个阶段都未进行安全集成Level 2: 较低程度集成在一个阶段集成了安全Level 3: 一般程度集成在两个个阶段集成了安全Level 4: 较高程度集成在三个或者四个阶段集成了安全Level 5: 最高程度集成在所有阶段集成了安全虽然重点研究落在了软件交付之上但是从运维角度关于生产环境中安全集成方面也在如下的一些环节进行了确认脆弱性管理与修复安全策略自动化审计发现与响应2、安全集成现状通过对于受访者的反馈进行分析各个级别的比例分布大体如下所示注意整体比例加起来是101可能又是一个无伤大雅的小问题对于整体状况的把握没有影响。另外从Level 2 Level 4由于存在多种组合的可能性经过调研发现如下模式在目前阶段最为常见Level 1: 仅在生产环境安全事件报告时或审计发生时才会驱动安全相关的工作Level 2: 在测试阶段集成安全Level 3: 在测试和部署阶段集成安全Level 4: 在构建、测试和部署阶段集成安全Level 5: 在需求、设计、构建、测试和部署阶段集成安全3、改善方式大多数组织对于安全的改善使用了一种迂回的策略比如关于身份识别和权限控制等都是常见的实践但是很多企业都没有严格地完整地去做这件事因为在实际实施中非常困难这些严格的控制可能会拖慢所有事情的进度在时间成本和效率上将会付出昂贵的代价。而经过调研也发现了真正有效并能够带来正向结果的改善方式从软件的规划和设计开始对每个阶段进行安全相关的控制才能从整体上带来正向的效果。但是如何才能使得安全能够更容易地进行改善能否以一种更为敏捷的方式进行通过不断地迭代来完成答案也非常简单重点在于构建增强安全意识的文化交付团队的成员需要能够具有足够的知识和自动化的手段予以定位安全问题、了解安全问题的处理有限度、具有处理安全问题的足够知识在此基础上对于安全意识的增强才能够真正落到实处。4、安全集成与信心的增强在2019年度的调查问卷中设计了内容用来确认安全集成程度与团队成员信心之间的关联度从下图可以清晰地看出整体来说信心随着级别的提升而提升。解读在安全集成程度最高级别的受访者中有82%的程度表达了他们的信心而在没有任何集成的阶段这一比例只有38%。可以看到即使是只有最简单程度的集成也能在安全信心方面给团队带来明显的效果。持久的信心非常只重要因为它能真实体现团队成员对于安全现状的认识虚幻的信心是无法经受实践的检验的团队持久的信息实际来源于实际上真正安全的现状这样在价值的交付时才能做到真正地安全、快速和稳定。另外需要意识到更为重要的是安全并不仅仅是将一些安全实践比如渗透测试或者静态代码检查等提前开始需要改变和重点关注的是跨团队的协作和责任的共担。5、行之有效的实践建议报告中还列出了一些对于安全集成有效的实践建议可以在使用时进行参照团队协作基于威胁模型分析安全团队和开发团队增强合作应对安全威胁工具集成安全工具集成到开发的流水线中可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。安全需求从功能性和非功能性综合考虑将安全相关的需求列到产品任务清单中。人工评审从安全专家的角度对于自动化测试进行评估重点包括那些具有较高风险的代码变更内容比如认证和加密相关部分。基础框架安全与基础框架相关的安全策略需要在部署之前进行评审主要变更评审对于主要的代码变更在部署之前进行安全人员评审安全特定的测试对于安全相关的特定测试比如测试应用的使用权限和数据访问权限等。自服务开发者可以配置按需进行包含安全设定的基础框架和环境设计融合安全需求被视作普通的设计需求进行处理轻微变更评审对于轻微的代码变更在部署之前进行安全人员评审安全评审应用代码发布至生产环境后出发安全评审渗透测试包含并不仅限于脆弱性相关测试或者黑客工具测试等基础框架配置基础框架可以进行在安全审批的流程基础上进行自动化配置依赖检查对于应用和环境进行相关的依赖检查以确认整体的安全性状况静态代码分析使用静态代码分析工具对于应用进行安全性和脆弱性问题的检查6、经验总结基于威胁模型的团队协作来自于交付团队、安全团队和业务关系人等各方人员一同对于安全相关的威胁常见威胁模型并进行分析以确认应用和支持应用的基础框架所潜在安全风险以及出现问题时相关的应对措施。威胁模型有助于在项目最早期的阶段进行规划和设计同时有助于在开发团队、安全团队以及业务团队之间建立信任和同理心。工具集成提升开发团队的信心工具并不能解决所有的安全问题也不存在一个解决所有安全问题的工具但是可以通过集成工具将例行繁琐的任务进行自动化以提高效率和节省时间比如可以将静态安全工具的检查对于安全相关的脆弱行的分析进行例行的集成通过这些工具的集成使得开发成员在开发阶段就可以快速定位可能存在的风险而在这个阶段进行修改的整体成本也是较低的。在敏捷迭代过程融合安全随着敏捷理念的深入人心代码的发布也正在使用一个小而快的方式在迭代周期中不断进行。敏捷方式有助于持续学习和改进但是对于传统方式下的安全需求的实现则较为困难因为传统方式往往安全策略的检查等都是手工方式另外开发团队内所缺少的安全相关知识和经验才是最重要的问题而实际上这也是融合时的难点所在有了这样的团队成员在定义敏捷的DoD的时候才有可能将安全需求以可验收的方式提前指定才能真正地在敏捷开发中融合安全需求。由于大型企业往往是有一个统一的中心化的团队来对所有应用开发团队的交付安全进行统一管控所有很难保证每个项目都有自己的专门安全人员所以一个较为折中的方式则是鼓励开发团队成员或者运维团队成员能够具备这方面的知识以帮助团队在快速的迭代中能够进行性安全的融合。基础框架相关的安全评审使用诸如CIS Benchmark这样的参考对于进行基础框架相关的评审是一个不错的想法但这是一个开始每个项目的基础框架都有可能不同这就需要安全团队和运维团队一同协作在部署之前对于基础框架的变更或者引入可能会导致的各种问题进行知识和经验的交换并在此基础上进行深入探讨和评审以保证部署的安全性。对高风险的代码变更进行安全专家的评估和自动化测试传统方式下应用只有在UAT或者准生产环境中可会受到安全团队的手工确认如果将此部分的内容进行左移在更早的阶段由开发这能够通过检查或者自动化测试确认这些风险和不合适的配置修改的成本将会更低。由于脆弱性的存在有非常广泛的可能性三方组件、服务器、数据库、网络设备、防火墙、云存储等为了防止被攻击我们需要跨团队比如包括开发、运维、网络、存储、中间件、云计算等进行深入的知识共享以确保我们的检查和自动化测试是与时共进的而这些自动化的检查和测试也将安全人员从琐碎的工作中解放出来可以一起完成一些根据有意义的工作比如和交付团队一起协作确保和测试应用以保证安全性给予错误的配置已反馈以避免类似的错误配置重复出现对于高风险的代码变更进行安全相关的评审实践经验的频度和影响度矩阵根据经验使用的频度以及影响度进行划分上述列出的实践建议的分类如下所示7、软件交付生命周期安全集成与正向效果在软件交付生命周期进行安全集成会在多个方面带来正向的效果这包括8、部署频度在2019年的调查研究中设计了“部署能力”和“实际部署频度”的问卷主要用于确认技术和流程是否对于业务需求的部署有所限制。详细的能力结果如下图所示解读从反馈的结果来看也能看到即使是没有做任何安全集成的组织也可以做到按需部署或者至少一天两次的这种能力相较于8年之前的调研结果已经发生了翻天覆地的变化当时部署甚至仍然是按照月的单位来进行衡量的。部署频度稳定地得到了提升在2017年高能效的组织就可以实现一天多次的部署了之前是等待部署能力是限制要素而现在更多的情况已经发生变化部署能力已经就绪但是限制要素变成了实际的需求等依赖了。需要注意的是Level 3相较于Level 2按需部署的能力有了明显的下降这也体现了我们所提到的“痛苦的中间阶段”的描述这可能是和安全集成交互在走向成熟的过程中的反复而在Level 4和Level 5就开始重新正向的提升了而Level 5的按需部署能力更是达到了61%而实际的按需部署也达到了34%之高。9、重要安全问题的修复时长调研之前的假定认为安全级别越高修复重要安全问题的时长应该会非常明显的降低而2019年的调查结果却显示并非如此首先很少有受访者能够在1小时之内修复安全问题大多数会在一周之内修复安全问题具体来说只有7%的受访者能够在1小时之内修复安全问题32%的受访者在1小时1天之内修复安全问题33%的受访者在1天一周之内修复安全问题详细按照各个安全级别对于重要安全问题修复的时长的比例统计详细信息如下图所示解读:从这附图中我们可以看到- Level 5的受访者中11%可以在1个小时之内修复重要安全问题相较于Level 2Level 4的6%由于目前整体水平不高还是有较大差距的。- 观察修复时长在1小时1天范围之内的统计信息可以发现Level 1的受访者中有31%能达到此水平而Level 4和Level 5分别能达到38%和39%还是有些许的提升的而中间的下降仍然考虑到是“中间阶段”所带来的反复同时也是由于更多沟通协作的引入在成熟之前显然后拖慢相应的速度显然自动化或者相应的流程改善还有很多余地。10、安全改善 vs 特性交付安全改善肯定是需要做的但是是不是立即要做在现实的世界中往往需要和特性交付进行平衡而需要交付的特性往往是那些已经承诺给客户了的在这种情况下安全集成程度高的公司在这方面能更好地保证安全改善的切实执行这很有可能是因为安全的重要性和其价值已经在这些组织中得到了广泛的共识而在整个DevOps演进的过程中也是这样只有DevOps演进程度更高的公司在实践这些原则的时候才能做的更好。但是这个数据显然还有很多改善的余地比如在安全等级最高的在抉择的时候仍然是49%的选择安全改善51%的仍然会选择特性交付潜台词就是我知道系统这种方式直接交付会有风险但是不按时交付特性我会有风险。特性的交付非常重要忽视安全改善忽视数据安全往往会带来巨大的损失比如美国征信巨头Equifax泄露了高达1.47亿用户的信息被泄漏的信息包括姓名、社会安全号码SSN、出生日期、地址、驾驶证号码等赔偿达到7亿美元。市场竞争激烈当然尽早进行特性的交付能够更好地占得一席之地但是安全同样不容忽视如何进行平衡是需要考虑的重点内容否则一旦出现安全问题也会出现巨大损失同时对口碑也将会有不小的影响。11、为安全改善停止部署经过调研发现安全集成程度较高的公司可以为了对应额各种类型的安全问题更好地停止部署详细信息可以参看下图因为发现了安全的问题停止部署看起来是非常容易的事情但是如果这个流程执行高效的话还需要至少考虑到恢复也能够很快地重新正轨。当然最为重要的还是降低了风险使得系统免受了可能的风险。解读停止部署这件事情背后的意义在于在一个大型的项目之中因安全问题停止部署这样的决定往往是一个中心化的安全团队来做的而现在将能力赋给了交付团队充分体现了分享的另外一层含义责任共担这也是安全集成级别高的团队所体现的一个重要特点所有的团队成员对于安全的意义和责任能充分意识这种做法也避免了传统方式下可能出现的官僚做法。12、安全责任共担在传统的大型组织中安全往往被视作安全团队的责任主要原因是安全是一个比较专业的领域包含的专业知识角度另外思考的方式往往与普通编码作业有所不同更多的考虑代码失败的方式而不是正常动作的方式开发者更为关心如何更快构建和发布新的特性而在安全团队成员来看这可能并不是最重要的。一个整体的安全集成方式可能包含在需求阶段识别的安全需求、编码阶段遵循的安全代码规约、测试阶段的脆弱性持续测试、生产环境的日志和监控。修复的阶段与成本而所有的这些整体的安全集成以及安全责任共担都是为了能在更早的阶段发现安全问题根据IBM的一项研究显示缺陷的修复越早成本越低在实现阶段的成本是设计阶段的6倍而在测试阶段则上升至15倍而部署至生产环境之后此成本则上升至100倍。而对于安全缺陷所付出的成本可能会更高比如一旦攻击者利用生产环境中的漏洞获得现金账户将直接导致实际的资金的丢失的巨大风险另外数据也可能会被卖给竞争对手客户数据的丢失还直接会使地公司被诉讼至法院同时可能会丢失客户的信任和市场的份额这些都不是危言耸听。外部依赖与安全问题另外很容易陷入的一个思维误区就是仅仅考虑代码自身所导致的安全问题而实际上在现代的系统中几乎不可避免的受到各种开源工具或者相关的开发框架以及依赖的影响这些关联的外部依赖是否有安全问题也是系统整体安全所必须考虑的问题。根据Snyk在2019年关于开源安全的调研报告当今软件中整体来说有接近78%的脆弱性问题就是由于这种间接的依赖所导致的所以修复这些关联部分所产生的安全问题显得尤为重要。安全共担的意识调查显示安全集成程度越高对于安全应该是共同承担的责任这一意识的认同度越高从下图的调查统计数据中可以看到Level 1和Level 5之间的差距达到31个百分点之多。无论是安全团队人员还是普通成员对于安全责任共担这一观点基本相同详细比例可参看下图13、安全集成 审计结果在2019年的调查中就安全审计和所确认出来的三类安全性问题的频度进行了确认需要立即更正的问题、需要作为较高优先度更新的问题以及较低优先度需要更新的问题详细内容如下图所示可以清晰地看到审计所能发现的这三种类型的安全问题随着安全级别的生狗都是有一个明显的爬升和回落的状态。解读Level 1基本没有安全相关的集成自然发现的问题较少而Level 5则是较为成熟很多问题在早期阶段就已经处理同时大部分既存的问题也都得到了解决是安全问题本身就很少的成熟阶段而中间阶段是逐渐开始深化安全集成的部分自然会发现很多的问题需要对应这和前面的结论也能够保持一致。14、J曲线效应安全集成的确能够带来正向的效应但是通往成功的道路并非一帆风顺本文已经多次介绍过一些安全集成时的一些J曲线效应本应该上升的趋势却在早期显示为完全相反的趋势只有越过这个阶段才能显示出原本应该显示的趋势2016年的研究报告发现中等绩效者会比低绩效者还要花更多的时间在rework上。2017年的研究报告发现中等绩效者会需要比低绩效者做更多的手工作业解读这都显示了J曲线的效应一旦开始改善打破原有的流程、规范和方式反而可能会带来一定的负面效果套用一句常用的话来进行总结前途是光明的道路是曲折的内心是坚定的。至于卡在中间的探索者能够看到最后的光明还是死在黎明前的至暗时刻这不仅仅是勇气和毅力的考验还有团队的支持和理解都非常重要。团队间的摩擦而关于安全集成是否能够以一种非常和谐的方式进行如下图所示的J曲线再次施展了它的魔力。而J曲线也不因是否是安全团队的成员而改变它的形态解读这也使我们清醒地认识到安全的集成所需要的跨团队的融合在达到成熟之前是无法避免摩擦的存在的所以正视摩擦的存在坚定信心最终是能够跨越这个困难的终结阶段的。拖慢了的交付速度而关于安全集成和软件交付速度之间同样存在类似的问题安全集成成熟度正处在中间的Level 3的受访者有48%认同安全集成是拖慢软件交付的重要原因之一。解读每次当我们觉得已经做好足够心理准备来面对可能会出现的J曲线的反复数据会告诉我们我们还没有做好准备所以当有48%的处在Level 3的身处其中人会认为安全集成和改善确实拖慢了交付速度的时候当我们按照这个节奏成为这48%之中的一员时我们还能否说出前途是光明的道路是曲折的内心是坚定的发现了更多问题J曲线再次不负众望再次告诉我们安全集成并不意味着所发现的问题更少这里我们再次看到熟悉的曲折过程解读实际上这个问题多少已经有所不同直至Level 5仍然比Level 1的程度要高但是这并不是一个问题安全问题就在那儿我们对应还是不对应都改不了它存在的本质把头埋在沙子里或者掩耳盗铃并不是聪明者的做法而且明显地可以看到整体的趋势会向好这才是这个统计结果所反馈给我们的内容。15、理想的组织结构不只是进行安全集成在整体进行DevOps实践的过程中被问到的最多的问题之一大概就是“推动DevOps实践时理想的组织结构是什么样的”目前的答案可能会另很多人失望“需要视情况而定”。确实为了更好地实施DevOps组织结构需要调整成什么样子才更有效率会有很多制约因素比如包括组织文化组织结构的灵活程度团队成员和团队领导者之间的关系职能团队分割的状况团队成员知识技能的实际状况…虽然很难给出答案但是就如同2018年的调查内容一样调查结果本身对我们可能就有一定的参照性2019年根据调查者的反馈根据组织大小不同安全职能相关的组织结构如下图所示而安全集成程度和组织结构的关系如下图所示从中我们可以看到有48%的受访者拥有一个中心化的安全团队对于交付团队提供按需支持的能力超过10亿美金营收的企业这一比例达到57%。有31%的受访者拥有一个中心化的安全职能而交付团队本身也有安全相关的专家成员营收在1亿10亿美金之间的企业这一比例达到46%只有14%的受访者有着去中心化的安全职能结构每个交付团队都有着自己专职的安全专家这种结构对于营收在1百万一下的小型公司中更为常见。解读需要注意的是Level 3中无论是按需的中心化职能从Level 1的57%下降至44%而同时是否有专职的安全专家方面的比例也有了一个非常显著的提升根据调研报告的分析推测大概是在Level 1Level 2的时候这方面并没有足够的资投资而到了Level 3随着安全集成的成熟度的升高对此也越加重视所以团队有了专门的安全专家予以支持听起来也比较合理在2020年后续的调查中是否展开我们也将会继续确认。总结在DevOps的演化中安全的集成和演化发生在较后的阶段这并非偶然跨职能团队的协作和责任共担的理念需要团队不断成熟才能更好地理解和执行安全的融入也是这样就像早期我们打破开发和运维之间的那堵墙一样安全的融入需要同样的方式和原则来打破部门的隔阂虽然不可避免地会出现J曲线的看似反复的曲折过程但是达到成熟阶段的整体方向和趋势是不会改变的。参考内容https://puppet.com/resources/report/state-of-devops-report/https://wiki.owasp.org/index.php/Category:Threat_Modelinghttps://owasp.org/www-project-top-ten/声明本文为CSDN博主「liumiaocn」的原创文章博文链接https://blog.csdn.net/liumiaocn/article/details/104890968。推荐阅读一文了解 Spring Boot 服务监控健康检查线程信息JVM堆信息指标收集运行情况监控
现代编程语言大 PK2020 年开发者关心的七大编程语言
Java 堆内存是线程共享的面试官你确定吗
比特币最主流以太坊大跌区块链技术“万金油”红利已结束 | 区块链开发者年度报告
超轻量级中文OCR支持竖排文字识别、ncnn推理总模型仅17M
用 3 个“鸽子”告诉你闪电网络是怎样改变加密消息传递方式的
真香朕在看了
