Home Blogs DevSecOps:向左移动以避免产品路线图向右移动- Edgio
Applications

DevSecOps:向左移动以避免产品路线图向右移动- Edgio

About The Author

Outline

欢迎观看Beyond the Edge的第四集,这是一个专门探讨现代数字企业所面临的动态挑战的播客。

在本集中,我们的主持人全球营销活动经理Lauren Bradley与Michael Grimshaw Edgio的平台工程总监以及Edgio安全平台产品管理高级总监Richard Yew讨论了向左移动的问题。 具体而言,文化和技术如何随着Web应用程序和API保护而发生变化,这将成为DevOps生命周期的固有组成部分。

"安全就像面粉一样让你烘焙蛋糕,当安全做得好时,你看不到它。 安全的整体要点是,当它做得好时,它应该已经被烘干,而不是可见的。"

Edgio《超越边缘》播客第4集:DevSecOps:向左移以避免产品路线图向右移动》由Edgio全球营销活动经理Lauren Bradley主持。

Lauren Bradley: 嘿,欢迎来到Beyond the Edge,在这里,我们深入了解现代数字业务。 我是Lauren Bradley,您是本集的合作飞行员。今天,我们将探讨”向左移”主题,特别是文化和技术变革如何成为Web应用程序和API保护成为DevOps生命周期的固有组成部分。

让我们先从Ponemon Institute的一个令人震惊的统计数据开始。 如今,大多数公司甚至需要200多天的时间才能检测到漏洞。 如果您检测到漏洞的速度不够快,您将付出巨大的代价。 IBM发现,在测试阶段发现的修复错误的成本比在设计阶段发现的成本高15倍。

简单地说,您等待时间越长,发现问题的成本就越高。 而且,我们所谈论的不仅仅是金钱,返工,时间和能源,最终会使产品路线图倒退。 那么,您如何有效地向左转,避免浪费宝贵的资源和阻碍您的进步?

今天加入我们的还有Edgio的平台工程总监Michael Grimshaw和Edgio安全平台产品管理高级总监Richard Yew。 欢迎,Michael和Richard。 很高兴能让你继续。

Michael Grimshaw: 谢谢你,Lauren。 很高兴来到这里。 谢谢你。

Lauren Bradley: 你们能告诉我一些关于你们自己和你们对这个话题的初步想法吗? Mike,我们将从您开始。

Michael Grimshaw: 绝对的。 首先,我要感谢劳伦先生对我的关心。 在这个非常重要的话题中,您正在深入探讨和深入探讨我们已经和正在围绕这个话题进行的对话,包括今年的讨论,对于我们在行业中所做的工作来说,这是非常宝贵和必要的。

Michael Grimshaw: 这种理解需要广泛地分享,并真正欣赏的兴趣。 我叫Michael Grimshaw。 我是Edgio的平台工程总监。 对于那些不熟悉或非常熟悉该平台的行业术语的人来说,它实际上是在考虑将您的应用程序和基础设施统一为一致的单元。

我来到这个平台时有着沉重的安全背景,这是一个我非常感兴趣的领域,因为它在安全性,盈利能力等方面有着巨大的推动力, 以及许多对我们的行业如此重要的领域。

我可以继续介绍DevSecOps,但让我将其交给Richard进行介绍。

Richard Yew: 非常感谢你,Michael。 是的。 是的。 这是一个非常重要的话题。 这在我心中是非常接近和亲爱的,因为我个人经历了整个软件开发生命周期的过程,并将这些转化为业务.

现在,我说什么… 显然,正如Lauren所说,我在Edgio负责我们的安全产品管理组织。 因此,我的日常生活涉及与研发团队,工程团队合作,以切实确保我们为客户提供价值。 而且,显然包括的一切包括优化我们的开发实践,我们的安全性,CI CD实践。 确保我们能够真正提供安全的产品。

对。 这实际上为我们的客户提供了价值,按时,按预算交付客户,并确保我们为客户提供出色的体验。 因此,我的观点是从人员的角度真正审视整个DevSecOps -流程而非技术,以及我们如何实际实施行业的最佳实践

什么是DevSecOps?

Michael Grimshaw: 你的观点,理查德,如果你不介意的话,让我去偷球吧。

