DEMO -多云安全软件供应链

你好,每个人。这是Matali Bisht。我是JFrog的一名软件工程师，作为合作伙伴工程团队的一员，从事不同的社区相关项目。谢谢你！

大家好。我叫Victor Szalvay。我是外派产品经理。我在Google Cloud工作，特别是在我们的DevOps产品套件中。

谢谢你们，维克多和米塔利。首先，热烈欢迎参加DevOps Cloud Days会议的各位。我们真的很高兴你能来。今天我们将从JFrog和Google云平台的DevOps软件安全开始。

我们还将做一个关于Artifactory和Xray的演示，这是我们在JFrog平台上的旗舰产品。hth华体会最新官方网站对于那些不了解这些产品的新手来说，Artifactory是我们的二进制存储库管理解决方案，Xray是我们的通用软hth华体会最新官方网站件组合分析解决方案。我们还将更详细地回顾它们。

简单介绍一下JFrog的背景，我们成立于2008年。目前，我们在全球11个办事处拥有1000多名员工。我们是一家真正的混合型公司，既提供SaaS服务，也提供跨多个云的自托管服务。

我们是一个值得信赖的解决方案，在不同的垂直领域有6000多家客户。正如你所看到的，JFrog为大多数财富100强公司提供支持，包括Netflix、HBO、谷歌、Twitter、VMware等公司的软件更新，并真正使其易于管理，并以支持世界级服务的速度交付软件。

我相信你们都见过DevOps的无限循环。在JFrog，我们称自己为流动软件公司。我们是一个端到端的DevSecOps平台，用于为所有软件更新提供动力。我们真的建立了一个平台，让你从代码到云。

现在，让我们花点时间看看JFrog平台是如何为DevOps提供自由选择的。如果你是一家软件公司，你的组织中有许多团队，你的开发人员正在构建应用程序，使用不同的技术堆栈，比如Java, Node.js, Docker等等。

现在你可以清楚地看到，在DevSecOps生命周期中，你需要对所有的需求进行优化和标准化。现在，这些要求是什么?这可能是围绕……你如何存储你的工件和依赖项。如何保护二进制文件?如何分发二进制文件、编排管道、自动化等等。

当你谈论所有这些不同的东西时，你需要DevSecOps生命周期的一致性。除了一致性之外，您还需要一个统一的平台，为您提供跨DevSecOps生命周期的单一视图窗格。这就是JFrog平台真正的亮点所在。正如您在这里看到的，JFrog平台是一个端到端的DevSecOps平台，旨在扩展，从根本上通用，并通过丰富的集成合作伙伴生态系统提供持续的安全性。

现在，在我们进入参考架构和演示之前，请允许我向您介绍JFrog Artifactory和JFrog Xray。现在，JFrog Artifactory被认为是所有二进制文件和依赖项的唯一真实来源。它是JFrog平台的核心，它确实采用了一种开放的方法，并为您提供了自由选择，以便在您的生态系统中集成流行的CI/CD以及监控工具。

此外，它还用于代理远程存储库。它将适用于市场上现有的所有CI工具，我们几乎与所有这些工具都集成在一起。您使用Articafactory来真正管理您在公司、业务单位或全球组织中为软件发布构建的工件。现在Artifactory是二进制存储库管理解决方案的领导者。

人工是普遍存在的。它集成了27个不同的包管理器。它提供了一个完整的记录系统，这意味着它为所有支持的包格式提供了元数据。它还提供基于校验和的存储，这实际上意味着，如果您在不同的存储库中拥有相同的二进制文件，那么您确实对存储进行了优化。它提供了一组丰富的自动化工具，主要使用REST api、cli和插件。正如我前面所说的，它与用于CI/CD的自动化工具具有丰富的集成集。

一旦您在Artifactory中拥有了这些工件，您还需要了解与这些工件相关的安全性和遵从性风险，以及如何减轻它们?正如您所知，今天编写的软件中有80%到90%是真正的开源软件，这暴露了安全漏洞、许可遵从性问题和性能问题。

这张幻灯片真让人大开眼界。正如你在去年看到的，供应链攻击的数量有所增加。去年真的涨了650%。我们知道，在我们想要了解它如何真正影响组织的安全之前，我们想要真正定义什么是软件供应链攻击。它基本上是一种黑客将恶意代码或组件植入可信软件或硬件的技术。

