使用DockerHub和Artifactory来保护开源包

Shane Fry, RunSafe Security安全工程副总裁
Dinesh Nagarajan, IBM执行合伙人和全球能力主管

在本次会议上,RunSafe Security重点介绍了它是如何使用Docker Hub和JFrog Artifactory一起构建和管理超过15个开源包来分发的,这样它的客户就可以享受安全保护,而不会减慢开发人员的速度。

该演示演示了Docker Hub - Artifactory在管理这些产品时的组合,同时统一了一种安全方法。hth华体会最新官方网站

它包括跨国It基础设施团队如何轻松部署这些安全容器的示例。RunSafe还分享了其他DevOps团队如何将安全保护整合到他们的CI/CD管道中,在使用Docker Hub时保护自己的代码,通过Artifactory加强第三方二进制文件,并最终实现安全云工作负载的持续交付。

这个过程减少了零日攻击,加强了您的软件供应链并保护了您的客户。

视频记录

大家好,欢迎使用Docker Hub和Artifactory来保护开源包。今天我们要讲一些不同的东西。但在我们开始之前,让我们来认识一下演讲者。我是Shane Fry, RunSafe安全公司的安全工程副总裁。我在进攻和防御网络方面有超过10年的经验,涉及很多不同的领域。从底层的物理安全,硬件电路,一直到web应用程序安全,我都做过。

虽然我的大部分时间都在研究用户空间和内核空间目标的内存损坏,无论是在防御方面,还是在漏洞研究方面。我还花了一些时间做系统的安全架构和设计,包括审查和提出安全设计。

今天和我谈话的是Danish Nagarajan,他是IBM安全服务的合伙人,他在网络安全领域有20多年的经验,领导着IBM安全服务的很大一部分。他关注的领域是应用程序安全、DevSecOps转换和网络安全服务。这也很酷,他在英国的伦敦,所以我们可以一起工作,在大洋彼岸。

轮到你们丹麦人了。哦,对不起,我们要先做议程,然后再讲丹麦语。我们要做的第一件事是讨论开源和应用程序安全的行业状态。因此,作为DevSecOps领域和应用程序安全领域的行业领导者之一,Danish将在这里提供他的见解,他将讨论围绕开源和应用程序安全的一系列不同统计数据,以及它们对业务的影响。然后,我们将讨论RunSafe如何交付加固的开源软件,以帮助减轻一些开源安全问题。实际上,大部分的讨论都是关于开源交付的挑战和解决方案,这就是artifactory出现的地方,以及我们如何使用artifactory SAS产品来解决这些问题。所以我将把它交给Danish来讨论开源和应用程序安全性。

谢谢,谢恩。谢谢你的介绍。我们看下一张幻灯片。因此,我将花几分钟谈谈开源软件,以及开源软件的影响,总的来说,还有应用程序安全性的总体影响。

许多人没有意识到的一件事是开源软件在当今企业中的普遍性。这张幻灯片上的一些数据在这个背景下让人大开眼界。超过44%的组织计划在未来几年内投入大量资金用于开源软件的使用。当他们开始使用开源的时候,我们已经看到这种趋势正在增长,你知道,不仅仅是在中小型公司。我们还看到大型企业和全球性组织服务于开源,甚至规范的行业也开始在其企业应用程序和业务应用程序平台上使用开源软件。

作为开源的一部分,其中一个有趣的事情是,超过60%的组织认为开源软件实际上是构建其关键平台和应用程序的关键。因此,今天大多数组织使用的开源软件程序对于支持他们的关键生产力和关键应用程序来说是非常重要和关键的。这正好反映了开源的重要性,在今天的大多数组织中都在使用开源。

虽然开源软件的数量在显著增加,但我们也看到超过49%的组织在努力识别开源组件中的漏洞。开源具有某些独特的特征,这使得它在安全元素和识别漏洞方面更具挑战性。然而,这种情况正在显著增加,并且今天大量的客户都在努力识别漏洞并实际修复其漏洞。因此,虽然开放源代码的使用在不断增加,但应用程序安全性的一般状态也是我们需要关注的一个问题。

应用程序安全已成为当今网络安全威胁最流行的载体,我们所看到的许多原因破坏基本上都是利用应用程序安全漏洞。应用程序,你知道,层和向量为攻击者提供了更丰富的环境,也提供了更多的吸引因素,你知道,破坏和攻击,实际上泄露数据,或者导致或破坏网络。

