谷歌云和JFrog如何创建一个安全的软件供应链

老实说，在过去的几年里，甚至在我加入谷歌的一年半时间里，我学到了很多，关于一个好的安全软件供应链是什么样子的?对于像我、你和其他人这样的开发者来说，哪些地方不是很糟糕?我们怎样才能在不那么困难的地方做到安全呢?也许我们能让做正确的事更容易。今天我们要讨论的是，为什么我们需要一个安全的软件供应链。什么是安全的软件供应链?谷歌和JFROG在这条生产之路上做了些什么，让它既安全又快速?

请继续关注。开始吧。

好吧。我说过了，我叫理查德·塞罗特。我是谷歌云的对外产品管理总监。我涵盖了容器、服务器列表、DevTools等内容，其中一部分甚至是我们的安全软件供应链工作。我很高兴今天能和你们在一起，告诉你们Google和JFrog是如何合作的，如何让做好事情变得更容易。

让我们开始吧。当然，生活中的大多数事情都是某种组合，对吧?不管我是在造一辆车，一所房子，不管它是什么，这是多种因素的组合。所有的东西汇集在一起，这些碎片会让事情变得更好。软件就是这样，我有我的代码，不管我怎么写，不管它是什么样子，一些配置，部署规范，脚本，一堆东西组成了这个工件，然后成为我们生产部署的一部分。很标准的东西，我们都做了一段时间了。也许10到15年前，你只是在传送压缩文件。现在，你在做容器。不管是什么，但我们如何包装，如何处理文物，在这个安全的世界里真的很重要。

现在棘手的是，今天我们要花很多时间讨论的是，整个软件供应链中只要有一个不安全的环节就会导致混乱。正如我们所想的那样，软件不只是我写代码，它是在生产中，你我都知道这一点。对你们中的一些人来说，这可能是一种英雄主义，而对另一些人来说，可能是每时每刻。但你仍然认识到有一系列步骤，通过构建步骤，通过打包步骤，通过其他步骤，来确保我能真正发布代码。任何一个地方，如果出了问题，我就有麻烦了。我想在上面点一下。我想看看攻击向量在哪里?当你和我试图让我们的代码生产，哪里是出错的地方?哪里会出错呢?让我们看看这些点。

首先，我可能只是提交了错误的代码。嘿，看看最近的一个研究人员的例子，他们试图故意地，为了研究目的，在Linux内核中引入漏洞。他们后来被拦了下来，但他们能走得很远的事实很有趣。有很多方法可以将错误代码首先检入到源代码控制中。第一个风险，我想我们都很熟悉。

然后，实际的源代码系统在这里受到了一些损害。在这里，攻击者，就像我们最近看到的那样，破坏了一些Git服务器的不同包管理和类似的东西，并添加了提交。好吧。所以，突然间，我觉得我安全了，但实际上，我签入源代码的地方现在是在后台给我的代码添加东西。这可不好。

在其他地方，甚至建造管道都可能被改变。对吧?它可能是对构建管道的由外而内的更改。还是那句话，我并没有真正看到，我只是在检查我的代码，其他事情发生了，这里发生了一些不好的事情。听着，我也可以让建造系统本身受损。在这种情况下，SolarWind就是一个很好的例子，有一个不良行为者得到一些不良行为和一些恶意代码，这些代码被添加到每个构建中，然后被发送给每个人。这似乎是最糟糕的情况，有人拥有静态构建环境，然后能够妥协。没有什么能真正清除或检测到那种疼痛。这是一个大问题。

依赖性，我们一会儿会再讨论这个，这是一个被低估的因素。听着，如果你和我今天用一种现代语言构建任何东西，那就是很多依赖关系。对吧?如果我是一个。net开发者，我就会使用NuGet，作为JavaScript开发者我会使用NPM，作为Java开发者我会使用Maven。我在做所有这些不同的事情。我的应用80%的代码可能都不是我写的。它是进行数据库讨论和交互的包。我有调用web服务的东西。我有一些计算的东西。我有各种各样的东西。 And so what happens if I actually have a bad dependency in the first place, or even have a good dependency that I add to my application, but then the actor actually makes a change to it and introduces intentional vulnerability later, and I’m just updating my packages? I might and not have added it in the first place be if I knew that was there, but now I’m not looking as much. So, that’s a big one. The dependency is a tricky place to check out.