以下是列出的事件时间表，但更重要的是，最近发生了更多事件，并导致了软件供应链攻击。最近的一些事件还包括2017年的Equifax事件，apache stretch的Java依赖导致了大约1.4亿人的数据泄露。

同样，在2008年，当思科被自由软件基金会起诉时，因为他们在一些产品中使用了GPL许可证。hth华体会最新官方网站他们因此遭受了很多损失。这给我们带来的关键问题是，了解哪些软件感染了漏洞是很重要的。我在使用它们吗?如何在不影响开发速度的情况下修复它们?这正是x射线能帮你回答的问题。它是一个自动化的软件安全解决方案，适用于从代码创建到发布分发和生产的整个软件生命周期。

它与Artifactory进行了深入的本地集成，并提供了一个单一的窗格视图。它还有助于深入挖掘每个构建包的所有依赖项。如果您正在使用Docker，它将帮助您递归地深入扫描所有Docker映像和层。它还提供了全面的漏洞情报，加上不同来源的数据库，包括我们的Xray产品中使用的vulndb。在介绍了Artifactory和Xray之后，我认为现在是时候让Victor来谈谈JFrog Google Cloud DevOps参考架构了，接下来是Mitali的演示。维克多，你这边。

嘿，谢谢你，尚卡尔。正如Shankar所指出的，真正令人兴奋的事情之一是，当你在你的DevOps工具链中使用你喜欢的组件时，你拥有的可选性，无论是在Artifactory和JFrog中，还是在Google Cloud中。今天，我们想带你通过一个混合用例场景的演示，我们使用谷歌云组件，但我们也使用JFrog Artifactory和x射线在这个工作流程。从左下角开始，你会注意到我们只是在开发人员进行PR或提交时开始工作。这个基于git的操作将在名为Cloud build的产品中触发构建。Cloud Build是一个灵活的DevOps自动化平台。它允许你在不显眼的容器中运行步骤。第一组步骤基本上会生成一个npm构建。该构建将被传送到JFrog Artifactory。

从那里，它也将被扫描与x射线。我们将在构建过程中看到一些漏洞结果。下一个云构建将继续将我们实际构建的应用程序容器化。稍后，Mitali将更详细地介绍应用程序，并向您展示我们正在构建的内容。这是本演示的一个示例应用程序。一旦我们被容器化，我们还将把它移回Artifactory以存储在Docker存储库中。此时，我们将进行二次扫描，以确保底层操作系统和容器本身没有引入的漏洞。我们会看到两种不同的扫描结果。接下来我们要做的是触发释放。这次发布，一旦被触发就会流向云部署，谷歌云部署是一个新产品。

您可能听说过云构建，云部署是一个新产品。基本上，它的目的是为Google Kubernetes Engine或GKE提供一个完全托管的持续交付平台。该产品允许您定义一个发布候选版本，并在其生产过程中通过任意数量的环境推进该发布候选版本。您还可以在任何步骤中插入批准步骤。例如，在本例中，我们将有三个不同的环境，您可以在顶部看到它们，测试、登台和生产。我们将在通往生产的道路上通过这些环境。在最后一步中，当我们接近生产时，我们将有机会看到它是如何与审批门一起工作的，因此特定的步骤需要批准。我们在里面也会看到。我想现在我要把它交给米塔利，他将带领我们完成实际的演示，我们将首先获得一些信息。米塔利谢谢。

谢谢你，维克多。在这个演示中，我将展示一个云构建文件，它是一个云构建YAML，它被用来对映像进行JFrog构建，并将其推送到Artifactory。在云构建YAML中，我们使用JFrog CLI。JFrog CLI是一个非常强大的工具，可以与Artifactory和Xray一起工作，因为它具有所有内置命令。我们将在这里使用的各种命令首先用于配置Artifactory服务器。然后我们将使用JFrog rt npm install来验证应用程序的依赖关系。然后我们将使用npm publish来打包和部署应用程序。最后是build publish，我们将把build-info推送到Artifactory，这可以进一步用于各种CI服务器，如Jenkins和所有。最后，我们将对该应用进行Docker构建，以容器化并将Docker映像推送到Artifactory。为此，我们在Artifactory中需要两个仓库，一个用来存放Docker仓库，另一个是npm仓库，用来存放所有依赖项和应用本身。

