安全融入所带来的挑战

解读：安全是一个非常重要的概念，需要给予足够的重视，这个想法深入人心，但是在很多项目进行安全实践相关的融合时，都会发现这个想法显得过于理想化，观念上的重视和事实上的轻视在实际的实践中同时被展现了出来。安全增强相较于功能特性的增强，对于企业来说，并不能时时清晰可感，它更像保险，只有安全事故出现的时候才会觉得后悔，所以特性增强一般会排在首位，其次才是安全增强，而实际上排名“其次”的第二名永远都得不到足够的重视，后面我们也将会使用一些数据来佐证这个观点。

在这份告中，对企业在实施DevOps转型时如何进行安全融入、以及安全融入对企业的产出的影响，都在告中给出了结论。

内容概要

DevOps的实施会对安全带来正向影响

一般来说，需要在DevOps实践中进行安全融入的企业都是那些已经走过初期阶段企业，DevOps的实践已初见成效，需要在整个企业内部进行展开，这种情况之下，自然需要在安全上进行进一步的强化。

解读：在2019年的调查告中，DevOps实践很好的团队之中有高达22%的比例达到了安全集成的最高级别。DevOps的CAMS在安全的融入方面同样起效，可靠性、可预测性、可测量行和可观测性不仅仅带来了安全的环境，更为重要地是将这一切结合了自动化之后所带来的安全事件响应速度的效率提升。
好的DevOps文化能够支持更严格的安全策略的贯彻执行，在有着Sharing（分享）的文化的团队之中，团队使用通用的工具，合力完成共同的目标，安全也自然成为了一种共同的责任，在这种文化之下，“部门墙”会相对更为容易跨越，在问题出现的时候，自然也会得到最早地解决。

在软件交付中深度集成安全使得团队更加自信

根据调查告显示，安全级别达到最高级别的受访者有82%对公司的安全有足够信心，而没有进行安全集成的受访者中，这一比例仅达到38%，这一调查结果充分显示在软件交付中，深度集成安全使得团队更加自信。

解读：集成安全并不只是简单的“左移”，而是需要从整体上进行解决，比如强调跨团队的协作、增强自动化在检测和预防方面起到的作用，同时需要打破部门之间的知识孤岛，使得成员都能够参与进来。在安全改进方面使用的最为广泛的几种实践如下所示：

团队协作：基于威胁模型分析，安全团队和开发团队增强合作应对安全威胁

工具集成：安全工具集成到开发的流水线中，可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。

安全需求：从功能性和非功能性综合考虑，将安全相关的需求列到产品任务清单中。

人工评审：从安全专家的角度对于自动化测试进行评估，重点包括那些具有较高风险的代码变更内容，比如认证和加密相关部分。

基础框架安全：与基础框架相关的安全策略需要在部署之前进行评审。

重点：所有的这些内容大多数公司都知道应该做，但是往往因为种种原因却没有去做，这是一种普遍的情况。

在软件交付生命周期集成安全会带来积极结果

调查告发现：

生产环境的按需部署效率提升：安全集成级别较高的受访者所在公司在按需进行生产环境部署方便达到了61%的比率，而安全级别较低的受访者所在公司在这一比例仅能达到49%。
修复时间相差不大：调研之前的假定认为安全集成级别较高的公司能够更快部署、更快修复安全性问题，但是实际反馈结果显示在修复问题的时间方面目前相差无几。
安全改善效率更高：安全集成级别较高的公司能够在进行功能特性交付的时候更加有效的强化安全改善，在发现交付只生产环境处理安全问题时的处理更有效率。

解读：在软件交付生命周期中安全集成地越深入，交付团队对于团队共同安全责任的理解更加清晰，同时对于对于潜在的对于业务的风险也会降低地更多，安全问题也会得到更多的重视。

中间过程可能会是混乱和难熬的