当然，我可能会在CI/CD过程之外注入不好的工件。我们也看到了这种情况。所以你要小心这个。

你也可以看到包管理器被破坏了一点，在这里，你可以有一个副本。对吧?它可以有一个包管理器的镜像。相反，我用的是那个包含了一些坏包的镜像。这并不罕见，也可能发生在你身上。

我也可以欺骗用户使用错误的软件包。哦，我以为我注入了这个HTTP模块，但我的依赖项是一个HTTP1模块，这实际上有一堆不好的东西。因此，仅仅通过类似的名称，类似的提供程序名称，我就可以添加错误的包。这是一个棘手的问题。

最后，进入制作阶段。我可能会有不受保护的系统，我可能会有错误的证书，我可能会有很多东西，即使是高级证书也会让我在工作中遇到麻烦。

所以，所有这些地方，甚至更多，这里还有其他地方，但这些是我们已经确定的一些核心，甚至作为我们谷歌流程的一部分，以确保我们正在加强和保护这些环境。你也要面对所有这些。所以想想这些都很重要，就像我们谈论依赖关系一样，对吧，信任从哪里开始起作用。看看GitHub上排名前1000的项目。我认为7万左右是其中的中等贡献数。当你发布代码时，你可能会有10万人以某种方式接触你的代码，因为你使用了所有这些开源依赖，有很多贡献者，这很棒，但我有很多人参与这些代码。我怎么知道第三或第四阶依赖关系是安全的呢?突然之间，我在这件事上不能把头埋在沙子里。我必须有更多的透明度和情报，这里发生了什么?我的依赖项的依赖项是什么? Are those safe? What’s going on there? I can’t leave this to the InfoSec team. I can’t leave this to my production platform, SRE team, whatever. This is, all of our responsibility. Right? Secure code is not something we outsource. It’s something we in source. It’s something we care about here.

有几件事我们需要考虑。首先，我如何重新思考或重新考虑?我如何信任外部供应链?数据显示，高达84%的商业代码库至少有一个活跃的开源漏洞。这可不太好。对吧?这就是黑客是如何通过这些漏洞渠道发生的，在很多情况下。我们必须重新思考和考虑的第二件事是，我们如何做安全以跟上速度?相当一致的是，当我们看我们的数据时，我相信你们自己的环境，我们运送更多的东西到更多的地方，更频繁。天哪，如果我注入了漏洞，那简直就是噩梦。 If I have more components in my code, it’s more distributed, more services, more things like that, I’m shipping it more often, and I’m dropping it to public clouds, private clouds, edge locations, different DevTest environments. One vulnerability hidden in one place, my blast radius is enormous now.

那么，我该如何思考这一切，而不是因为害怕而放弃编程去当图书管理员呢?有时候我们都有这种感觉。不。相反，我们应该说，我想继续发布令人惊叹的软件，但我想要安全，我想以一种不容易注入漏洞的方式来做，即使发生了不好的事情，我也有一个很好的过程，我能捕捉到它，关闭它，修复它。这是完全可以实现的。

我们看到这已经超越了技术人员谈论事物的范畴。我们看到美国政府的行政命令说，现在有一个关于安全软件供应链的期望。我们希望我们自己的软件供应商也能做到这一点。我们期望这个行业做到这一点。现在所有人都注意到了。当每一家公司，从银行到零售商再到其他公司，现在都开始关注，我们的业务运行在软件上，突然间一个漏洞就意味着巨大的数据泄露，这意味着什么?它指的是可能存在安全风险的事情。好像这是严肃的事情。所以，我们不想扼杀创新，但是我们怎样才能把事情安排到位，让正确的事情变得容易呢?