你知道,侵入企业外围网络不再是一个挑战应用层的威胁向量空间更丰富,也更容易受到攻击。您知道,除了攻击者对应用程序安全性的攻击增加之外,还有超过63,000份安全事件和利用企业应用程序的报告。这是一个典型组织中应用程序的现状。更重要的是,除了新的边界之外,一个关键的统计数据是,超过四分之一的这些漏洞在上线之前没有得到修复。因此,这些应用程序是在生产环境中运行的,存在一些不存在的漏洞没有打补丁或没有进行补救,并且很容易受到攻击和应用软件的破坏。

随着对应用程序的漏洞关注的增加,我们看到对开源软件的关注将会逐年增加。随着企业开始使用开源软件,这是一个众所周知的信息,对于威胁行为者来说,这是一个他们可以关注的空间领域,你知道,使用这个平台来侵入应用程序,你知道,创建安全桥梁。影响企业的一个众所周知的开源漏洞是“心脏出血”,它影响了超过50万个网站。那么解决方案是什么呢?我们已经看到了应用程序安全领域的挑战,我们还注意到……以及一些普及名称是开源的问题。

从IBM安全的角度来看,我们认为DevSecOps是一个可以改变这种平衡的机会。有了DevSecOps,你知道,安全性被集成到DevOps中,组织可以在开发生命周期的早期加强安全性。安全需求,已知的安全漏洞可以在软件发布到生产环境之前识别和修复,并且可以在此过程中对其进行测试。

虽然存在已知的漏洞,但修复安全性的方法之一是为运行时应用程序组件提供足够的安全功能,以确保应用程序在运行时受到保护,免受已知的威胁和漏洞的侵害,并且减轻了安全威胁,降低了风险,并且应用程序的部分不会发生变化。

一旦应用程序使用您的开发操作部署,您还可以监视部署的软件,以确保应用程序在运行时,安全威胁被识别,并在持续的基础上得到缓解。使用DevSecOps的关键要素之一,使用DevSecOps的关键优势之一是我们所看到的,超过50%的应用程序安全性可以通过在DevSecOps机制中采用安全设计原则来解决。

太好了。IBM安全…,请下一张幻灯片。从持续安全的角度来看,IBM安全已经对如何集成和自动化DevSecOps有了自己的看法,要想非常成功地集成安全和DevOps实践,需要考虑一些关键组件,但从根本上说,它形成了两个关键领域。

两个关键领域的安全。一个是在DevOps生命周期内安全开发所需的关键元素,但也包括监控和实际学习,并在开发过程中有一个学习周期应用程序在生产环境中运行。所以这里有一个非常重要的因素,那就是一个连续的过程。这不是一劳永逸的。我们觉得使用DevSecOps功能,你可以解决我们今天讨论的一些挑战。你知道,这是一个非常快速的自我介绍,介绍了应用程序的安全状态,以及开源软件的挑战。

谢谢,丹麦。现在,在我们讨论为什么要加强以及如何加强开源解决方案之前,我们将在这里做一个快速演示,我们将通过Danish刚刚谈到的这些漏洞之一,看看它们如何影响您今天运行的现有开源解决方案,以及您环境中的专有解决方案。我们这里有一个浏览器中的演示环境,它在catacota上运行。因此,我们将通过构建一个易受攻击的应用程序,利用它,然后我们将讨论RunSafe为开源解决方案提供的保护,向您展示该漏洞不起作用,然后我们将讨论如何使用Artifactory提供强化的开源解决方案。我们这里有三个小窗口,左边是循序渐进的文本,我们不用担心这个,我不会读给你们听。然后在顶部,我们有一个编辑器,现在我们有一个Docker文件,它将构建我们的应用程序,我们将安装,构建编译器的基本要素,我们将安装Python来进行实际利用,然后我们有一些易受攻击的应用程序的源代码。

我们将构建它,然后我们将能够运行它。这里我们要运行这个易受攻击的应用,叫做验证密码,它输入一个密码,在这个例子中,密码是超级安全的,它会为你打印出一个秘密信息,是0天或数字。现在我们已经知道了,我们将快速浏览一下这个漏洞利用脚本。

这是在Python中,它使用了一些本地的东西来实现一个非常可靠和健壮的漏洞利用。现在我们要用我们的漏洞运行相同的程序。我们可以看到,我们没有打印0天或数字,而是打印了一条错误信息,说,嘿,这个密码不正确,但是我们最终进入了shell环境。显然,在我们的shell环境中,我们将处于程序运行的任何级别我们可以做操作系统,我们可以修改文件,我们可以从系统中取出文件,等等。所以我们现在要退出了。我们将快速修改这里的安装我们只需要做一些改变,我们将添加一个新的阶段来复制一些文件,我们将复制这些文件,然后我们将添加一个脚本来安全地构建它。现在我们要重建它,就像我们之前做的一样。我们会看到,当我们正常运行程序时,一切都是一样的。当我们在攻击环境中这样做时,我们会看到攻击失败。所以很快,我们可以看到未受保护的版本仍然有效,我们可以看到漏洞仍然有效。现在,当我们运行受保护的那个,我们会看到,由于某种原因,它没有变大,好了。所以我们看到当我们正常运行它时,它会工作。这是这里的关键,当我们谈到强化开源时,我们不想做的是让客户用户在他们的应用程序运行时,使用开源的功能非常不同,或者完全不同。