此外，对于Xray，我们需要配置手表和策略。让我回到JFrog平台。这是一个SaaS平台。这被称为JPD，意思是JFrog平台部署。在这里你可以看到所有的JFrog产品在一个地方，人工分配管道和hth华体会最新官方网站x射线。从演示的角度来看，我已经为Docker和npm创建了仓库。对于npm存储库，我们有三个存储库，分别是本地、远程和虚拟的。

如果我做Cloud Days，我在这里有一个Cloud Days, Cloud Days。本地存储库什么都没有实际上是你的实例本地的所有应用都部署在那里。Cloud Days Docker将用于将你的应用程序的Docker镜像放在Cloud Days Docker本地存储库中。就远程存储库而言，当您想要使用远程URL时，远程存储库非常有用。我已经建立了一个云天远程回购。最后，我们会有一个虚拟的回购。虚拟repo，你可以把它称为组repo，用于对多个本地和远程存储库进行分组。如果我看到我的虚拟回购，我进入它，我可以看到我有云之日本地和云之日远程。现在，当我设置了存储库后，我需要使用Xray来了解这些存储库是否存在漏洞。

因此，我们可以看到所有这些东西。我们可以为他们做x光检查。它们已经被索引了，所以如果你看到Docker, Cloud Days Docker, Cloud Days本地和[听不清00:15:56]正在被索引，以便x射线监视漏洞。为了确定你想看到的漏洞是什么，是高、低、中等，以及你想采取什么行动，我们必须设定什么是政策。策略基本上是一组规则，您可以定义这些规则来显示您一直在寻找的漏洞类型或严重级别。所以这里我说的是Cloud Days high policy，也适用于手表，所以policy是索引列表，直到它们被应用到某些东西上。手表是我们使用这些策略的地方。在云天守望中，我已经说过，我使用的是云天高的政策。

另外，如果你在这里看到资源，我正在2022世界杯阿根廷预选赛赛程使用我的构建，这是我的云构建，然后构建扫描。正如维克多提到的，我们在这里做了两次扫描。一个是我们的构建被扫描，还有我们的仓库，也就是Docker的仓库被扫描。如果你想采取任何行动，假设如果你想，让构建失败，如果有任何严重性，或者如果你想停止下载，你都可以在你的手表中定义。现在，回到应用，我们有一个非常简单的应用。

这是一个npm应用程序，一个一页的应用程序，它显示了GCP和谷歌云和JFrog的标志。我有云构建。Yaml和clouddeploy。Yaml，所以是cloudbuild。如上面所示，我们有不同的步骤来配置Artifactory。这里我使用GCR图像，这是谷歌云注册表。我们已经将npm JFrog CLI的Docker镜像推送到这里，对于每一步，它都会启动自己的Docker容器并运行这些步骤。所以定义我们要处理的目录是很重要的。因此，这里我们使用JFrog CLI Docker映像来配置Artifactory，并执行我在这里定义的所有步骤。这里还有一件事要注意，出于安全目的，我们在Google Cloud中的秘密管理器中保留了所有这些秘密。为了访问Artifactory，我们需要访问令牌。该访问令牌在Secret Manager中定义，并在此处引用。 Once, if I trigger… If I make any changes in this file and do a get push, I have a trigger in Cloud Build.

我在Cloud Build中触发了这个触发器，它实际上开始运行并开始旋转所有这些步骤。如果我去查看我的仪表板，我最近运行了一次，最后一次运行显示了所有这些步骤，它在云构建中正在做什么。一旦这个云构建完成了，它会做什么呢?它会在我们的Artifactory中创建一个npm构建，也会创建这个应用程序的Docker镜像。让我们回到JFrog平台来看看构建的结果。首先，通过包，我们正在寻找车间应用程序，我们已经建立了这里，npm包。如果我输入…这是车间应用程序n包。我们在这里看到的第一个版本已经部署。我点击这个版本。我可以看到README文件，这实际上是在这里已经从GitHub拉出来，然后我可以看到与此相关的构建。所以构建是两个，这里已经定义了。