我们在谷歌学到的东西。一些构建真正安全软件的方法。我们能建立信任吗?我们能验证信任吗?总是检查。零信任模型不只是假设它来自这个输入，一定很酷。不。我要建立它，我要验证它，我要维护它。一旦我把它寄给了prod，然后说，好吧，一切都很好，我还没做完。我们不断更新软件，它在一个非常动态的环境中运行，这是流动的。 I have to maintain that chain of trust. Can we do all this without it being super painful? I really think we can. So let’s talk about that.

技术是如何开始结合起来使这更有可能的?所以，再一次，当你在这里看你的过程，它不会感觉过于复杂，它不应该。我们考虑我提供的代码来自哪里。我在编码，导入，构建。这就是我开始建立信任的地方。我怎么能相信我带来的东西?我怎么能相信自己在做什么?我如何信任构建?酷。现在是部署它的时候了。 How do I verify? How do I verify what happened earlier? And don’t just blindly take that content and deploy it to production. Nope. I’m going to do an extra verification. And once I’m in prod, how do I continually maintain that trust? Simple, but really important.

我们如何用它作为框架来讨论剩下的问题呢?让我们想想第一部分，建立信任。这些东西是从哪里来的?我的包裹是什么?这是怎么回事?所以我们做了一些很酷的东西。开源洞察力。第三，现在就去deep。dev/，不是现在，享受这个演讲，在这个演讲之后，去看看吧。我们建立这个服务实际上是为了帮助开发人员了解他们的开源依赖。在这里，你得到一个完整的图表，所有的软件依赖关系，甚至是维护者，依赖于那个软件的东西，这很酷。 We’re scanning millions of packages and we’re updating that info sometimes even hourly. So it’s a really good up to date look at all sorts of packages from code. Today we support Cargo for Rust, Go Modules, Maven for Java devs, NPM for Node.js developers, Python Package Index for Python.

所以，你可以进去说，嘿，我要添加这个包，让我了解一下。我们必须翻转这个。而不是，我们会引入任何东西，任何能在你的代码中获得权利的东西。你应该对这里抱有很高的期望。是什么获得了应用程序代码中的权利?我要把这个随机的库拉进来吗?让我先去看看，看看是不是很酷。让我看看它还取决于什么。所以这是一个很酷的工具，可以提高能见度。我们将继续在Google做更多的工作，甚至使它更容易在您的系统中使用。 So, check this out. It’s a great way to start to establish some trust in your code.

你如何检查这些项目的更多内容?这是一回事，依赖性图是什么。这很重要，但现在让我再多了解一点。我有多相信这个包裹?我们建立了一个很酷的项目，记分卡项目。它的作用是告诉您开源项目的依赖项是安全的。这些记分卡是自动的，它们检查很多东西，你可以下载并自己对不同的包运行它，那个开源的洞察网站实际上使用这个。我们把所有的测试都叫出来。这里没有秘密。我们会给你看，我们做了六、六种不同的测试。

他们检查各种东西，比如，这个在二进制文件中检查过了吗?这是一个危险信号。您不应该检入二进制文件。这应该是构建过程的一部分。这不在源代码中。这个项目是否分配了CI测试?当你拉取请求时，它是否需要代码审查?贡献者是否来自至少两个不同的组织?所以你不会偶然得到一个短视的安全观点，你会得到一些不同的观点。它是否使用模糊测试工具? Is it injecting garbage just to see what kind of breaks and if you can hack into something? Does it use static code analysis tools more?

所以，这是一个很好的方法，至少可以对你的一些系统进行抽查。您可以在CI管道中运行它。你可能会运行这样的东西，只是为了确保，如果它有一个我不喜欢的分数，也许我甚至不会让这个东西构建。它开始给你更多关于如何建立信任的权力。你不一定是受害者或人质，不管你拉了什么包裹。您要确保这些包在您的代码中获得了权利。