正像DevOps个别的成功推广开来碰到的问题一样，中间的阶段和过程可能是混乱无序、非常难熬的。在项目刚开始的时候，很多未知的问题和障碍还未出现，还没有大面积普及的情况下，往往较为顺利的看到了预定的结果，但是很快随着集成的深入，很多问题就会出现，这就是非常难熬的中间阶段。安全集成也是这样，往往解决了一个问题，就会引入一个新的问题，我们不知道这漫长的中间阶段到底有多长（不过根据经验来看一般比想象的要短，但是难熬的日子往往觉得很漫长）。比如如下是2018-2019年的中间阶段的企业的比例构成：

解读：按照国家来确认，中国的反馈占到这19%的8%，所以这份调研告所能体现出中国在其中的比例大概为1.5% （19% * 8 % ），所以这又是一份基本不能代表2019年中国DevOps最新发展状况的数据，但是对于整体的发展趋势可以有所了解。

行业与规模

角色

受访者仍然以管理人员偏多，IC（Individual Contributor）仅占26%，这一比例很巧合地跟2018年完全一致，其他成员的比例也大体相差无几。

解读：看似下降的比例，但是考虑到如下三部分都属于DevOps的范围，比例已经为22% + 4% + 2% = 28%

Site reliability engineering：4%

Release engineering：2%

DevOps：22%
同时在2019年重点融合的安全相关的部分，也同样可以认为是DevOps团队的延伸，所以结合起来仍然在进一步上升，名称可能有所变化，但是方式和职责明显是更为细化和清晰。

Information security / security operations：6%

Compliance & audit：1%

DevOps实践中的安全集成

DevOps的演进模型中的安全集成

在2018年的告中提出了企业在DevOps演进时的5个阶段的模型如下所示：

DevOps演进 & 安全集成

2019年度关于安全集成和DevOps演进的结论:
DevOps演进能够更好地推进安全实践的落地，对于希望对于安全进行改善的组织，继续践行DevOps是一个不错的主意。

安全集成级别

安全集成的级别界定方法

对于受访者安全级别的界定，2019年度是通过对于问卷的内容进行设计来达到的，首先需要确认安全在软件交付周期的哪些环节被引入：

需求
设计
构建
测试
部署

根据受访者在上述环节安全被引入的状况来界定安全集成的等级：

Level 1: 无集成（在任何一个阶段都未进行安全集成）
Level 2: 较低程度集成（在一个阶段集成了安全）
Level 3: 一般程度集成（在两个个阶段集成了安全）
Level 4: 较高程度集成（在三个或者四个阶段集成了安全）
Level 5: 最高程度集成（在所有阶段集成了安全）

虽然重点研究落在了软件交付之上，但是从运维角度关于生产环境中安全集成方面也在如下的一些环节进行了确认：

脆弱性管理与修复
安全策略自动化
审计发现与响应

安全集成现状

通过对于受访者的反馈进行分析，各个级别的比例分布大体如下所示

行之有效的实践建议

告中还列出了一些对于安全集成有效的实践建议，可以在使用时进行参照：

团队协作：基于威胁模型分析，安全团队和开发团队增强合作应对安全威胁
工具集成：安全工具集成到开发的流水线中，可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。
安全需求：从功能性和非功能性综合考虑，将安全相关的需求列到产品任务清单中。
人工评审：从安全专家的角度对于自动化测试进行评估，重点包括那些具有较高风险的代码变更内容，比如认证和加密相关部分。
基础框架安全：与基础框架相关的安全策略需要在部署之前进行评审
主要变更评审：对于主要的代码变更在部署之前进行安全人员评审
安全特定的测试：对于安全相关的特定测试，比如测试应用的使用权限和数据访问权限等。
自服务：开发者可以配置按需进行包含安全设定的基础框架和环境
设计融合：安全需求被视作普通的设计需求进行处理
轻微变更评审：对于轻微的代码变更在部署之前进行安全人员评审
安全评审：应用代码发布至生产环境后出发安全评审
渗透测试：包含并不仅限于脆弱性相关测试或者黑客工具测试等
基础框架配置：基础框架可以进行在安全审批的流程基础上进行自动化配置
依赖检查：对于应用和环境进行相关的依赖检查以确认整体的安全性状况
静态代码分析：使用静态代码分析工具对于应用进行安全性和脆弱性问题的检查