我想让我们对DevSecOps的含义进行标准化,并向左移,对吧? 有Gartner,下面是一些人在这个DevSecOps中的想法,术语”向左移动”,”向右移动”等听起来相对较新。 这不是新的,你知道,它不像,哦,最新的最热的东西刚刚击中一年前.

不,这已经在这个行业烘焙了很长一段时间。 事实上,Gartner在2017年发布了一份关于DevSecOps生命周期的报告。 实际上是DevOps的延伸,也是业界的DevOps趋势,只是扩展到将信息安全纳入反馈循环和您的软件开发生命周期中。

所以,正如我所说的,Gartner在2017年就在写这篇文章,这已经是行业中的一个过程和一场运动。 在那之前有很长一段时间。 所以,这些并不是全新的概念。 这只是我们多年工作成果的延伸。 实际上,DevSecOps就是采用类似的DevOps模型,因为您有开发方面,实际上也有操作方面。

关键是要尽快满足您的所有安全需求,我的意思是,从设计的开始,构建整个过程,直到您的开发人员在船上的开发阶段,打扰我, 向右移动在操作可观察性方面更重要。 今天我们将重点放在左侧偏移上,但它基本上是在您测试扫描和验证时烘焙,早在最左侧。 尽可能早地在SDLC的开发生命周期中。 例如,其中一个话题就是, 而且,这可以追溯到七年前,比如安全,扫描和扫描您的开源第三方库,存储库,代码库,以及您编写的代码,设计,架构,整个九码码,并从一开始就加以利用。 我给出的一个例子就是构建和安全扫描到您的开发人员使用的IDE中。 这只是一个例子,有很多。

因此,当他们编写代码时,他们会立即得到反馈。 哦,我只是打开了一扇门,你知道,撞库或续集注入,它们就像一个语法错误,它们得到了一个安全错误,就在编写代码的时候。 因此,他们可以立即解决这个问题,这样他们就不会有客户抱怨客户或最终用户被打了,一个月后,不会,就在那里处理。

最便宜的,最快的,最简单的开始。 “你要和我说什么?

在成本方面,为什么向左移动如此重要?

Richard Yew: 哦,是的。 是的。 就像我认为成本实际上是非常重要的,你知道,每个人都知道很多运营成本,你知道,任何组织,它就像开发一样,对吗? 研发过程。

因此,就成本而言,这就是为什么向左移动更重要的原因,对吧? 因为我们付出了大量的努力,并在谈论为什么,我相信我们将在稍后讨论”如何”,但我们想谈谈为什么这一点如此重要,因为我们有数据。

是的。 根据我们的研究,您知道,如果要修复在您发布代码和产品后发现的安全漏洞,其成本是您在进行威胁加载时在设计阶段发现的成本的15倍。 显然,我们并不是说您知道,开发工作的早期阶段将完全捕获所有安全漏洞。

这就是为什么我们需要实施深度防御。 但很重要的是,当你看着八个阶段,你知道,一般来说,债务周期,生命周期,从,你知道,计划,代码, 构建,测试,一直喜欢监控和操作。 对。 您越靠近它们,您就会看到它们,比如当您发现安全漏洞时,成本就越高,您知道。

让您的组织真正解决问题。 所以,我们在谈论的是在扫描中发现漏洞的区别,这种漏洞发生在您已经向产品发布了一堆代码之后,而不是说,您知道, 就像在暂存环境中执行动态应用程序安全任务,在将该代码发布到产品之前就实际检测到它一样,对吗?

Richard Yew: 您可能能够修复这些问题,或者在发布代码缩减之前提前实施某种虚拟修补以缓解这种情况。 但是,同样重要的是,在您将任何内容放入IDE并开始考虑进行威胁建模之前,您必须从该过程的第一步就充分了解安全性。 嘿,设计的哪个部分可能容易被利用?

对DevOps和安全团队的日常影响

Lauren Bradley: 是的,这些都是很好的点,你们。 我的意思是,从用户的角度来看,除了成本之外,如果DevOps或安全团队一开始没有实现这一权利,他们的日常体验意味着什么?

此外,我还想谈谈我们如何在DevOps生命周期中有效地实施它。

Michael Grimshaw: 很好的问题。 问得好。 让我在最初的回应中直言不讳。 是行业中的每个人,每位CEO,CTO,CFO–每个人,工程师, 用户–我们都想要的只是一个神奇的子弹,我们可以做什么,我们每天做什么.