那么，让我们来看看这个过程。一开始，我们就在建立信任。它始于我的桌面。你和我可能花80%的时间来构建一个应用程序，写代码，在我们的桌面，或者云IDE，或者其他地方，测试它，做任何事情。然后我们开始思考如何将其添加到信任链中?Cloud Build，我们一会儿会讲到，它做了一些很酷的事情。您也可以在工具中使用Artifactory。您可能正在使用JFrog管道。你可能在用x光。我们会讨论所有这些事情。 But this is where you start to establish trust.

我认为有一件事很重要但可能被低估了，尤其是在这个容器的世界里，我的容器来源在哪里?我的基本图像是从哪里来的?就像我之前提到的，我很讨厌Docker文件，这对我来说不是一个好主意。你从哪里提取你的基本图像?是来自供应商吗?是从码头中心寄来的吗?是从什么地方来的?你完全不担心它怎么样?

如果你听说过Cloud Native Buildpacks。这是CNCF的一个项目。从历史上看，构建包来自Heroku和Cloud Foundry，我曾在其中工作过。简而言之，它所做的就是获取源代码，为编程语言和框架确定正确的堆栈，然后构建堆栈，包括一个安全的基础映像。因此，它产生的是一个基于强化操作系统的容器映像，和正确的锁定堆栈，它是由buildpack提供的。

所以Google Cloud构建包使用的是我们精简的操作系统。它们使用了正确的强化配置，将一个紧凑的堆栈构建到一个小容器映像中，如果我愿意，只需一个命令就可以从Cloud Build中启动它。我可以在我的桌面上这样做，gcloud构建提交，然后得到一个可以在任何地方运行的容器映像。我可以把这个图像部署到Cloud Run, GKE, GKE Anywhere和Anthos上，运行那个计算引擎。这是一种很酷的方式，再说一次，这并不难，坦白地说，这比我自己做要容易。如果我只使用我的源代码，通过Cloud Native Buildpacks运行它，获得一个容器映像，那么我就不必处理容器化、基本映像、Docker文件的排序。这些我都不想要，但我确实想要一个容器，这样我就可以把它部署到任何地方。这是尽早建立信任的好方法，因为你正在使用一个可信的工具链和一个可信的操作系统堆栈，来自像谷歌这样的公司。

你还是要用这个。如果你在使用像Google App Engine, Google Cloud Functions这样的东西，我们在下面使用build pack来生成那个实际被部署的图像。它已经在那里了，这很酷。如果你在使用Cloud Build，你会得到这个。即使您使用的是JFrog套件，您也可以使用这个工具链来生成容器映像，然后将其放到Artifactory中，无论您想怎么做都可以。但是看看Cloud Native Buildpacks，真的很便宜，免费，易于使用。

好了，我们有了一些代码。我们已经完成了一些构建。我们已经开始生成一些证明，我一会儿会讲到，我们在默认情况下会在Cloud Build中这么做，它会添加证明你可以证明那是构建容器映像的东西。你开始达到我们所说的SLSA 1级。SLSA除了是你薯片里的美味调味品，还有什么?我们来谈谈SLSA。这代表软件工件的供应链级别，或SLSA。这些都是我们在谷歌学到的，如何确保软件供应链安全的实践?这是一个很好的框架。实际上，它现在在一些行政命令的后续事情中被提及，这很好。 I’d love to see this become a standard. It’s based on some best practices. And this is great for you to start to frame this out. Like, what do we need to do to have a secure software supply chain? Again, it’s not Infosects responsibility, it’s not some production ops team, all of us. All of us can take on some ownership here.

看第一层，SLSA的基本保护。这里，如果你看表格，脚本构建，我有一些出处，所以我可以证明是什么构建了这个东西。好吧，还不错，这让我明白了。第二，中等保护。听起来不错。这给了我一些进一步的检查。我是否在使用构建服务?我可以有一个服务生成的来源，没有手动的吗?我有什么很棒的版本控制故事吗?听起来不错。 Then I get to advance protection stage three. Now I’m adding some new things, different retention of source control with a verified history, I’m getting some additional isolation in my build. Again, if I want to avoid a compromised build server, where someone can just smuggle in some bad malicious code, because that build server never seems to get restarted, everything is very stateful, not if I’m using an ephemeral containerized environment where every build happens in a container and that gets blown away. Right now there’s nothing left behind for the next build. It’s always fresh. It’s always new. So are we starting to do more of those things?