但是现在我们利用这个漏洞,我们看到了相同的无效密码消息,但是我们看到了段故障,程序崩溃,所以攻击者并没有成功地控制系统,他们实际上没有控制系统。

那么我们的产品适合哪里呢?hth华体会最新官方网站你知道,当我们谈论保护开源解决方案时,你知道,我们在很多地方获得开源,我们在某些情况下将开源软件作为源代码,人们在构建过程中将其作为软件依赖项使用。

这里有一些非常有趣的供应链安全问题,你可以看看,深入研究,并真正解决。这就是像JFrog Xray产品这样的东西可以帮助你找到现有开源软件中的漏洞的地方。然后我们还设置了可以提供这些保护的构建时间。

今天我们将更多地讨论回购方面,这是我们托管已经加固的开源解决方案存储库的地方。稍后我们将讨论一种新的功能,我们称之为Alkemists square,它更多地是在监控方面,但是Flare真正酷的地方在于它将能够与您的测试环境和Artifactory集成,为您提供一些您以前可能从未有过的新见解。因此,让我们来了解一下为Artifactory或通过Artifactory提供开源解决方案的一些挑战。因此,第一个挑战是保持软件更新。

真的,你知道,这是有问题的,因为微软有补丁星期二,你知道,每个人都知道周二,每个月的第一个星期二,我想是,会有补丁出来,我必须去更新我的系统。但对于开源解决方案或软件来说,并没有真正的标准补丁日,也没有发布新版本的标准日。所以这些时间表是零星的。

没有真正的网钩。你知道,对于那些网络开发者和使用网络钩子告诉你所有正在变化的东西的人来说,在开源空间中你并没有真正拥有这些。因此,我们需要确保当我们提供开源解决方案时,软件总是更新的,我们的客户得到的是最新最好的,这样他们就有了最新的功能和最新的安全修复程序。所以每天,我们都有一个git实验室CI管道,我们运行它来重新构建我们提供的所有软件,无论是Docker的,Deb的,rpm的,我们可能很快会有一些apk。所以我们每天都在开发软件,但是我们如何确保我们得到的是最新的版本?我们做一些不同的事情。

对于Docker镜像,我们会从Docker Hub中获取最新的版本和所有最新的标签,然后使用GitHub存储库来获取最新的Docker文件,将所有这些文件拉到一起,然后构建最新的Docker镜像并将其推送到Artifactory,从那里发布。

对于我们的开发人员和rpm产品,我们构建最新和最好的源rpm和源选项卡,并将它们推送到Artifactory。

下一个大挑战是分销。因此,在Alkemist的帮助下,我们通过apk (Alpine)、rpm (CentOS、Fedora、Red Hat)、dev (Debian和Ubuntu镜像)以及Docker (Docker)来提供我们的开源和主要产品。因此,维护所有这些基础设施,能够不断确保基础设施提供最新最好的版本,这真的很有挑战性。所以Artifactory是一个很自然的选择,而Artifactory软件作为一种服务也非常适合我们,因为我们想要确保我们总是拥有最新最好的Artifactory版本,而不是我们想要的不得不担心cdn,担心如何确保我们的软件…我们的交付存储库是安全的。

我们可以利用Artifactory和SAS的产品来实现这一点。然后另一件事是,当我们发布我们加固的开放源代码时,我们依赖于我们的一些主要软件包。所以即使我们要运行我们自己的存储库,我们也要经常担心这个问题,好吧,我需要这个包在15个或20个不同的存储库中,所以我们要做很多工作来保持这些文件的副本,我们会有巨大的,你知道,膨胀的磁盘存储使用量。所以我们混合了虚拟仓库和本地仓库,我们实际上总共有34个仓库。

随着我们添加更多的包和更多的产品,这个数字会有所变化和增长。因此,我们使用本地和虚拟存储库的混合,使我们能够具体地说,嘿,这是所有的Apache包,这是所有的节点包,这是所有的Redis包。但是当我们想要向客户公开时,我们只需要给他们虚拟存储库。所以他们总是有最新最好的版本。但是我们可以更容易地管理本地存储库中可用的版本。然后我们还利用这些本地存储库进行开发和测试。这样,我们就不必为我们提供的所有东西列出软件列表,我们可以只关注开发或测试工作中我们想要关注的一个东西。