经验总结

基于威胁模型的团队协作
来自于交付团队、安全团队和业务关系人等各方人员一同对于安全相关的威胁常见威胁模型，并进行分析，以确认应用和支持应用的基础框架所潜在安全风险，以及出现问题时相关的应对措施。威胁模型有助于在项目最早期的阶段进行规划和设计，同时有助于在开发团队、安全团队以及业务团队之间建立信任和同理心。
工具集成提升开发团队的信心
工具并不能解决所有的安全问题，也不存在一个解决所有安全问题的工具，但是可以通过集成工具将例行繁琐的任务进行自动化以提高效率和节省时间，比如可以将静态安全工具的检查对于安全相关的脆弱行的分析进行例行的集成，通过这些工具的集成使得开发成员在开发阶段就可以快速定位可能存在的风险，而在这个阶段进行修改的整体成本也是较低的。
在敏捷迭代过程融合安全
随着敏捷理念的深入人心，代码的发布也正在使用一个小而快的方式在迭代周期中不断进行。敏捷方式有助于持续学习和改进，但是对于传统方式下的安全需求的实现则较为困难，因为传统方式往往安全策略的检查等都是手工方式，另外开发团队内所缺少的安全相关知识和经验才是最重要的问题，而实际上这也是融合时的难点所在，有了这样的团队成员在定义敏捷的DoD的时候才有可能将安全需求以可验收的方式提前指定，才能真正地在敏捷开发中融合安全需求。由于大型企业往往是有一个统一的中心化的团队来对所有应用开发团队的交付安全进行统一管控，所有很难保证每个项目都有自己的专门安全人员，所以一个较为折中的方式则是鼓励开发团队成员或者运维团队成员能够具备这方面的知识以帮助团队在快速的迭代中能够进行性安全的融合。
基础框架相关的安全评审
使用诸如CIS Benchmark这样的参考，对于进行基础框架相关的评审是一个不错的想法，但这是一个开始，每个项目的基础框架都有可能不同，这就需要安全团队和运维团队一同协作，在部署之前对于基础框架的变更或者引入可能会导致的各种问题进行知识和经验的交换，并在此基础上进行深入探讨和评审以保证部署的安全性。
对高风险的代码变更进行安全专家的评估和自动化测试
传统方式下，应用只有在UAT或者准生产环境中，可会受到安全团队的手工确认，如果将此部分的内容进行左移，在更早的阶段由开发这能够通过检查或者自动化测试确认这些风险和不合适的配置，修改的成本将会更低。由于脆弱性的存在有非常广泛的可能性：三方组件、服务器、数据库、络设备、防火墙、云存储等，为了防止被攻击，我们需要跨团队（比如包括开发、运维、络、存储、中间件、云计算等）进行深入的知识共享以确保我们的检查和自动化测试是与时共进的，而这些自动化的检查和测试也将安全人员从琐碎的工作中解放出来，可以一起完成一些根据有意义的工作，比如：
- 和交付团队一起协作确保和测试应用以保证安全性
- 给予错误的配置已反馈以避免类似的错误配置重复出现
- 对于高风险的代码变更进行安全相关的评审

解读：从反馈的结果来看也能看到即使是没有做任何安全集成的组织，也可以做到按需部署或者至少一天两次的这种能力，相较于8年之前的调研结果已经发生了翻天覆地的变化，当时部署甚至仍然是按照月的单位来进行衡量的。部署频度稳定地得到了提升，在2017年高能效的组织就可以实现一天多次的部署了，之前是等待部署能力是限制要素，而现在更多的情况已经发生变化，部署能力已经就绪，但是限制要素变成了实际的需求等依赖了。
需要注意的是Level 3，相较于Level 2，按需部署的能力有了明显的下降，这也体现了我们所提到的“痛苦的中间阶段”的描述，这可能是和安全集成交互在走向成熟的过程中的反复，而在Level 4和Level 5就开始重新正向的提升了，而Level 5的按需部署能力更是达到了61%，而实际的按需部署也达到了34%之高。

