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 Security平台产品管理高级总监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和Shift Left Shift的含义，对吧？ 有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：是的。 我认为这是一个伟大的呼声是刹车。 强劲的制动让您掌控一切。 我们前方的电流或道路充满了曲线，急转弯，以及所有这些，当然，有的是，你可以直接把它踩在地面上，而不是触摸刹车，而是导航一切，那刹车，我想，爱，我喜欢这两个类比，理查德，因为这种制动类比，它给你控制，当你面对路边，挑战和意外的事情时，它给你更精细的谷物控制。
理查德·尤：伟大的呼叫。 顺便说一句,我想澄清,我没有想到这个比喻是从这个叫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，你培养了审计员和合规流程。 这是另一个例子，Lauren，关于孤立化可以从根本上破坏事物的地方。
如果您处于PCI,SOC,ISO,FedRAMP,任何这些不同的合规性框架的中间,并且您尚未真正集成,您仍在运行一种庇护心态,您可能会有一个合规或信息秒的人与您的审计员交谈,他们将不得不通过一两层将其转换到工程方面,希望将实现所有预期的,然后这只是为了实现它。 然后,所有的证据和扫描,以及你需要提供给你的其他人的一切,祝你好运。
如果这真的可以解释清楚，我们都玩过，小学的旧谣言游戏是一种类似的功能，如果你有一个整合的团队和审计员一起工作，他们立刻知道如何将其转换为特定的技术，你可以立即将其转化为你的规则集，并在你与审计员会面时扫描和验证。 你已经把所有的证据都集中在那里了。 这是一个彻底改变游戏规则的因素。 它使您能够更快地向客户交付产品，而不是像理查德所说的那样，现在就不断改变您的路线图。
Lauren Bradley：是的。 因此，为了更具体地说明这一点，我的意思是，CISO和AppSec领导者如何量化他们的衡量标准，以了解成本影响，甚至只是一般的成功？
理查德·尤：这很有趣，因为我们谈论了很多原因，你知道什么，但让我们深入了解如何做，因为我知道，这就是我们很多观众的目的。 我们在这里不是为了给你一个蓬松的，高层次的陈述。 我们希望在这里提供的内容在具体如何实施时具有一定的价值。
也许我们可以弹出我们拥有的DevSecOps图表，然后我们可以简单地了解如何优化步骤。 好的。 您可以看到传统的安全测试，就像线性运行一样，对吧？ 就像我们谈论瀑布，就像你的计划，你有，美丽，一个测试，对吧？
在操作员监控阶段完成了大量的安全测试。 所以，它就在右边。 那么，现在新的概念是，如果我们继续看下一张图片，对吧？ 你可以找到这个图表的100个不同的品种。 就像今天的谷歌DevSecOps (谷歌DevSecOps)，就像Mike之前所说的那样，这个概念已经存在了7年了，对吧？ 您知道，有些组织可能不会称之为这一周期。 有些组织只称之为AppSec，对吧？ 因此，某些组织会将其称为安全管道。 因此，这是一个大致的表示安全管道的含义。 对吗？ 所以，从一开始，您就处于规划阶段，对吧？
您可以进行威胁建模威胁分析。 您尝试并确保在设计解决方案时完成了所有这些建模。 所以，在你编码的时候，当你进入第二阶段，你的编码阶段，对吧？ 你想确保你有上钩. 您希望确保您拥有一个安全的IDE，因为开发人员编写代码时会实时捕获一些问题。 显然,这不是一个银子弹,对吧? 但这是一个额外的层，我们正在讨论纵深防御周期中的额外层。 现在，当我们进一步向下推进这一过程时，对吧？ 一旦您致力于编写代码，对吧？ 您希望确保您有一个流程–谁能够提供静态扫描您的所有代码，以确保它们检查自动依赖性，供应链，漏洞等，以及软件补偿分析，从而创建材料的软件视图，向您显示您正在使用的软件版本？ 他们多少岁？
因为,你知道,我不开玩笑,我刚刚读了一两个星期前的统计数据–25%的Apache Log4j下载仍然包含一个漏洞的旧版本是关闭的。 现在我们差不多两年了，但这仍然是一个统计数据，这让我感到困惑。 我不知道,是在12月初宣布第一个Apache Log4j零天漏洞后的两年还是三年? 是2021年吗？ 因此，我们确实需要专注于做得更好，并准备好这种软件对话/分析，以确保您确切了解所运行的软件版本。
这很重要。 那么，我们就走向测试，对吧？ 你想确保你有内部测试,你有你的动态测试,你知道,实施,以确保这一点。 我们能够测试正在运行的应用程序，并查看是否存在可被利用的任何类型的漏洞。
你知道这通常是通过模糊来完成的。 现在，传统DevSecOps周期中没有显示什么？ 因为这一切看起来都是非常标准的行业实践，对吧？ 因为我们一直在部署，监控和响应。 过去，您会将Web应用程序防火墙，爬虫程序管理器，API安全以及他们所有的Web应用程序API保护解决方案置于响应和监控阶段，对吧？ 这是当您监控生产流量时，您可以确保不存在针对的漏洞。
但需要考虑的是实际移动您已有的Web应用程序API保护。 也将它们移至左侧。 在这种情况下,在图片中,这是向前迈出的一步。 在您进行动态应用程序安全测试时，将其置于测试阶段，对吧？ 您为什么不通过生产安全机制对其进行测试？ 因此，您知道，实际上代码之间存在多少漏洞，有多少漏洞可以被缓解，因为重要的是，我们一直在努力通过实际加快开发工作来改善当前应用程序周期的方法。 当您在测试过程中发现安全漏洞时，通常的做法是您基本上停止列车。 你回去吧，对吧？ 您修复了代码，然后重新发布它们。 您再次完成八个步骤。 但如果我告诉你也许有办法让你说，”嘿，让我们不要停火车呢？”
让我们继续列车。 让我们通过在步骤四前面对安全解决方案进行一种附加测试来释放这一点，这将让您提前知道在生产中要虚拟修补什么，这样您就不必停止火车了。 你让你的火车继续前进。 你保持你的速度。
您使用虚拟修补程序发布代码以缓解漏洞，然后在下一个周期修复它们，希望这将很快完成。 这也是我们想要的创新方法之一，您知道，我们希望通过这种方法来教育客户并与客户合作，以尝试改进现有CICD安全工作流。
Michael Grimshaw:我喜欢,理查德。 我爱你,我爱你,拉这个变成左移的事实。 如果你的游戏计划是,哦,让我们把它投入生产,然后我们会担心. 在开发，部署和运营过程中，您将遇到问题，并且会遇到一些可以缓解的问题，这些问题可能会覆盖您的背面。 “我爱你! 一个类比和一个类似的类比，我想说，就像混沌猴子。 这就是问题。 如果你有混沌猴子在生产中工作,你处理混沌猴子的唯一时间是当它在生产时,你将有一个可怕的开发和操作经验。
您必须在其投入生产之前对其进行规划，设计和工程设计。 否则,你就会陷入苦难。
量化指标以了解成本影响和成功
Richard Yew：是的，Lauren，我想回答前面的问题，现在我们如何衡量成功，因为我们只需了解整个DevSecOps生命周期以及如何优化它。 什么是最佳实践，对吧？
非常快。 所以我们要追踪成功。 所以显然,你需要能够量化成功。 对。 如果您是一名安全领导者，并且您正在尝试衡量应用程序安全计划的成功程度，那么有一些衡量标准会有所帮助，这是您可以看到的其中一件事情，也是您拥有的应用程序覆盖范围的多少，对吧？
例如，您的组织中是否有超过90/95%的应用程序或面向互联网的应用程序都在同一流程下覆盖？ 您是否有相同的标准化流程涵盖？ 对。 包括软件组成，分析，SAS，测试，测试，测试，测试在内的一切，您都知道，例如Web应用程序，API保护。
您是否准备好这些措施来持续跟踪覆盖范围？ 您多久发布一次，多久必须回滚一次？ 由于您检测到的安全漏洞，在哪个阶段必须在生产阶段回滚，而在代码提交阶段(您知道，在执行静态分析的代码提交阶段)必须回滚的频率显然是因为回滚了生产。
这将比静态代码分析后修复代码更昂贵。 对。 还有其他两个统计数据,你肯定想衡量,正如Lauren早些时候提到的。 行业平均检测我们称之为MTTD的时间是200天。 所以,我相信有了这个正确的过程与右移左移的过程,你可以大大减少时间来检测,到更短的时间. 因此，请尝试将度量组合在一起，以检测从漏洞披露到检测组织内的这些建筑需要多长时间。
同时实施响应，对吧？ MTTR同时解决问题，对吧？ 行业平均值是70天，因此发现漏洞后是70天，对吧？ 它仍然需要平均70天的时间来解决这个问题。 但是通过这种开始跟踪，您可以多快地解决问题？ 当您在软件组成分析中使用您的代码发现J的易受攻击的日志版本时，您可以用防火墙虚拟修补它们的速度多快，或者您可以多快地更新库以使用不同的软件？ 因此，在一个非常成熟的组织中，我已经与一些组织交谈过，他们实际上有四个小时的平均时间来解决log4j事件的时间。
这令人印象深刻。 这说明了他们DevSecOps流程的成熟度。 所以,我看到了各种各样的东西。 我还看到客户组织需要几周甚至几个月的时间来解决log4j等关键问题。 因此，在您尝试改善整个流程时，牢记这些指标非常重要。
Michael Grimshaw：还有一些其他的KPI，我想在这里介绍，就像在平台方面，当您处理基础设施或者在许多情况下，任何工程，成本都是这里的一个重要因素。 但是在过去的几年里，随着利率的上升，你知道，这种情况就像是VC货币，其中很多钱真的枯竭了，但游戏的名称和不断上升的利率环境是一个非常有利可图的地方。
这里有一个方面。 我喜欢这种技术。 显然，平台工程总监。 我喜欢技术方面，但特别是在过去的几年中，如果您在平台工作，就像我说的那样，基础设施和类似的东西，财务方面，以及向您的CFO和CTO澄清和提供反馈，这已经成为当务之急。
因此，KPI围绕成本和收入，这是另一个重要方面。 我只想谈谈一些类似的事情，例如，在收入方面。 如果您坐下来进行红线讨论，如果您有一位客户想要购买您的产品，但您的产品，您将通过安全红线，因为每个人都认为安全是安全问题，您的客户希望确保他们受到保护。
他们希望在这里将风险降至最低。 如果你来找他与老派的心态。 哦，是的，我们开发事物，然后我们让我们确保我们的信息安全扫描它们和所有这些。 我已经参加了大量的红线讨论和合同讨论,这只是不会再飞了。
在过去五年中，客户风险部门和法律部门的问卷和问卷的级别已经变成了其他级别的详细信息，更不用说10年了。 而且，能够拥有完全集成的Shift-Left解决方案，以拥有Web应用程序和API保护–所有这些。 当你和其他人的律师交谈时,这会在很大程度上推动针。 这是什么意思？ 这意味着它允许您更快地达成交易。 其中一件事是，如果您不是在练习Shift Left，或者您只是认为它是一个附加项，我建议您回头看看您的成交比率以及它们在哪里出现分歧，并特别关注安全红线讨论，因为这些类型的产品问题经常被视为成本中心。 他们不是,他们可以解锁收入,他们可以为您节省大量的资金。
在播客的早些时候，我们介绍了大量的成本节约，涉及内部成本，但在这里，我们发现了Beta版的收入影响，我认为这一点很重要，因为这正是当前利率不断上升的世界中很多人的注意力所在。
总结
Richard Yew:这是一个很好的观点。 我很高兴我们换了一点点帽子，比如戴上我的SDLC帽子，戴上你的商务帽子。 好极了。 我希望我们分享的所有这些东西都能为我们的听众带来一些价值。
Lauren Bradley：非常感谢你们。 我认为这是一个很好的结尾。 我们已经介绍了向左转的重要性以及如何有效地将Web应用程序和API保护融入DevOps生命周期。 当然，如何有效衡量成功。 误报次数是否减少？ 您的平均时间分辨率是多少？ 您发货软件的速度有多快？ 您是否获得更多收入？
所有这些指标对企业的成功至关重要。 所以，我非常感谢Michael和Richard今天与我一起工作。 我们非常高兴，感谢我们的观众加入我们的Beyond the Edge。 我们将在下一集看到您。