然后进入第四阶段，最大保护。在这里你有一整套你可以做的事情。也许一切都不值得这样，也许一切都不需要这样。我不知道。也许我们会想出第五级的极端保护，但现在第四级是最远的。你可以通过很多活动来判断，这是开发团队吗?我们来处理一些。我们的产品运营团队，安全团队，平台团队。太棒了。这为您提供了一种通用语言，用于真正思考如何确保供应链的安全。 I think that’s pretty cool.

如果你看看Cloud Build，我提到Cloud Build是一个很棒的工具链。这是我们的无服务器构建服务，只在谷歌云上运行。它下面没有基础设施需要处理。一切都是短暂的，一切都在容器中构建，你按分钟付费。我们继续在这里做一些很酷的更新。现在有私人泳池，给你更多的隔离。它实际上是在一个沙盒中运行的，远离其他人，所以你今天可以打开它，这很酷。正如我所提到的，我们在证明方面做了更多的工作。因此，故障云构建的所有内容都会立即获得一个附加到Artifact Registry的认证。然后你就有了额外的元数据。

在整个过程中，您可能还会使用JFrog和Artifactory来存储您的图像。棒极了。太棒了。但关键是，你是否完成了这些步骤?您是否在考虑构建服务建立信任?然后你在整个过程中验证信任。

现在，在这里，你也要做一些漏洞扫描。这就是Xray很棒的地方，Artifact Registry也做了一些事情，但显然Xray在这里做了一些很棒的工作，确保我能够做一些扫描，检查代码，因为那时，我在我的存储库中，我的工件存储库中，但现在我还没有完成，我想要发布它。整个价值是让这个东西投入生产。那么在这种情况下，我现在如何获取这个工件并确保我在生产的过程中验证了它?这里有一些很酷的东西叫做二进制授权。

二进制授权实际上是我们内部的东西，我们在谷歌使用，它变成了我们现在向每个人提供的服务。但这实际上是一种检查这些证明的方法，并说，这个容器是否被允许到达这个生产服务?这对用户来说是一种非常简单的体验。在幕后，这是一个非常强大的东西。我们来讨论一下。

使用二进制授权的关键原因是确保您信任的东西进入生产环境。简而言之，就是这样。它实际上是在部署之前执行一些政策，无论是GKE, Cloud Run, Anthos环境，还是Offprem。它会做一些签名验证，它还会查看允许列表，嘿，这是从哪里来的。也许我们不允许从Docker Hub获取图像。也许我们不允许没有通过这个构建服务的映像。棒极了。你增加了政策，现在什么都不允许装运了。在产品投入生产之前，我做了一个非常好的验证步骤。所以我要确认一下，它是由我信任的管道建造的吗? Does it pass those sort of checks? Did it go through vulnerability scanning? So you’re able to add a really good check here, right at the end here, and making sure that before it gets to pro you’re doing another key verification step

我们一直在改进这项服务。所以，真正重要的不是核实信任，而是维持信任。检查它是一回事，但如果我把它变成prod，然后拉入依赖更新，或者一些奇怪的东西。不。有了这个，我们不断地核实，确保那个容器和产品是应该在那里的。所以，即使你把它放在那里，也没有办法把它塞进去，或者在那里塞进另一个零钱。我们将确保我们不断检查，保证你的安全，确保那个东西仍然符合你之前定义的政策。非常强大的东西。确保即使在那个部署环境中，您也在执行遵从性。

同样，正如我提到的，我们在Google Cloud上有一个很棒的工件注册表。这是一项全球可用的极好的服务。我们还添加了漏洞扫描，以及一些模糊测试支持。如果你是一个Go开发者。同样，对于组合的故事，Artifactory非常棒，您应该尽可能地使用它。这是可怕的。所以选择一个好的注册表。这对我来说并不重要，可以说，只要使用最有意义的方法，但要把它放入你的管道中。确保你有一个很好的故事，你在做漏洞扫描，比如x射线。你做的事情都是有证明的。

