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