我们面临的下一个挑战是可发现性。所以如果你去看看大平,RPM包库,甚至Docker本身,都有一个可发现性问题,对吧?Docker Hub有一个很棒的搜索功能。但是,你知道,这是有局限性的,当我们考虑如何为人们提供一堆不同的软件包时。然后,你知道,开发者和rpm,你最终会得到一个HTTP列表,对吧?这就是文件结构,你需要一直点击确保你在正确的目录中。

我们不希望人们这样做,我们希望能够展示最新最好的版本,以及我们拥有的所有标签。现在,通过我们当前的仓库,我们有8个不同的开源包,大约1098个Docker映像,以及所有不同的标签和我们在这些包中支持的所有不同版本。所以我们需要一种方法让所有这些都能被发现,这样寻找特定标签版本的人就能很快看到我们是否支持该标签。右边这个是我们回购网站的测试版这显示了所有不同的标签。

你可以看到我们有所有不同的发布图像散列,然后是所有匹配这个散列的标签。所以我们利用Artifactory REST API在用户浏览网站时动态生成这个。

所以很明显,如果你使用App或Yum来安装你的包,这对你来说是不可见的你只需要安装一个包,然后就结束了但是对于Docker,我们想让它真正可见。因此,用于列出所有标签和给定存储库中所有版本的其他api,对我们来说非常容易利用到动态更新的前端,并且始终是最新的。我之前提到过,我们有一些功能即将推出。我们来深入研究一下。

我们有Alkemist: Flare作为一个产品模块,它允许您在软件进程崩溃发生时对其进行监控。那么这和Artifactory有什么关系呢?

你知道,这和今天的演讲有什么关系吗?我们发现,在开源解决方案中,没有一个很好的方法来监控这些解决方案何时崩溃,对于那些做DevSecOps的人来说,他们正在构建软件,部署它,不断地测试它,当测试失败时会发生什么,这是一个挑战,

你要做的第一件事就是对测试失败进行根本原因分析。JFrog Artifactory试图成为DevSecOps软件开发、生产、发布、测试生命周期的中心,我们可以利用Flare数据发布关于崩溃的不同二进制文件的元数据。所以当你运行你的测试时,你会看到失败。然后,您可以利用我们提供给Artifactory的元数据来了解实际的崩溃是什么,它是如何崩溃的,为什么会崩溃,等等。所以现在Artifactory不仅可以在你的管道中跟踪你的构建,在你的测试中,还可以在过程崩溃时给你一些数据,告诉你在这个过程中什么地方出了问题,这将帮助你更有效地利用你的工程时间。这很快就会到来,Alkemist: Flare今天就可以了,但是我们还没有集成JFrog Artifactory,但是很快就会到来。这样你就能得到所有那些很棒的功能。所以很快,我们将向你们展示作为监测的一部分,哪些信息是可用的。现在我们将进入我的开发环境。我们要做一个快速的冒烟测试。

在这里,我们观察一个包,它将崩溃。我们将在Splunk中看到应用程序崩溃的数据。我们再快速运行一遍。我们可以实时看到之前没有数据的地方,我们将实时看到,现在这里有了撞车数据。我们要看这里的信号事件我们可以看到有一个叫做信号测试的命令运行,我们可以得到关于参数的信息。所以如果你有一个动态环境,你的测试接受了一堆不同的参数,你将能够利用这个来看到嘿,这个特定的碰撞测试。这个特定的测试崩溃,抱歉,这些是传递给它的参数,这是用于测试的环境变量。然后你还能看到处理器寄存器状态。

通常,如果你在GDB或其他调试器中查看这个,你会在文本中看到这些值。Splunk提供了当前的无符号整数。但是你可以很容易地把它转换成上下文,指令指针是什么,处理器在做什么。然后你还可以得到主机的信息,主机名,接口等等。然后是信号信息。所以我们可以看到,当你试图调试测试失败的根本原因时,所有这些信息对帮助你诊断非常有用。所以我想感谢大家来参加我们的演讲,并花时间了解RunSafe如何利用Artifactory来保护开源解决方案。现在我要把最后的发言交给丹麦人。

谢恩,谢谢你给我这个机会和RunSafe一起演讲。

这是一个非常有趣的演示和展示。

希望大家已经学到了一些关于如何处理开源安全的新知识。

谢谢你!

要么释放,要么死亡