因为这里重要的是，一旦进入运行时环境，它是什么样子的?从身份管理的角度来看，我做得怎么样?我在基础设施的报道中做了什么?这不仅仅是部署管道。一旦我到了那里，它周围是什么?我是否处在一个非常脆弱的地方，我可以很容易地黑进去?从操作系统层面的安全角度来看，是否存在其他注入漏洞的方式?

当我们想得更多的时候，我的平台是什么?你可能已经在这里花时间了，但是，这个供应链的一部分是，哪些服务正在做诸如存储我的秘密之类的事情?所以，当我在制作过程中，或者在制作过程中，我是如何让人们难以访问那些不应该访问的内容?你是如何储存秘密的?如果我回到10年前，让我们称之为15年前，当我构建。net应用程序时，我只是加密值并将它们粘贴到web配置文件中。这在当时是可以的。但现在我不应该在我的配置文件中保留秘密。当然，我不应该在代码里写这些东西。我可以使用秘密管理员。也许是HashiCorp Vault，好吧。 That’s terrific. Maybe it’s something else native in one of the other clouds. Go for it.

如果你使用的是Google Cloud, Secret Manager非常酷。这是一项全球性的服务。如果我愿意，我可以做区域数据存储，所有东西都会自动复制。我有一个全局命名空间。默认情况下，所有内容都有版本控制，遵循一些最小权限原则，并与我们的云审计日志集成。它可以与GitHub的动作一起工作。如果您是Spring Boot开发人员，它会自动将这些秘密导入。如果你是地球人，我可以在里面管理我所有的秘密。如果我在开发应用，它会集成所有sdk，不管是。net, Go, Java, Python, PHP, Ruby。我们所有的sdk都与秘密管理器一起工作，将秘密拉入您的代码中。 So really, really nice way, if I want to secure software supply chain, I’m also being ruthless about what’s actually in the code, and I’m doing some late binding of things like secrets, and Secret Manager’s pretty cool.

同样，当你想到安全的软件供应链时，无服务器是一个非常酷的故事，那么安全到底是什么样子的呢?为什么呢?把这个功能看作是一个服务平台，就像云功能一样。我甚至没看到操作系统。我不负责修补，保护，加固它。这些都是平台提供的。我绝不可能在那里不小心做错事情。我只是给你密码。现在，正如我们之前讨论过的，我仍然可以写一个10行的函数，比如说，导入5个包来完成它的工作。这可能突然变成了一个1万行代码的函数，因为我引入了依赖性。 So, I still can’t fix that automatically. You still have to have all that diligence to check your packages, look at their history, look at their vulnerabilities. But I have shrunk the attack surface with Serverless. I don’t have as much infrastructure. I have as much network stuff I’m messing with. There’s fewer places where I could have bad vulnerabilities. So, Serverless is a really good security story because I’m shrinking how many things I have to be responsible for as a developer and more of that’s going into a managed platform.

Cloud Run是一个很棒的服务。这是一个零容器环境。但它不仅仅是您认为的传统Serverless，因为我可以运行16g容器映像。我可以做持久存储之类的事情。我可以对单个服务执行80个并发请求，然后在几秒钟内扩展到1000个实例。所以它非常健壮。我可以在这里运行很多东西，甚至设置最小实例。所以我甚至不需要缩放到0。对于某些工作负载，我可能会扩展到一个。因此，这两种环境都非常强大，适合越来越多的应用程序类型，而且它们在您的供应链中具有良好的安全性。 And what’s new from a security perspective here is, if you’re a cloud run developer, I can have customer managed encryption keys. Bring your own encryption key, encrypt your things at rest. I can’t see it as Google. Nobody else can. It’s your stuff. It’s awesome.