然后,我们有一个神奇的安全子弹,您只需按下开关,您的所有工作就会突然变得安全。 这是每个人都想要的,但这不是现实。 这就是,你知道,人们问我们。 我想问他们,幻想之地的天气怎么样? 我听说这很好。 这种类型的一年是,如果你接近你的安全,你的信息,以及你的发展,因为这只是一个螺栓固定式. 您知道,”哦,我打算购买一些工具,在我们开发,构建和部署了所有产品之后,我将会购买这些工具,而且这些工具将继续下去,确保所有产品的安全。”老实说,您购买的是非常昂贵的纸质产品。

这就是为什么我们提到的人,流程, 和工具。 这就是为什么这种办法的连贯性的整体如此重要。 是你,我们是遥远的岁月,几十年,如果它曾经是可能的。 老实说,我们从您的想法中学到了很多经验教训,您只需设计一些东西并使用安全工具,您就可以开始了。

它会影响一切,从您的成本到开发人员的速度,再到客户的成本。 这方面的一个很好的例子是我的怀疑是,几乎每一个在其职业生涯的某个时刻收听此播客的人都处于一种新功能或新服务或类似的情况,甚至只是部署了修补程序和更新。 一切看起来都很好。 一切都运行良好。 然后突然你接到一个客户的电话或信息从其中一个客户得到一个电话。 “我们刚刚受到攻击”,”我们刚刚发生了安全事件”或类似情况。 原因是,好的,你已经部署了它,但也许扫描没有完成运行,或者你没有进行扫描,或者你没有对它们进行适当的调整,你刚刚引入了一个巨大的安全漏洞。

也许它会影响您,但更重要的是,它会影响您的客户。 DevSecOps是要在一个连贯的过程中将所有这些结合在一起并避免这种情况。 这是关于成本削减。 当然可以。 是为了提高利润吗? “哎呀,都怪我不好。 但这也是关于消除你的公司和你的客户的责任.

将安全性融入DevOps–就像做蛋糕一样!

Richard Yew: 是的。 你知道,说到烘焙,你知道,就像迈克使用了这样一个词”连贯的整体”。 这是真的。 这是非常强大的,这是一个非常有力的词来表明为什么把那个烘焙到位是非常重要的,你知道,就像我在Edgio中被称为是一个类比的家伙一样。

我喜欢把一堆类比放在周围,我听说过这很棒。 我认为类比可以作为在任何组织内推动正确文化的坚实基础,我们都知道,作为安全人员,我们工作的一个重要部分是传福音。 这不仅仅是实施正确的技术和创建流程,还真正做了大量的内部营销工作。

告诉人们安全对企业很重要,对吧? 因为,作为安全领导者,人们通常会想到安全问题,比如在工作流中添加额外的流程层,但您知道,考虑这一点的正确方法是安全如何加速业务?

安全如何真正带来更多的收入,因为这是证明许多安全(您知道,为了确保组织的安全而必须实施的额外安全实施)合理化的好方法。 所以,我听到的一个很好的比喻是,你知道,安全不应该被当作蛋糕上的糖衣,你知道,你是如何烘干蛋糕的,只是把所有的糖衣作为最后一步,你知道, 这通常是人们在没有安全性(ICD工作流)时所做的事情,他们只是在生产阶段的最后一个阶段实施防火墙和API保护。 它应该是什么,安全,它就像面粉,你知道,它, 这应该是从一开始就有的东西。

安全就像面粉为你烘烤蛋糕。 然后,当安全措施到位时,您就看不到它了。 安全的重点是当它做得好的时候,它应该已经被烘干了,它是不可见的。 它不应造成挑战。 它不应使组织减速。

就像类比一样,我曾经帮助向企业展示为什么这很重要,因为拥有强大的安全流程和安全技术文化,就像拥有强大的制动器一样。 在一辆赛车中,你知道为什么所有超级跑车都有大的,非常大的,奇特的刹车,因为它可以让它们更快地转弯。

