DevSecOps的快速胜利
我总是喜欢到森林里去,享受宁静,不受干扰地追求我的思想。最近,我想到了一个问题,我在会议、聚会或研讨会上一次又一次地被问到:这个问题几乎总是:如果您想更多地处理软件开发中的安全性主题,那么什么是快速成功或唾手可得的成果?
我现在就想回答这个问题!
视频记录
大家好,欢迎来到我在SwampUP的演讲。如果您想知道如何在您的DevOps环境中开始安全性,它如何与SRE方法相适应,以及您是否可以将两者合并,那么您完全可以在我的演讲中找到答案。我们将发现如何从安全性开始,如何将安全性集成到您的团队中,如何合并不同的方法,什么是快速的胜利,以及作为开发人员应该使用的基本工具是什么,如果您真的想要进行有效的转变。
顺便说一下,我叫Sven,是JFrog的开发者倡导者,大多数人都知道我是林中之人。如果你能看到我现在在森林里。我很喜欢它,因为这是思考复杂it挑战的最佳时机。所以,你们现在和我一起踏上了两段旅程。
一个是DevSecOps世界,另一个是德国森林深处。好吧,让我们看看我们能做什么和享受。
如果你想把安全问题集成到DevOps的世界中,它与其他主题有什么不同?好吧,让我们看看DevOps的世界是什么样子的?
DevOps的世界通常关注的是这个过程的开发,如何构建软件,如果你读维基百科,你会发现它很可能描述从编码、构建、测试、打包等所有这些东西,直到它运行到生产环境。这里的共同点是所有提到的步骤都是专门的生产步骤。但现在,我们谈论的是安全问题。
安全是一个生产步骤吗?不,安全不是生产步骤,安全是你必须在不同步骤中整合的东西,主要是你必须在每一步中整合它,因为安全就像质量一样。那么让我们看看我们如何包含这个或者更好的我们从过去学到的东西以及我们现在可以做些什么来处理这个安全主题。所以在过去,我们有开发和运营团队,他们有酒,他们有生产步骤。它们的共同点是,Dev pod创建二进制文件,ops pod将这些二进制文件抓取到像Artifactory这样的存储库中。然后投入生产,让它运行。
从ops和dev一起到DevOps的转变集中在不同生产步骤的技术需求上。所以这很顺利,现在或多或少建立起来了。但是现在我们有了安全,如果安全无处不在,意味着每一个微小的步骤都与安全有关,因为安全不是这个专用的步骤。
好了,最后一个问题是,如何将DevOps世界中的安全集成到DevOps环境中?
只是,你必须在每个生产步骤中考虑安全问题,我将向你展示一种不同的方法以及我们如何尽可能地向左平移。
但总的来说,安全更像是一种文化必须意识到,这不仅仅是一个产品,一个产品会帮助你,因为作为一个人,你不够快。但这不仅仅是买一件产品,也不会让你慢下来。所以如果你做得对,你就有可能以一种不会拖慢你速度的方式实现安全。
即使你做得对,它也会提高你的质量,因为质量和安全是好朋友。但是我们稍后会讲到这个话题。那么,如何集成安防呢?嗯,每个人都是其中的一部分。这是团队的责任。这就像是一种文化。
多读一点关于这个的内容。我们会发现安全就像质量一样。
它在你的管道里无处不在。好的,这些dev ops或者dev sec ops,但是人们谈论的是站点可靠性工程。我们能把这个结合起来吗?有什么区别?最主要的是,站点可靠性工程来自谷歌,所以他们有这种方法,我们有专门的工程师来自动化所有这些东西。谷歌给出的定义是SRE主要关注最大化50%的工作时间用于运营,其余时间用于开发。那么这是什么意思呢?
最后,还是差不多的。这是一个人的开发。所以是一个非常有经验的开发人员专注于运营或者是一个非常有经验的运营人员现在专注于开发。所以无论你选择什么,这个SRE,站点可靠性工程师,或多或少是介于开发和运营之间。所以把这篇文章放在一起?肯定。因为DevOps只是一个过程,它是组织所有这些东西的一种方式。SRE是一个角色。那么SRE是否适合开发运维还是开发运维?
当然,这是完美的,因为大多数人都是处于中间位置的,而这里的巨大潜力在于,这个SRE,这个服务可靠性工程师,可以将这两个部分粘合在一起,将操作部分的安全性和开发部分的安全性粘合在一起,并以此为契机。简而言之,答案与此吻合。肯定。
好的,我们看到devops和SRE完美地融合在一起。但是我在接下来的步骤中所解释的并不局限于DevOps,或者SRE,或者其他什么。所以即使你有一个非常经典的项目管理风格,如果你有专门的团队,你可以使用我现在解释的所有东西,因为这有点通用。因此,安全性并不局限于专门的产品管理风格。
安全性是你可以在任何地方实现的东西,但正如我所解释的,你将在DevOps或dev sec环境中获得全部潜力。现在,我们来看一个例子。这个例子是…科技领域的独行侠。令人惊讶的是,在过去的一两年里发生了什么重大事件?
Solarwinds。所以我不想细说太阳风黑客的所有细节,但我想提一些对我们接下来要做的事情非常鼓舞人心的事情,或者我们应该利用这个经验教训。首先,这个黑客组织侵入了太阳风公司。那么谁是太阳风公司呢?Solarwinds是一家开发用于管理网络基础设施的软件平台的公司。令人惊讶的是,如果你在管理网络基础设施,首先,这是公司沟通结构中最关键的部分。第二件事是,要管理基础设施,你需要雇佣合适的人,比如管理员。所以这是一个完美的目标,因为太阳风公司有大约30万客户在使用这个软件。这个黑客组织所做的就是他们闯入了太阳风的环境并将太阳风作为他们所有客户的乘数器。
但是发生了什么?太阳风号是如何破解的?这个黑客组织从太阳风公司侵入了这个IT系统,太阳风公司正在生产软件,主要目标不是破坏东西或者使它不可用,他们只是破坏了CI环境。
哇,CI环境?为什么?所以他们所做的是,他们以一种他们现在正在制作的构建的方式改变了构建,他们会添加一些来自这个黑客组织的被破坏的二进制文件,然后他们的官方更新,或者他们的官方发布包含已经被破坏的代码。仅仅是有一家公司,它就能传播到潜在的30万客户,这是令人惊讶的。
它有大量的潜在目标,所以不是瞄准最终目标或者只是攻击最终目标,你要做的是使用乘数这将有两个视图。第一,如果你是下一个太阳风公司,或者你是太阳风公司的消费者。说,我们有两个维度要看,因为我们必须看对抗双方。所以如果这是一种新的攻击方式,那就是他们针对的是供应链而不是最终目标。
那我们就得准备好,按我说的说,你有没有扫描过你的Jenkins CI,以对抗已知的漏洞?
对抗所有这些攻击,这意味着什么?你能做什么?谈到DevOps环境,你有两个部分,两个主要部分。你有运营部和开发部。那么你应该把重点放在哪里呢?
首先,如果你关注运行时环境,扫描运行时环境,我不确定你是否真的想要它但如果你想测试和运行环境,你谈论的是DAST,动态应用程序安全测试框架他们所做的是他们把你的环境看作一个黑盒子,他们不知道依赖关系,他们不知道你正在使用的技术。
但我想强调的是这些动态应用安全测试工具,他们在攻击你的系统,试图闯入,他们需要知识如何做这些事情这是基于最常见的漏洞。如果你想有一些特殊的攻击,那么你需要定制这些工具,你需要这种特殊的知识,有时你有云环境不能自定义。那么我们还能做什么呢?因为我们想要专注于一些唾手可得的成果,快速的胜利,你能在你的环境中产生的最大影响,这肯定会激发一个静态的派对。
好了,我们讨论了动态应用程序安全测试,它的对立面是什么?静态部分,SAST,静态应用程序安全测试,我个人关注的是这个,因为它有很多好处,因为我们不仅关注汽车中最常见的漏洞,因为这只是一小部分。
现在我们专注于一切。因此,对于不良代码,我们关注已知的漏洞、遵从性问题,等等。
为什么?因为我们有所有的语义信息,所以我们有关于所有组件的所有信息,如果你专注于静态分析器部分,我们甚至可以在生产环境中运行之前就完成它。因此,如果您只是在生产环境中运行时进行扫描,那就太晚了。所以我想尽早对抗所有的漏洞,这意味着我必须在开发部分,而不是在运维部分这样做。
运维不擅长on,但主要的重点应该放在开发部分,因为这是早期的,这不是在生产中运行,你有更多的信息可以用来加强你的系统,这就是为什么你应该开始关注这个静态分析主题。如果我们看的是强音杆,我们就会看到依赖性是99%的测试棒。为什么?所以在我们编码的时候,我们写了一些代码,但最有可能的是,我们直接或间接地通过依赖关系或传递依赖关系添加了更多的代码行。
如果我们把这个推到一个操作系统上,这样它就必须运行,例如,在x行上,我们配置了一点[听不清],但操作系统的其余部分是二进制的,这是我们正在抓取的依赖项。Docker也是一样,从front语句开始。所以我们在添加依赖项、样本、Kubernetes等等。所以看整个技术栈意味着如果你在谈论我们自己在做什么,弄清楚我们在某个地方添加了什么,通过依赖性,这是最棘手的部分。
如果我们想要有效地对抗已知的漏洞,我们必须首先关注依赖,因为这是迄今为止技术栈中最大的部分。让我们从遵从性问题开始。那么遵从性问题的行为是什么呢?
为什么我们要扫描它们?为什么这是安全措施的一部分?嗯,安全不仅仅是一个漏洞,安全是合规性。所以也要保证生意的安全。这意味着如果你要添加依赖项,这是最重要的部分,检查所有直接或间接的依赖项是有意义的,以确保我们没有在正确的地方使用错误的许可证。这对企业来说是毒药。那么,我们需要从什么开始对抗遵从性问题呢?
首先,我们需要一个被授权的人来决定什么是适合你生产线的哪一部分的许可证,因为你需要一些法律建议,或者任何有能力决定的人来确保你有一个允许的白标签许可证和黑标签许可证的初始清单,所以不允许的许可证。所以如果你有这个,那么好的是机器可以开始扫描。有了是或否许可,或者有了传递或直接依赖的排他的否许可,为什么每次运行时都要扫描它?大多数情况下,如果你在项目中首先扫描,如果它在正确的许可下运行,你就不会再有问题了因为这基本上不会改变。但有两件事可以改变。
首先,项目本身可以改变,比如看看这个。Java。ee,雅加达。ee, NoEclipse。情感表达的东西。所以依赖关系总是有变化的。也可能是你使用的依赖项的项目维护者,对他的依赖项的维护不是很清楚。所以也许他正在从谷歌番石榴转向收集任何东西。然后你可能有不同的许可证,也可能没有,但如果你经常检查,如果有任何关于合规性的问题,这总是好的。
但如果你有合规问题,你要做什么呢?所以合规问题,它们有好也有坏,因为好的方面是你可以把它们结合起来。坏的事情是,如果你有一个遵从性问题,那么你必须删除这个点在你的整个文本x或这个单一的依赖,然后你必须确保你改变它或取代它的语义平等的实现。
这不是微不足道的。所以找一些在不同许可证上运行的东西和你期待的一模一样。所以这可能会带来一些麻烦,但大多数情况下,在检查了许可证之后更改依赖项或传递依赖项的情况并不常见。如果你有这可能会很辛苦。但大多数情况下,如果你是干净的,那么中期或长期都不会有大问题。注意攻击媒介,不同的攻击媒介。谈到漏洞,我们有一个常见的漏洞评分系统cbss。然后我们在不同的漏洞之间进行了排名在非常危险,不太危险和。
如果你想了解更多关于CVSS,我有一个专门的YouTube视频,详细解释CVSS。但是我想在这里强调的主要事情是,您需要一些工具,它知道什么是已知漏洞的CVSS值。下一件事是,即使CVSS值很低,也要看看完整的影响图。所以你需要整个技术栈的所有依赖关系,因为你可以将不同的漏洞组合到不同的攻击向量上。
不同的攻击向量意味着可能存在的弱点的数量在您的应用程序中不只是每一个单一的漏洞点,它是,除此之外,所有不同的攻击向量的整体组成。这意味着即使是低风险的漏洞也可能与其他对您的环境非常危险的东西结合在一起。
针对已知漏洞和遵从性问题的良好安全构建是什么?有一件事非常非常好,那就是良好的测试覆盖率。为什么?因为谈论已知的漏洞,您必须切换到同一依赖项的不同版本。所以如果你有一个非常强大的测试覆盖率,那么你就可以以一种不再有漏洞的方式来改变版本。同时,通过良好的测试覆盖率,您可以检查不同版本中是否有相同依赖的新组合,它们所做的事情与您需要的完全相同。
如果您有遵从性问题,TDD甚至更强大,因为如果您必须用语义相等的实现替换,您会对良好的测试覆盖率感到非常高兴,因为这样您就可以在不同的实现之间切换并检查测试覆盖率,如果一切运行正常。因此,TDD是对抗已知漏洞的最佳安全带之一,您需要非常强大的测试覆盖率。我个人知道的最强的测试覆盖率之一是突变测试覆盖率。因为它比线路覆盖或分支覆盖强得多。
看看我的YouTube频道,我有解释测试本身的视频。但是无论您采用何种测试覆盖率,强大的测试覆盖率都是您抵御已知漏洞和遵从性问题的安全带。
如果测试覆盖是对抗已知漏洞和遵从性问题的最好方法之一,那么您就需要管理所有这些依赖关系的东西,因为所有技术层的新依赖关系的组合或依赖关系的替换必须是对抗已知漏洞和这些遵从性问题的一部分。所以你需要一个单一的点,一个逻辑上的单一点来管理你所有的存储库管理器,这样你就可以在一个地方拥有所有的依赖关系。然后用一个工具,你可以检查,不仅仅是一个技术层,或者一种技术,或者一个,无论什么,你可以扫描整个技术堆栈。我说的一切,真的是一切。例如,你的Maven依赖,如果你正在编写Java代码,你的DBN存储库,你的Docker存储库,你的Helm图表,甚至,例如,在你的工具中,想想Solarwinds油箱。所以这次攻击是针对供应链的,这意味着如果你有一个Docker映像,里面有你的Jenkins,只要扫描它,这样你就知道并意识到所有的漏洞。
所以你需要一个单一的点,我们对Artifactory有相同的点,因为我们知道所有这些不同的存储库类型,我们知道所有这些元数据。所以我们不仅要理解依赖关系,还要理解传递依赖关系,直到最后一个元素。
然后用x射线,x射线是一种扫描仪,我们使用所有的二进制和人工工厂内部的知识,包括皮带信息和所有其他的东西,给你一个关于所有已知漏洞和所有许可证的完整影响图在你的整个技术堆栈中使用。这是针对整个技术栈的80%,90%,99%所以,如果依赖关系是整个技术栈中最大的部分,你想从安全开始,关注依赖关系,关注有效的依赖关系管理,关注扫描这些依赖关系,防止漏洞和遵从性问题。
如果你感染了某种攻击,你会怎么做?所以简单的回答就是识别所有被感染的组件,移除它们从头开始安装是干净的。
有这么简单吗?嗯,如果你有被感染的组件,你不知道其他组件在使用这个,那么如果你做得正确,这或多或少是一个非常非常长,非常长,非常长的工作和大量的努力。因此,有效地,我们在人工查询语言中得到了支持,它是SQL查询语言,你可以选择不同的工件,然后你会看到它们在其他部分使用,或者它们被其他组件使用,因为有X射线,我们有完整的影响图,如果你有完整的影响图,我们可以确定谁在消耗什么。有了这个,很容易确保我们正在删除受感染的二进制文件,然后确保所有依赖都被干净的替代。所以这是一个点,如果你有一个点,所有的依赖关系都经过,你就有了完整的影响图,如果你把完整的影响图添加到你的查询风格语言中,你可以选择部分树,然后它可以删除所有的东西,从头开始安装。这就是为什么JFrog客户对这种查询语言非常满意,因为有了它,我们可以很容易地删除受感染的二进制文件。
好了,如果你知道如何对抗已知的漏洞,有一个术语经常被提到,而且非常非常重要。这是向左平移。这是什么意思?例如,如果您第一次向左移动,这意味着我们不是在与产品中的漏洞作斗争,而是在与CI管道中的漏洞作斗争。
有了它,我们可以在每次构建时扫描二进制文件,我们可以确保就已知的漏洞或合规问题而言,没有什么是对我们不利的,但我们可以进一步或更多地向左转移。这意味着,如果你只是把洞察力作为你的环境,我并不是说我们不需要它,我只是说我们需要一些额外的东西。
因为如果你一整天都在做第一次提交,或者在几个小时后就把它推向持续集成环境,得到内部存在漏洞的反馈,我们已经烧了一些钱。所以我们也要最小化这个时间。这意味着我们向左转了更多。
更左意味着我们直接移动到IDEE内部,所以如果你在写第一行代码,你就知道你需要的所有东西。例如,如果这个许可是正确的,在你的传递依赖或间接依赖中有什么东西是你应该知道的吗关于已知的漏洞。这是通过IDEE插件完成的,所以我们在IDEE内部直接向左移动。然后,如果你添加了第一行依赖项或第一行代码,你已经知道了一切,你现在正在做的东西的完整影响图是什么。因此,在ci环境中拥有它意味着您有可能在整个技术堆栈中拥有它,从您的应用程序到掌舵图。
如果你直接在你的idea中加入它,你就知道你所添加的第一行代码的所有内容,你就不会浪费时间,也不会浪费你的努力。如果你想尝试一下,用这个插件。我们有IntelliJ VS code Eclipse。它是开源的,可以在GitHub上找到。所以如果你有任何需要,你可以提出一些问题,或者你可以提出一些特性要求。或者如果你想让代码通过,那就先制定一个度量标准。有了这个IDEE插件,你可以连接到一个x射线实例。这甚至有可能与免费层。所以你只需要从你的X射线实例协调你的用户名,密码,然后你可以与X射线连接。所有的X光信息就是看看你的IDEE里面是怎么回事
对于IDEE内部的开发人员来说是什么样子的?我将用一个简短的视频给你们展示。现在,我们有一个X射线IDEE插件的简短视图,我刚刚添加了一个池塘依赖项。这是你在IDE插件中会有的一个版本,某种窗口。我用的是IntelliJ。它在Eclipse上可能看起来有点不同,然后它会看到我们已经添加的依赖项,这里是4120然后你必须按住铅笔树你会看到对象和数据绑定存在安全问题。
你得到的是将其列为高、中或低安全风险。您将看到许可信息或类型版本等。
好的是,您可以在这里看到所有的详细信息,例如,如果已经有一个固定的版本可用,什么时候,问题本身的摘要。一个很酷的事情是,如果你在某处,你可以到这里,说show他project descriptor,然后你就跳转回这个。另一件事是,如果你决定排除,你可以在这里说排除依赖,你会得到的是依赖排除。就是这样。
另一件事,我想向你们展示如何安装它。在IntelliJ中,这很简单。同样,作为一个插件,您正在搜索JFrog插件,更新它或只是安装它。在IntelliJ中,您必须重新启动,在Eclipse中可能会有所不同。然后你要做的唯一一件事就是你要去这个x射线插件的设置,添加你的坐标,然后你就可以把你的IntelliJ连接到x射线安装。
就是这样。玩得开心。好了,是时候总结今天的内容了。因此,我们看到安全不仅仅是生产流程中的一个步骤,安全就像一种文化,安全就像质量,它无处不在,在生产流程的每一个步骤中,我们看到无论何时你选择DevOps,或SRE方法或经典项目管理方法,任何安全都可以在所有这些项目管理的关键流程中实施。
这意味着您团队中的每个人都必须意识到他可以做些什么来增加他所工作的这个专用步骤的安全性。我们需要总体概况,我们需要完整的影响图。因此,我们需要一种关注所有技术和所有流程的整体技术堆栈的观点。所以安全不像我只是买一个产品,安全是团队内部的责任,团队需要意识到它需要权力来决定必须做什么来实现更好的安全。
一开始就关注安全性意味着你应该关注那些唾手可得的成果,速成的成果,关注整个技术栈意味着整个技术栈远远超过90%,实际上,在大多数情况下超过90%,只是依赖关系的管理,这意味着你需要一个非常有效的依赖关系管理,另一方面,你需要一些东西可以处理所有这些依赖关系,直接依赖关系,传递依赖关系,间接依赖关系。为此,我们有Artifactory,因为它知道所有这些包管理器,从Java, Maven到大比安到Helm图表,Docker等等。然后用x射线,我们不仅可以扫描二进制文件本身,还可以检查依赖关系,间接依赖关系,我们也可以扫描遵从性问题。因此,我们对已知的漏洞和遵从性问题有了一些了解。这与关注依赖关系意味着您有超过90%的系统清除已知漏洞。所以如果你想尝试一下,我们有这个免费层。你可以做两件事,你可以在ci环境中实现它,在ci环境中,有一个工作机器,你必须自动化所有的东西,这样质量总是一样的,安全行为总是一样的,无论你选择什么时间。在另一边,你可以尽可能地向左移动。使用我们的IDE插件,我们直接进入IDE,在这里您可以编写第一行代码。你也需要所有这些信息。接下来你能做的是不同的事情。
首先,您可以参加我们的一些网络研讨会,以获得有关分发、Artifactory、安全性等更详细的信息。
如果你想获得实践经验,只需注册我们的一个研讨会,我们有定期的研讨会,我可以用德语和英语授课。如果你想在YouTube上看东西,可以看看我的YouTube频道。我在YouTube上有很多户外IT相关的视频。非常感谢你们的出席。
很高兴在本次会议上见到大家,并祝会议愉快。好好欣赏其他的演讲吧。我非常希望你能参加我的网络研讨会,研讨会或者订阅我的YouTube频道。否则,我现在要做的是,我会在森林里待一会儿,我们煮杯咖啡,我们吃点东西,然后绕一圈,然后回家,为了你,享受剩下的会议,保证安全,再见。