我们可以看到与之相关的存储库，所以我们创建了Cloud Days本地，它与这个构建相关联，我们可以看到与之相关的x射线数据。我们这里有一个违反执照的。所以x射线显示了漏洞和许可证违规。我们可以在这里看到它的细节，以及可以做些什么来补救。如果你去这里的后代，它会给你一个很好的依赖关系视图。现在让我们去看看Docker映像。我们把推送的Docker镜像称为npm app。

这就是我们回到包和npm应用程序的方式。这是今天推送的最新的云构建。如果你看到关联的存储库，它就是我们创建的基于can的Docker。现在进一步深入到Docker映像的那个版本。我们可以再次看到存储库并返回到它们的x射线数据。我们可以看到与这个特定图像相关的所有漏洞。现在我们在这里找到了13个漏洞，如果我选择其中的任何一个，我可以看到一个非常好的数据视图，它说的是什么。它显示了严重程度，它显示了CVSS分数。此外，它还向您展示了最重要的事情是修复版本。如果您真正更新组件，大多数漏洞都会得到修复。这里说的是2.2 0.5-r4是安全版本。

现在它用的比这个少。此外，在总结中，您可以看到这个漏洞所讨论的内容。还有，哪些版本是易受攻击的。尚卡尔说过，x射线给你扫描你的图像或扫描你的软件，它会进行深度递归扫描。它会扫描Docker映像的每一层。它扫描您的软件或任何其他东西的每个JAR。这个影响路径实际上显示了这个漏洞的位置，或者它位于哪个特定的依赖项中。此外，它还为您提供了一些参考资料，以了解有关该漏洞的更多信息。我想再强调一点用[绿色花朵00:22:55]任何被标记为这样的CV，它都有更多关于严重程度的丰富信息。

在JFrog，我们有自己的研究团队，他们每天都在分析每一种严重程度，并为此提供良好的补救措施，看看它们到底是严重、中等、高还是低。如果您看到外部数据库提供的严重性是关键的，但是当JFrog团队手工分析它时，它发现它是中等的，因此我们可以在想要修复它时优先考虑。此外，您可能希望进入JFrog研究严重性原因，以查看它解释了关于严重性及其路径的哪些信息。

来源咨询，也会给你版本，描述和影响部分。现在，既然我们已经看到了这些漏洞，如果您修复了任何版本并从操作中推送了一个新的Docker映像，您可以再次扫描违规行为，甚至可以从中分配自定义问题。此外，您可以从这里导出所有这些漏洞的数据在Excel文件中。这为您提供了非常方便的工具。最后但并非最不重要的是，我们想看到的是我们创建的npm构建。如果我输入并构建一个npm构建，那么我到这里…最近使用这个云构建，我已经创建了第二个构建，我已经拉了。点击build 2，可以看到workshop/app, npm app在这里。它给出了它所拥有的藏物的数量。它给出了依赖项的个数。此外，它还显示了此构建的x射线数据，因为这也扫描了漏洞，并显示了所有安全和许可违规。

它向你展示它所发现的和未知的许可证。最后，它会给你建筑。JSON，我们可以用它来进行持续集成和交付。这就是人工x射线显示的所有组件。一旦构建完成，它实际做的是在云部署中创建一个发布版本，对于云部署，我将把更多的内容交给Victor来解释。

好吧。米塔利谢谢,。正如我所提到的，云部署是一种新产品，主要关注于GKE的持续交付。我们要做的第一件事是看一下如何配置云部署版本和管道。这是管道配置。在顶部，您可以看到这是KRM风格的格式，因此这是实现持续交付的声明性方法。从第7行到第10行可以看到。你可以看到我们定义的不同阶段。现在这些对应于测试阶段和产品环境，我们之前讨论过。这些目标在下面有进一步的定义。 For example, starting with line 13, you can see that the test target is being defined. You can give a description, but more critically on lines, 18 and 19 you can define the underlying Google Kubernetes Engine cluster for which that target corresponds.