同样，作为Secret Manager的本地集成，我喜欢这种集成，因为如果我是开发人员，我可以说，我确实想使用secrets，我有两个选择。我可以将它们注入到环境变量中或者我可以将其作为卷挂载到容器映像中，然后在我的代码中访问它，这非常好。我有一些不同的方法，在运行时，后期绑定，把东西拉到我的应用程序中，让它更安全。

最后，Cloud Run GA最近提供了二进制授权支持。你喜欢那张支票吗?你喜欢那个证明检查，上面写着，不能从这里部署到云跑。太棒了。现在超级好用。再说一次，你不需要做太多的工作。这些是复选框功能，实际上在封面下做了很多。所以你已经准备好了《云跑》。

同样，云功能。云功能，再一次，很酷的低估了作为服务平台的功能。我们还添加了与Cloud Secret Manager的集成这样你就可以把秘密拉入你的函数，因为函数经常扮演粘合的角色，也许那个函数会响应一些东西，调用Twilio，调用地图API，你可能会存储一些API密钥。酷。把它们插入秘密管理器。这样做要安全。所以，如果我在构建现代软件，有很多很好的方法，我试图快速完成它，我正在发布，速度是很棒的。我能在不牺牲安全性的前提下，做一些很酷的本地操作吗?

我在这里要说的最后一个大服务是GKE。GKE可能是在公共云中运行Kubernetes的最佳方式。它是任何云提供商提供的最可配置、最安全、功能最丰富的Kubernetes。非常棒。我们真的很努力地让它变得很棒。我们在2021年早些时候所做的是领导力自动驾驶。如果你还没有遇到过这个，它很酷。它是GKE, GKE就是Kubernetes，操作上很神奇。但我们从安全的角度，把所有正确的默认选项，所有这些扩展，所有这些有趣的东西，都换成了GKE。然后我们承担了责任。 So you, as a user say, I’d like a GKE autopilot cluster. We spin up a control plane and, behind the scenes, we stand up whatever nodes are needed, you just pay per pod. We scale it. We get paged if something goes wrong, our SREs. We auto scale it, we provision it, we update, we maintain it, which is awesome. So, you get the Kubernetes API surface and none of the work.

现在，为什么这是一个伟大的软件供应链故事?你可以想象，我们打开了所有正确的安全功能。然后我们会以谷歌的规模为你们运行和操作。我们正在再次缩小你的攻击面给你一个超级坚固，受保护的环境。所以Autopilot是安全软件供应链的完美组成部分。其他任何供应商都没有这样的服务。我们真的很努力让它变得很棒。所以，看看这个。你如何从运行时一直延伸到桌面，通过你的构建工具，通过你的漏洞扫描，现在有一套惊人的技术，它们很好地集成在一起，给你一个安全的软件供应链。

当我们看到JFrog和谷歌云是如何合作的，首先呼吁行动，去云市场看看这个。安装Artifactory，将这些其他JFrog体验安装到您的Google Cloud帐户中，并拥有一个强大的硬化工件注册表，可以与我们在Google Cloud中的其他服务一起工作。去吧。Xray也是一样，我在做漏洞工作，因为我要确保我的包是安全的。您可以将其部署到Google Cloud托管模型。你可以做一个自己动手的模型，但也要自己动手。这是可怕的。然后试试这些谷歌云功能。使用Buildpacks生成容器映像。看看你怎么想。 Try deploying the Cloud Run. We give you a couple of million free requests every month to try out with no cost. Try GKE Autopilot and see that maybe you can build a secure software supply chain without actually compromising velocity. Instead, I can actually go fast and stay safe.

我希望这些东西能让你们感到兴奋当你们思考做这类工作的正确方法时。安全的软件供应链从未如此重要。你在这上面花时间对你的职业生涯来说是很好的，因为这将是一个非常受欢迎的技能组合。看看像SLSA这样的框架，将其应用到您的一些工作中，并帮助使软件成为您公司的竞争优势，而不是风险。

好吧。我珍惜时间。你可以在推特上@ rserter找到我，在那里对我大喊大叫。告诉我你的想法。希望你喜欢会议的其余部分，希望很快能见到你。