它允许他们硬制动。 它可以让他们更快,更艰难地转向,对吧? 它让他们赢得比赛。 因此,拥有强大的制动器与拥有强大的发动机同样重要,对吧? 这就是我们应该从哲学角度看待安全问题的方式。 你知道,很明显,我们谈论了很多高水平,对吧? 所以,我们显然想更深入地了解这一点。 这句话的要点是,好的,这一切都是好的,但是我们到底要如何实现这一点呢?

Michael Grimshaw: 是的。 我认为这是一个很好的呼吁是制动。 强力制动让您掌控一切。 我们前面的道路充满了曲线,急转弯,所有这些,当然,在地板上有直线,不会碰到制动器,但要驾驭一切,我认为,制动器,我很喜欢, 我喜欢这两个类比,理查德,因为这种制动类比,它给你控制,它给你更精细的粒度控制,当你面临的是路缘,挑战,和意想不到的事情。

Richard Yew: 伟大的呼吁。 顺便说一句,我想澄清,我没有想出这个比喻,这是从这个家伙叫Eric Koh博士。 他有,他运行一个伟大的播客. 所以,我建议大家都去看看。 但是的,我觉得在向企业解释这一概念时,这是非常合适的,特别是那些对这种概念不熟悉的人。

有问题,孤立的团队和不断变化的路线图

Lauren Bradley: Richard,你说过你是怎么说的,你知道的,如果, DevSecOps已完成,对吗? 你看不到它。 显然,其中一个显而易见的问题就是成本。 它也是孤立的团队。 当出现这些问题时,团队之间也会产生脱节,为什么他们以前没有被抓住?

为了快速或有效地解决这些问题,哪些流程,哪些沟通没有进行? 所以,我对你的问题是,你知道,在你的经验,哪一个… 你知道,可能是缺乏透明度。 决策缓慢,有可能浪费资源。

当您的团队处于孤立状态时,在您看来,当团队处于孤立状态时,哪些问题最容易引起问题?

Richard Yew: 是的,我来看看这个。 我认为,我个人在过去生活中经历过的一件事是,你知道, 当我们谈论类似的产品时,就像规划一样,重要的是,有时您的安全团队不会像CTO组织那样嵌入到研发中。

有时,在许多组织中,我们发现安全团队和CTO组织之间存在孤岛,您会发现许多流程是在事后完成的。 例如,我们遇到了这样一种情况:我们发布了大量产品,发布了大量代码,因为安全团队和工程团队之间没有强大的通信协作。

您最终得出的结论是,您知道,组织必须合规。 有时,具体的例子是,您有团队每年来做一次或两次扫描。 这些扫描的结果是什么? 嗯,我会被告知,”嗨,Richard,我们下一季度要放慢速度,因为我们发现了几百个不同的大小安全漏洞,你知道,也许,也许像20个,像前20个一样,严重程度为1和2及以上,而其余的,你知道, 关键是,您必须专注于解决这些问题。”

组织内有一个SLA需要你解决,你知道,最后发生的事情是,通过这样做,你基本上只是把我的路线图扔到下一个季度。 因此,通过不向左移动,不真正地将这一过程落实到位,只在右侧做这些事情,我们基本上是在推动我们的路线图,这是创收的交付成果,可能有助于扩大我们的业务。 我们可能会将其移动到正确的位置,这样我们就可以用四分之一的时间来缓解这些问题。

这就是为什么我要说,对于组织和企业来说,要想让他们把路线图项目移动一个季度是非常昂贵的。 因此,您的新产品,特性和功能的所有发布计划都必须改变,对吧? 因为你没有向左转入你的练习。

如果能够更好地协作,尤其是组织内的应用程序安全团队与开发团队之间的协作,这些方面的一些方面本来可以得到改进。 这就是为什么我们看到许多组织开始拥有这一新概念的原因。 你们知道,你们听说过HR BP,你们知道,是嵌入不同业务部门的HR业务合作伙伴。

现在有一个应用程序安全BP的概念。 所以,你将开始听到这些术语,比如应用程序SEC BP,这可能成为你有人工作的实践。 几乎就像工程团队的半嵌入式经理一样,确保他们在开发工作流程的每个步骤中提供正确的指导,工具和流程,例如,实施软件成分分析,实施安全ID,实施所有的黑盒和白盒任务, 在开发过程中,确保我们能够在开发生命周期的早期捕获这些问题。