你可以看到项目被定义了区域，位置，集群运行的地方，还有集群的名字。我们稍后将在GKE中看到这些集群，但这只是提供了一些映射。现在，再往下，您将看到登台集群，这是有意义的，登台目标，底部的最后一行定义了生产集群。现在请注意第36行，我们基本上以声明的方式定义了一个批准需求。在这种情况下，通过将真实标志添加到所需的批准中，我们基本上是在说，对于特定的目标，在启动到该环境之前必须有一个手动批准门。好吧。让我们来看看云部署及其工作原理。在这里的云部署中，您将看到这三种环境，以管道样式进行测试、分段和生产。

你还会注意到，在staging和prod之间有一个零等待选项。如果我们对该产品有等待批准，至少我们会看到它们在那里排队，但现在我们没有。如果我们想看一下发布细节，我们可以点击这个。云部署中的一个版本基本上是已完成的配置和对工件的引用的总和，即为该特定版本定义的映像。在这个特殊的例子中，你可以看到我们有一些注释。例如，与此特定版本相关联的提交消息或提交SHA。我们可以点击文物标签。在这里，我们可以看到发布内部发生的事情。你可以在那里看到构建工件，这是Mitali推送到Docker仓库的映像。

你也可以在渲染源部分看到，它包含了预渲染的Kubernetes配置，预渲染的清单。在最下面的部分是目标工件，它包含各种呈现的清单以及其他信息，如管道细节和其他一切，这样我们就可以根据需要重新创建那些版本。你会注意到这里有test, staging和prod表示，那是因为在发布创建时，我们实际上快照并同时呈现所有的环境清单。所以我们渲染一切，快照并存储。好吧。让我们回到管道上来看看。

当然，我们有CLI和其他形式的API风格的方法来实现这个，但在UI中你可以提升。我们27分钟前刚刚发布了那个版本。我们现在要推广它。当然，我们想知道我们在推广什么，对吧?什么在那里，什么将被取代。我可以进入manifest diff，看看这里主要的变化是我的图像，如果我满意，我可以点击下面的promote。我们来做一下。

您可以看到推出已经开始。一旦它完全启动，我们将在这里看到一个更新，表明它是成功的还是失败的。现在，如果我们点击view latest rollout，我想我们也能看到日志。渲染已经完成了。这是发布创建的一部分，但是我们也可以看看实际的发布框。现在我们来看看这个，看看这个已经成功完成了。你可以看到驱动成功了，我们会回去在主UI中确认。好吧。所以驱动发生了。现在，下一步将是将其推广到生产中。 We’re going to go through the same type of process. We’ll do a promotion. We can compare what was there, what’s going to come. We can also diff the manifest again to take a look at that. If we’re satisfied with everything and it all looks good, we can go ahead and click promote.

在这种情况下，有趣的是我们设置了一个审批门。这不会自动启动。我们首先需要手动批准这个。在这个特殊的例子中，我是一个超级用户，但是你可以想象有一个操作团队，这个团队有特殊的权限来做这些审批。所以进入审批队列，我可以看到我有一个审批队列。你可以再次看到类似的信息。现在有什么?我要批准的。我还可以再核对一下舱单。基本上在底部，它给了我批准或拒绝推出的机会。 I’m going to go ahead and improve it. Now, again, it’s letting me know that I’ve got nothing queued up within my approval queue, and I’m back at the main pipeline view, watching the actuation take place. That’s cloud deploy. Hopefully it gives you a sense for how we would do continuous delivery out to GKE in a safe and controlled fashion. Back to you, Shankar.

谢谢,维克多。希望这对你来说是令人兴奋的。我们看到Artifactory如何被用作您所有购买和依赖的单一事实来源，以及Xray如何真正让您快速看到您的软件安全问题。看看你如何把它们按优先顺序排列，以及如何有效地解决它们。这给你带来的是让安全团队安心，让开发人员能够更快地开发软件。如果你很兴奋，想体验JFrog和Google Cloud的强大功能，你现在可以在Google Cloud上获得30天的专业团队免费试用。按照说明操作。去谷歌市场在给定的链接，选择JFrog云专业团队，并点击订阅。您应该已经准备好运行JFrog平台了。希望你们所有人都能体验到这种力量。 Thanks for attending this session. We will now open it up for Q and A. Thank you.