重要安全问题的修复时长

调研之前的假定认为安全级别越高，修复重要安全问题的时长应该会非常明显的降低，而2019年的调查结果却显示并非如此，首先很少有受访者能够在1小时之内修复安全问题，大多数会在一周之内修复安全问题，具体来说：

只有7%的受访者能够在1小时之内修复安全问题
32%的受访者在1小时～1天之内修复安全问题
33%的受访者在1天～一周之内修复安全问题

详细按照各个安全级别对于重要安全问题修复的时长的比例统计，详细信息如下图所示

解读：停止部署这件事情背后的意义在于，在一个大型的项目之中，因安全问题停止部署这样的决定往往是一个中心化的安全团队来做的，而现在将能力赋给了交付团队，充分体现了分享的另外一层含义：责任共担，这也是安全集成级别高的团队所体现的一个重要特点，所有的团队成员对于安全的意义和责任能充分意识，这种做法也避免了传统方式下可能出现的官僚做法。

安全责任共担

在传统的大型组织中，安全往往被视作安全团队的责任，主要原因是，安全是一个比较专业的领域，包含的专业知识角度；另外，思考的方式往往与普通编码作业有所不同：更多的考虑代码失败的方式而不是正常动作的方式；开发者更为关心如何更快构建和发布新的特性，而在安全团队成员来看，这可能并不是最重要的。一个整体的安全集成方式可能包含：在需求阶段识别的安全需求、编码阶段遵循的安全代码规约、测试阶段的脆弱性持续测试、生产环境的日志和监控。

修复的阶段与成本
而所有的这些：整体的安全集成以及安全责任共担都是为了能在更早的阶段发现安全问题，根据IBM的一项研究，显示缺陷的修复越早成本越低，在实现阶段的成本是设计阶段的6倍，而在测试阶段则上升至15倍，而部署至生产环境之后此成本则上升至100倍。而对于安全缺陷，所付出的成本可能会更高，比如一旦攻击者利用生产环境中的漏洞获得现金账户，将直接导致实际的资金的丢失的巨大风险，另外数据也可能会被卖给竞争对手，客户数据的丢失还直接会使地公司被诉讼至法院，同时可能会丢失客户的信任和市场的份额，这些都不是危言耸听。
外部依赖与安全问题
另外，很容易陷入的一个思维误区就是仅仅考虑代码自身所导致的安全问题，而实际上在现代的系统中，几乎不可避免的受到各种开源工具或者相关的开发框架以及依赖的影响，这些关联的外部依赖是否有安全问题也是系统整体安全所必须考虑的问题。根据Snyk在2019年关于开源安全的调研告，当今软件中整体来说有接近78%的脆弱性问题就是由于这种间接的依赖所导致的，所以修复这些关联部分所产生的安全问题显得尤为重要。

安全集成 & 审计结果

在2019年的调查中就安全审计和所确认出来的三类安全性问题的频度进行了确认：需要立即更正的问题、需要作为较高优先度更新的问题以及较低优先度需要更新的问题，详细内容如下图所示：

解读：每次当我们觉得已经做好足够心理准备来面对可能会出现的J曲线的反复，数据会告诉我们，我们还没有做好准备以当有48%的处在Level 3的身处其中人会认为安全集成和改善确实拖慢了交付速度的时候，当我们按照这个节奏成为这48%之中的一员时，我们还能否说出：前途是光明的，道路是曲折的，内心是坚定的/p>

有48%的受访者拥有一个中心化的安全团队对于交付团队提供按需支持的能力，超过10亿美金营收的企业这一比例达到57%。
有31%的受访者拥有一个中心化的安全职能，而交付团队本身也有安全相关的专家成员，营收在1亿～10亿美金之间的企业这一比例达到46%
只有14%的受访者有着去中心化的安全职能结构，每个交付团队都有着自己专职的安全专家，这种结构对于营收在1百万一下的小型公司中更为常见。

解读：需要注意的是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/

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

2019年DevOps最新现状研究 告解读