Michael Grimshaw: 我爱一切。 很好的问题,Lauren。 我爱你刚才说的一切,理查德。 因为有一个相关的成本。 你知道,如果有人在产品中听到声音,等等,你知道,如果我向左移动,我就不必向右移动我的路线图。

这是他们的耳朵的音乐。 但是,对于CFO,甚至是运营,或其他业务领域,您可能会说,好的,这会产生什么影响? 影响是巨大的。 您只是揉捏了您的销售部门。 您对客户产生了影响,因为您拥有大量客户,尤其是在安全方面。 我知道在平台方面,当我与供应商交谈时,我想知道路线图是什么,因为,好的,也许我必须去找我的审计师,我需要获得补偿性控制,直到您发布路线图上的内容。 好的,如果你告诉我,好的,我期望在一个季度内完成的是三个季度。 我将开始了解其他供应商。 为什么? 因为我对我的审计员负有义务,我必须履行这些义务。

我也很喜欢Richard,您提出了审计师和真正的合规流程。 这是另一个例子,劳伦,关于硅化在哪里可以从根本上破坏东西。

如果您处于PCI,SOC,ISO,FedRAMP等各种合规框架的中间,但您尚未真正集成,您仍处于庇护心态,您可能会有合规或信息安全人员与您的审计人员交谈, 他们必须通过一两个层将其转换到工程方面,希望工程部门能够实现所有预期目标,然后就是实现它。 然后所有的证据和扫描,以及一切你需要提供给你的其他人,祝你好运。

如果这实际上转化为,我们都玩过,你知道, 这种来自小学的旧谣言游戏是一种类似的功能,如果你有整合的团队,与审计人员一起工作,立即知道如何将其转换为特定的技术,你有扫描,你可以立即把它转过来,并把它 在您的规则集中进行扫描和验证,并在实时以及与审计人员会面时进行扫描和验证。 你把所有的证据都集中在这里。 这是一个彻底的改变游戏规则的人。 它可以让您更快地向客户交付产品,而不是像Richard所说的那样,立即改变您的路线图。

Lauren Bradley: 是的。 因此,更具体地说,我的意思是,CISO和AppSec领导者如何量化他们的指标以了解成本影响,甚至只是总体成功?

如何实施DevSecOps流程?

Richard Yew: 什么,你知道,这是有趣的,因为我们谈论了很多为什么,你知道什么,但让我们更深入地探讨如何,因为我知道,这是我们很多观众的目的。 我们来这里不是为了给您提供蓬松的,高级的陈述。 我们在这里希望提供的是一些价值,当涉及到确切的实施方式.

也许我们可以弹出我们拥有的DevSecOps图表,然后我们可以简单地了解如何优化这些步骤。 好的。 您可以看到传统的安全测试,就像线性运行一样,对吗? 就像我们在谈论瀑布,就像你的计划,你有,美丽,一个测试, 对吗?

在操作员监控阶段进行了大量安全测试。 所以,它是在右侧。 所以,现在新的概念是,如果我们继续看下一张图片,对吧? 你可以找到这个图表的100个不同的品种。 就像今天的Google DevSecOps一样,正如Mike之前所说的那样,这个概念已经存在了7年了,对吧? 您知道有些组织可能不会称之为该周期。 有些组织只是将其称为AppSec,对吧? 因此,某些组织会将其称为安全管道。 所以,这是一个关于安全管道代表什么的粗略表示。 对吗? 所以,从一开始,您就处于规划阶段,对吧?

您可以进行威胁建模威胁分析。 在设计解决方案时,您会尝试确保您已充分利用所有这些建模。 所以,当你编写代码时,当你进入第二阶段时,你的编码阶段,对吧? 你要确保你有钩子。 您希望确保您拥有一个安全的IDE,因为编写代码的开发人员能够实时捕获一些问题。 显然,这不是一个银色的子弹,对吧? 但这是一个额外的层,我们正在讨论深度防御周期中的其他层。 现在,随着我们在这一过程中的进一步推进,对吧? 一旦您承诺编写代码,对吧? 您希望确保您有一个流程-能够对您的所有代码进行静态扫描,以确保它们检查自动依赖性,供应链,漏洞等。 以及软件补偿分析,以创建材料的软件视图,向您展示您正在使用的软件版本是什么? 他们多少岁?

