浅谈企业 DevSecOps 实践:基本原则
导语:Devops 是一个操作框架,通过自动化来促进软件的一致性和标准化。 通过打破不同开发团队之间的障碍,同时通过优先考虑使软件开发更快更容易的事情,该框架帮助解决了围绕集成、测试、修补和部署的许多噩梦般的开发问题。
Devops 是一个操作框架,通过自动化来促进软件的一致性和标准化。 通过打破不同开发团队之间的障碍,同时通过优先考虑使软件开发更快更容易的事情,该框架帮助解决了围绕集成、测试、修补和部署的许多噩梦般的开发问题。
DevSecOps是将安全团队和安全工具直接集成到软件开发生命周期中,利用 DevOps 的自动化和效率,确保每个构建周期都进行应用程序安全测试。 这促进了安全性、一致性,并确保安全性与其他质量指标或特性同样重要。 自动化的安全性测试,就像自动化的应用程序构建和部署一样,必须与基础设施的其余部分一起组装。
但这就是问题所在。 软件开发人员传统上并不支持安全性。 这并不是因为他们不关心安全问题,而是因为他们被激励着去关注新特性和功能的交付。 DevOps 正在改变自动化构建过程的优先级,使它们更快、更容易和更一致。 但是,这并不意味着他们会特意加入安全或安全工具。 这通常是因为安全工具不容易与开发工具和流程很好地集成,通常带有非智能发现的大量队列,并且缺乏以开发为中心的过滤器来帮助优先化工作。 更糟糕的是,安全平台——以及推荐它们的安全专业人员——很难使用,甚至无法提供 API 层支持来提供集成。
另一方面是安全团队,他们害怕自动化的软件过程,通常会问“我们如何控制开发”这样的问题。 这个问题的本质既忽略了 DevSecOps 的精神,也忽略了开发组织为使每个软件版本更快、更高效和更一致所做的努力。 对于安全团队来说,应对软件开发中发生的变化,并扩展他们相对较小的组织的唯一方法,就是变得和开发团队一样敏捷,并且拥抱自动化。
为什么我要写这篇文章?
我们通常讨论我们做研究背后的动机,以帮助读者理解我们的目标和我们希望传达的内容。 当我们更新一份研究报告时,情况就更加复杂了,因为它有助于我们聚焦最近行业的变化,这些变化导致旧的论文在描述最近的趋势方面存在不准确或不足的问题。 由于 DevOps 和 DevOps 选项在四年内已经相当成熟,所以,关于这一方面我们有很多要谈的。
这项工作将是对我们2015年关于将安全构建到 DevOps 中的研究工作的重大改写,包括围绕安全团队询问的关于 DevSecOps 的常见问题的重大增补,以及对集成工具和方法的彻底更新。 这篇研究论文的大部分内容将反映的是2017年以来财富2000强公司的200多个安全团队的400多次谈话。 因此,我们将包括更多从这些对话中衍生出来的讨论要点。 由于 DevOps 已经存在了很多年,很少有人讨论什么是 DevSecOps 或者它是如何对我们有益的,更多的是关于如何组合一个 DevSecOps 程序的务实的讨论。
现在,让我们改变一下。
不同的焦点,不同的价值
有大量的新的调查和研究论文可用,其中一些是非常好的。 还有更多的会议和在线资源涌现出来,资源多到我都数不过来了。 例如,Veracode 最近发布了他们的软件安全状态(SoSS)报告的最新版本,这份报告是一个大部头读物,带有大量的数据和观察。 关键的要点是 DevSecOps 团队使用的灵活性和自动化提供了明显的安全优势,包括更快的修补周期,更短的缺陷持续时间,更快的减少技术债务,以及更容易的扫描意味着更快的问题识别。 最近发布的2019年软件供应链状态报告显示,团队表明,模范项目团队利用 DevOps 原则大大降低了代码部署失败率,补救漏洞的时间只有平均水平的一半。 我们还有像全天 DevOps 这样的活动,数以百计的 DevOps 从业者在这里分享关于文化转型、持续集成 / 持续部署(CI: CD)技术、站点 / 可靠度以及 DevSecOps 的故事。 所有这些都很棒,并且提供了一系列定性和定量的数据来说明为什么 DevOps 工作以及从业人员是如何演变他们的程序的。
这不是这篇文章的主题。 这些资源并没有解决我每周都被问到的问题。
注意,本文是关于整合一个全面的 DevSecOps 程序。 因为我们总是被问到“我如何把一个 DevSecOps 程序组合在一起? ” 以及“安全性与 DevOps 有什么关系? ” . 他们不是在寻找正当理由,也不是在寻找关于细微差别的故事来解决具体的障碍。 他们需要一个与同行组织保持一致的安全程序,并拥护“安全最佳实践”。 这些受众绝大多数是安全和 IT 从业者,很大程度上被开发团队所遗忘,他们至少接受了敏捷概念,如果不是完全接受 DevOps 的话。 面临的挑战是理解开发试图完成什么,以某种方式与这些团队集成,并弄清楚如何利用自动化安全测试,使其至少像开发团队一样敏捷。
DevOps vs DevSecOps
这就引出了另一个有争议的话题,以及为什么这项研究与众不同: DevSecOps 这个名字。 我们的论点是,鉴于在这个问题上缺乏成熟和理解,调用安全性(“ DevSecOps”中的“ Sec”)是必要的。
换句话说,完全支持这一运动的 DevOps 实践者会告诉你,没有理由在 DevOps 中加入 Sec,因为安全只是另一个因素。 DevOps 的理想是打破单个团队之间的隔阂(例如: 架构、开发、 IT、安全和 QA) ,以更好地促进团队合作,更好地激励每个团队成员朝着相同的目标前进。 如果安全性只是融合在构建和交付软件的总体工作中的另一组技能,那么我们就没有理由称之为质量保证。 从哲学上讲,这些支持者是对的。 实际上,我们还没有到那个地步。 开发人员可能会接受这个想法---- 他们通常不擅长促进团队集成。 当然,安全是可以自由参与的,但这取决于他们了解在哪里可以集成,并通常要求将他们可能不具备的技能带到聚会上。 这是被动攻击型的团队建设!
自动化的安全性测试,就像自动化的应用程序构建和部署一样,需要时间和技能来构建。 在我们与客户的典型约定中,开发人员不参与调用。 分歧仍然存在,安全性和通常有几十到几百个分散的开发团队之间几乎没有交流。 当开发人员在场时,他们声明安全团队可以创建脚本,将安全测试集成到构建服务器中; 他们可以编写安全策略; 安全可以将安全分析工具与故障检测以及几行 python 代码的度量结合在一起。 毕竟,许多 IT 从业者正在学习为组态管理编写脚本,并构建模板来定义基础设施部署,那么为什么不提供安全性呢? 这完全忽略了一个事实,即很少有安全从业人员能够在这个级别编写代码。 更糟糕的是,与我们交谈的大多数公司的开发人员与安全从业人员的比例约为100:1,而且根本没有办法在所有开发项目中扩展安全资源。
许多安全专家在理解 DevOps 的早期阶段,以及开发人员在过去十年中为了变得更加敏捷而采用的各种方法,这些都无济于事。 安全确实落后于形势,而且似乎现有的大部分研究(上文提到的)并不是为了解决安全的引入和整合问题。
最后,我们选择使用 DevSecOps 名称还有一个非常重要的原因: 代码安全方面的安全工作与基础设施和支持组件的安全工作非常不同。 用于验证应用程序代码的安全性检查是安全的(即: DevSec) ,但与使用的工具和过程不同,它们用于验证支持基础架构(即: SecOps)是安全的。 这是两个不同的规程,具有不同的工具和方法,应该作为单独的工作进行讨论。
常见问题
我们检查了过去三年所有的电话记录,并记录了我们被问到的问题。 下面的列表是最常见的问题,按问题被问到的频率排序如下。
· 我们希望将安全性测试集成到开发管道中,并将从静态分析开始。 我们该怎么做?
· 我们如何根据自动化、 CI: CD 和 DevOps 构建应用程序安全策略?
· 如何开始构建一个应用程序策略? 我应该遵循什么应用程序安全标准?
· 开发部门每天都在向生产环境发布代码。 我们如何控制开发? 我们真的能够改变开发人员的行为吗?
· 引入 DevSecOps 的最佳方式是什么? 我该从哪里开始呢? 最基本的部分是什么?
· 当现在有些是瀑布式的,有些是敏捷的,有些是 DevOps 的时候,我们如何让不同的单位采用同一个程序(不同的团队做事情的方式不同) ?
· 我们(安全)应该如何与开发人员一起工作?
· 我们理解左移,但是这些工具有效吗? 你建议从哪些工具开始呢?
这些问题都有一些共同的线索; 它们都来自至少有一些 DevOps 团队已经到位的公司,安全部门对 DevOps 的意图有一些了解,但是它们都是从零开始的。 即使已经在开发管道中内置了安全测试的团队也在为每个工具提供的价值、开发人员对于误报的抵触、如何与开发人员合作或者如何在多个开发团队之间进行扩展以保持一致性而苦苦挣扎。 我们发现,在调用和约定期间,安全人员与开发人员接受 DevOps 的原因并不完全一致,并且错过了工作的重点,这就是为什么它们通常不同步的原因。
以下是我们提出的安全性问题清单,安全团队应该问这些问题,但是没有解决。
· 我们在文化上和操作上如何适应 DevSecOps?
· 我们该如何使开发和开发实践具有可见性?
· 我们如何知道变化是有效的? 我们应该收集和监控哪些指标?
· 我们该如何支持开发部门?
· 我们需要知道如何编码吗?
在本系列课程中,我们将讨论这两个问题列表。 接下来,我们将简要介绍 DevOps 原则和安全在 DevOps 中的作用。
发表评论