因为,你知道,我不是小孩儿,我刚刚读了一两周前的统计数据–25%的Apache Log4j下载仍然是旧版本,仍然包含一个漏洞. 让我感到困惑的是,现在我们已经将近两年了,这仍然是一个统计数据。 我不知道,从12月初宣布第一个Apache Log4j零日漏洞起,是两年还是三年? 是2021年吗? 因此,我们需要专注于做得更好,并进行此类软件对话/分析,以确保您准确了解正在运行的软件版本。

重要。 那么,我们就转向测试,对吧? 你想确保你有内部测试,你有你的动态测试,你知道,实施,以确保这一点。 我们能够测试正在运行的应用程序,并查看是否存在任何可被利用的漏洞。

你知道这通常是通过Fuzzing来完成的。 现在,在传统DevSecOps周期中,此处未显示的是什么? 因为这一切看起来都是相当标准的行业实践,对吧? 随着我们一路向前推进,部署,监控和响应。 过去,您会将Web应用程序防火墙,爬虫程序管理器,API安全以及所有Web应用程序API保护解决方案置于响应和监控阶段,对吗? 这是当您监控生产流量时,您可以确保不存在对的漏洞利用。

但需要考虑的是实际移动一些您已实施的Web应用程序API保护。 也将它们移向左侧。 在这种情况下,在图片中,这是一个进步。 在您进行动态应用程序安全测试时,将它们置于测试阶段,对吧? 为什么不通过生产安全机制对它们进行测试? 因此,您知道,实际上代码之间存在多少漏洞,可以缓解多少漏洞,因为重要的是,我们一直在尝试通过使开发工作更快速来改善当前应用程序周期的生命周期。 当您在测试过程中发现安全漏洞时,通常的做法是基本上停止火车。 你回去吧,对吧? 你修复代码,你重新释放他们. 你再次经历了八个步骤。 但是,如果我告诉你,也许有办法让你说,”嘿,让我们不要停下火车?”

让我们继续前行吧。 让我们通过在步骤四之前使用安全解决方案进行某种额外测试来发布该测试,这将让您提前了解生产中虚拟修补的内容,这样您就不必停止培训。 你可以保持你的火车运行。 你保持你的速度。

您发布了带有虚拟修补程序的代码以缓解漏洞,然后在下一个周期修复它们,希望这将很快发生。 这也是我们想要的创新方法之一,我们希望通过这种方法来教育客户并与他们合作,努力改进现有的CICD安全工作流程。

Michael Grimshaw: 我爱你,Richard。 我爱你叫这个事实拉,把它拉入左移. 因此,如果您的游戏计划是,那么,让我们将其投入生产,然后我们将对此感到担忧。 您将会遇到问题,并且会有一些可以缓解的问题,这些问题可以通过开发,部署和操作流程覆盖您的后台。 我爱你,爱你。” 一个类比,一个类似的类比,我会说,就像混沌猴。 这是事情。 如果你在生产中有Chaos Monkey工作,而你在处理Chaos Monkey的唯一时间是它在生产中,你会有一个可怕的开发和操作经验。

您必须为此进行计划,设计和工程设计,然后才能投入生产。 否则,你就会陷入痛苦之中。

量化指标以了解成本影响和成功

Richard Yew: 是的,Lauren,我想回答前面的问题,现在我们只需查看整个DevSecOps生命周期,以及如何优化它,我们如何衡量成功。 什么是最佳实践,对吧?

非常快。 所以我们要跟踪成功。 很显然,您需要能够量化成功。 对。 因此,如果您是安全领导者,并且正在尝试衡量应用程序安全计划的成功程度,您可以查看其中一件事,也可以了解您拥有的应用程序覆盖范围, 对吗?

例如,您的组织中的所有应用程序或面向互联网的应用程序中是否有超过90/95%的应用程序在同一流程下运行? 您是否有相同的标准化流程覆盖? 对。 包括软件组成,分析,SAS,测试, 测试,测试,你知道,像Web应用程序,API保护.

您是否准备好了这些东西以保持跟踪覆盖范围? 您多久释放一次?多久必须回滚一次? 在哪个阶段(因为您检测到的安全漏洞)以及在生产阶段必须回滚的频率与在期间回滚的频率(您知道, 代码提交阶段,您正在执行静态分析,因为显然会回滚生产。

这将比在静态代码分析之后修复代码要昂贵得多。 对。 其他两个统计数据,你肯定想测量作为,正如劳伦前面提到的。 检测我们所称的MTTD的平均时间为200天。 所以,我相信,有了这个正确的过程与右移左过程,你可以大大减少同时检测,短得多. 因此,请尝试将度量标准组合在一起,以检测从漏洞披露到检测组织内部的漏洞需要多长时间。

同时实施响应,对吗? MTTR同时解决同时解决问题,对吗? 行业平均为70天,因此发现漏洞需要70天,对吗? 利用此漏洞的组织平均需要70天才能解决此问题。 但有了这个开始跟踪,你能多快解决? 一旦您在软件组合分析中找到了使用代码的J日志的易受攻击版本,您可以多快地使用防火墙对其进行虚拟修补,或者您可以多快地更新库以使用不同的软件,对吗? 因此,在一个非常成熟的组织中,我与一些组织进行了交谈,这些组织实际上拥有我们所说的平均4小时的时间来解决log4j事件的时间。

这是非常令人印象深刻的。 这说明了其DevSecOps流程的成熟度。 所以,我看到了各种各样的。 我也见过客户组织需要几周甚至几个月的时间来解决Log4j等关键问题。 因此,在您尝试改进整个流程时,记住这些指标非常重要。

Michael Grimshaw: 还有一些我想在这里提到的KPI是,就像在平台方面,当你处理基础设施或在许多情况下,任何工程,成本一直是这里的一个重要因素。 但在过去几年随着利率的上升,你知道,龙头是到VC的钱和很多,真的干了,但游戏的名字和上升的利率环境是一个击败了非常有利可图的.

这里有一个方面。 我喜欢这项技术。 很显然,您知道,平台工程主管。 我喜欢技术方面,尤其是在过去几年中,如果您正在平台上工作,就像我所说的那样,基础设施和类似的事情,财务方面,以及向CFO和CTO澄清和提供反馈变得势在必行。

因此,KPI是围绕成本和收入的,这是另一个,这也是一个非常重要的方面。 我只想指出一些类似的事情,例如,在收入方面。 如果您坐下来进行红线讨论,如果您有一位客户想要购买您的产品,但您的产品却需要购买,您将会经历安全红线,因为安全是每个人的心头,您的客户将希望确保他们受到保护。

他们要尽量降低风险。 如果你带着旧派的心态来找他。 哦,是的,我们开发的东西,然后我们,让,我们确保我们的信息扫描它们和所有这些。 我一直在进行大量的红线讨论和合同讨论,这只是简单地不会再飞了。

客户风险部门和法律部门的调查问卷和调查问卷在过去五年中达到了完全不同的详细程度,更不用说10年了。 而且,能够拥有完全集成的左移解决方案来实现Web应用程序和API保护–所有这一切。 当你和其他人的律师交谈时,这会大大推动这条针。 这是什么意思? 这意味着它可以让您更快地完成交易。 其中一件事是,如果你不是在练习左移,或者你只是认为这是一个附加功能, 我建议您返回并查看您的成交比率及其细分处,并特别关注安全红线讨论,因为这些类型的产品问题往往被视为成本中心。 他们不是,他们可以解锁收入,他们可以为你节省大量的钱.

在播客的前面,我们介绍了许多成本节省以及内部成本,但在测试版中有一些收益,我认为这一点很重要,因为在利率不断上升的世界中,很多人都关注这一点。

总结

Richard Yew: 这是一个很好的观点。 我很高兴我们换了一些帽子,你知道,就像戴上我的SDLC帽子,戴上你的商务帽子。 这是很好的。 我希望我们分享的所有这些东西都能为我们的受众提供一些价值。

Lauren Bradley: 非常感谢你们。 我想这是一个很好的结束。 我们已经介绍了向左迁移的重要性以及如何将Web应用程序和API保护有效融入DevOps生命周期。 当然,如何有效地衡量成功。 是否有更少的误报? 您的平均时间分辨率是多少? 您交付软件的速度有多快? 您是否获得了更多收入?

所有这些指标都是企业成功的关键。 因此,我感谢你们,Michael和Richard今天加入我的行列。 这确实是一个愉快的经历,感谢您与我们的听众一起参与超越边缘的活动。 我们将在下一集看到您。