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

老实说，这些年来我学到了很多，甚至在我加入谷歌的一年半里，关于一个好的安全软件供应链应该是什么样的?对于像我、你和其他人这样的开发人员来说，哪里不是可怕的地方?我们怎样才能做到不那么困难的安全?也许我们能让你更容易做正确的事。我们今天要讲的是，为什么我们需要一个安全的软件供应链。什么是安全的软件供应链?谷歌和JFROG作为生产路径的一部分正在做什么，以使其安全快速同时安全?

请继续关注。开始吧。

好吧。我说过了，我叫理查德·瑟罗特。我是谷歌Cloud的出站产品管理总监。我讲的内容包括容器、服务器列表、开发工具，其中一部分甚至包括我们的安全软件供应链工作。我很高兴今天能在这里和你们一起，告诉你们谷歌和JFrog如何一起工作，帮助大家更容易地做一些好事。

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

这里的棘手之处，也是我们今天要花很多时间的地方，是整个软件供应链中一个不安全的环节就会造成混乱。就像我们所想的那样，软件不仅仅是我写代码然后投入生产，你我都知道这一点。对你们中的一些人来说，刺激它可能是一套英雄主义，而另一些人，可能每小时都能做到。但是你仍然会意识到有一组步骤，经过构建步骤，经过打包步骤，经过其他步骤，以确保我可以实际发布代码。任何一个地方，如果出了问题，我就有麻烦了。我想稍微点一下。我想看看攻击载体在哪里?当你和我试图将我们的代码投入生产时，哪里会出现问题?哪里会出问题呢?让我们看看这些斑点。

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

然后，实际的源代码系统在这里受到了一些损害。这里，攻击者，在过去我们最近看到过，侵入了一些Git服务器用于不同的包管理和类似的东西，它增加了提交。好吧。突然间，我认为我是安全的，但实际上，我签入源代码的地方现在是在后台向我的代码中添加东西。那不好。

还有其他地方，甚至构建管道都可能被改变。对吧?它可能是构建管道由外向内的变化。同样，我没有真正看到它，我只是签入我的代码，其他事情发生了，现在我有一些不好的事情发生了。听着，我也可以让构建系统本身受到威胁。你知道，在这种情况下，这可以是一些地方，太阳风就是一个很好的例子，那里有一个坏演员，他得到了一些坏的行为和一些恶意代码，被添加到每一个构建，然后被发送到每个人。这似乎是最糟糕的情况，有人有一个静态的构建环境，然后能够妥协。没有什么能真正消除或检测到那种疼痛。这是个大问题。

依赖关系，我们一会再详细讲，这个被低估了。看，如果你和我今天要用现代语言构建任何东西，那就是大量的依赖。对吧?如果我是一个。net开发人员，我全部在NuGet，我使用NPM作为JavaScript开发人员，我使用Maven为Java。我在做各种不同的事情。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.

我们如何利用这个框架来讨论剩下的问题呢?让我们考虑第一部分，建立信任。这些东西是从哪里来的?我的包裹是什么?那里发生了什么?所以我们做了一些很酷的东西。开源洞见。第三，现在就去deps。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.

你可以进去说，嘿，我要添加这个包，让我了解一下。我们要把这个翻转过来。而不是，我们会引入任何东西，只要能赢得在你的代码中出现的权利。你应该抱有很高的期望。什么东西有权在我的应用程序代码中?我是要随机抽取这个库吗?让我先去看看，看行不行。我来看看它还依赖于什么。这是一个很酷的工具，可以增加能见度。我们将继续在谷歌上做更多的工作，使它更容易在您的系统中使用。 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上，或者测试它，做任何事情。然后我们开始思考如何将其添加到信任链中?云构建，我们马上会讲到，它做了一些很酷的事情。您也可以在工具中使用Artifactory。您可能正在使用JFrog管道。你可以用x光。我们会讨论所有这些事情。 But this is where you start to establish trust.

我认为有一件事很重要，但可能被低估了，尤其是现在在这个容器的世界里，我的容器来源在哪里?基像从哪里来?就像我之前提到的，我的Docker文件很糟糕，这对我来说不是一个好主意。你从哪里提取基本图像?是从供应商那里买的吗?它来自Docker Hub吗?是什么原因吗?你就别担心了好吗?

如果你听说过云原生构建包。这是CNCF的一个项目。从历史上看，构建包来自Heroku和Cloud Foundry，这是我曾经参与过的一些地方。所以，简而言之，它所做的就是获取源代码，为编程语言和框架确定正确的堆栈，然后建立堆栈，包括一个安全的基本映像。因此，从它出来的是一个容器映像它基于一个加固的操作系统，和正确的锁定堆栈，它是由buildpack提供的。

所以谷歌云构建包使用我们的瘦身操作系统。他们使用了正确的加固配置，在一个小的容器映像中构建了一个漂亮的紧密堆栈，如果我愿意，我可以通过一个命令从云构建中启动它。我可以在桌面上做这个，gcloud构建提交，然后得到一个可以在任何地方运行的容器映像。我可以将该映像部署到Cloud Run, GKE, GKE Anywhere with Anthos，运行该计算引擎。这是一种很酷的说法，再说一次，这并不难，坦率地说，这比我自己做要简单。如果我只拿我的源代码，在云原生构建包中运行它，得到一个容器映像，我从来不用处理容器化，基本映像，Docker文件的排序。我不想要这些，但我确实想要一个容器，这样我就可以在任何地方部署它。所以尽早建立信任是很好的方式，因为你使用的是来自谷歌这样的公司的可信工具链和可信操作系统堆栈。

不管怎样你都在用这个。如果你使用谷歌App Engine谷歌Cloud Functions，我们会在下面使用构建包来生成实际部署的映像。所以它已经在那里了，这很酷。再说一次，如果你在使用云构建，你就有了。即使您使用的是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?

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

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

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

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

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

使用二进制授权的关键原因是确保只有您信任的内容才能进入生产环境。简单地说，就是这样。实际上，在部署之前，它会执行一些策略执行，无论是部署到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

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

同样地，正如我提到的，我们在谷歌Cloud上有一个很棒的Artifact Registry。这是一项全球可用的极好的服务。我们还添加了漏洞扫描，以及一些模糊支持。如果你是围棋开发者。同样，对于合并的故事，Artifactory非常棒，您应该在任何可能的地方使用它。这是可怕的。所以选择一个好的注册表。可以说，这对我来说并不重要，只要使用最有意义的东西，把它放入你的管道中。确保你有一个很好的故事，你正在用x射线之类的东西进行漏洞扫描。您正在使用认证进行操作。

因为这里重要的是，一旦我进入那个运行时环境，它是什么样子的?从身份管理的角度来看，我做得如何?我在基础设施的故事中做了什么?这不仅仅是部署管道。一旦我到了那里，它周围有什么?我是否处于一个很容易被黑进去的脆弱地带?从操作系统级别的安全角度来看，我是否存在其他注入漏洞的方法?

当我们进一步思考这个问题时，我的平台是什么?你可能已经在这里花了一些时间，但是，供应链的一部分是，哪些服务在做诸如存储我的秘密之类的事情?所以，当我在制作过程中，或者当我在制作过程中，我是如何让人们很难访问那些不应该访问的东西的?你是怎么储存秘密的?如果我回到10年，让我们称之为15年，当我构建。net应用程序时，我只是加密值并将它们粘贴到web配置文件中。这在当时是可以接受的。但是现在我不应该在我的配置文件中隐藏秘密。当然，我不应该在代码中使用这些东西。我可以使用秘密管理器。也许是哈希公司保险库，好吧。 That’s terrific. Maybe it’s something else native in one of the other clouds. Go for it.

如果你在谷歌云，秘密管理非常酷。这是一项全球性服务。我可以进行区域数据存储，所有数据都会自动复制。我有一个全局名称空间。所有东西都是默认版本化的，遵循一些最小权限原则，与我们的云审计日志集成。它可以和GitHub的动作一起工作。如果您是Spring Boot开发人员，它会自动将这些秘密导入。如果你是terrraform，我可以把我的秘密都藏在里面。如果我在开发我的应用，它集成了所有的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是一项巨大的服务。这是一个从零到零的容器环境。但它不仅仅是传统的无服务器，因为我可以运行16g容器映像。我可以做持久存储之类的事情。我可以对单个服务执行80个并发请求，然后在几秒钟内扩展到1000个实例。所以它非常健壮。我可以在这里运行很多事情，甚至设置最小实例。所以我甚至不需要缩放到0。对于特定的工作负载，我可能会将其扩展到1。因此，对于越来越多的应用程序类型来说，这两者都是非常强大的环境，并且它们在您的供应链中具有良好的安全故事。 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的原生集成，我喜欢这种集成，因为如果我是一名开发人员，我可以说，我确实想使用秘密，我有两个选择。我可以把它们注入到环境变量中或者我可以把它作为一个卷挂载到容器映像中，然后在我的代码中访问它，这很好。我有几种不同的方法，在运行时，一个后期绑定，把东西拉到我的应用中，让它更安全。

最后，Cloud Run最近获得了二进制授权支持。你喜欢那张支票吗?你喜欢那个认证检查，上面写着，不能从这里部署到Cloud Run。太棒了。现在超级容易使用。同样，你不需要做太多的工作。这些是复选框特性，实际上在封面下做了大量工作。所以你已经很好地使用Cloud Run了。

同样，云功能。云功能，同样是一个很酷的被低估的服务平台功能。我们还添加了与云秘密管理器的集成，这样你就可以把秘密拉到你的函数中，因为函数经常扮演一个粘合的角色，也许那个函数响应一些东西，调用Twilio，调用maps 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和谷歌Cloud是如何一起工作的，第一个行动呼吁，去云市场看看这个。得到Artifactory安装，得到这些其他JFrog经验安装到您的谷歌云帐户，并有一个伟大的硬化的工件注册表，与我们的其他服务在谷歌云。去吧。和x射线一样，我在做漏洞工作，因为我实际上是在确保我的包是安全的。您可以将其部署到谷歌云托管模型。你可以做一个自己动手的模型，但也要坚持下去。这是可怕的。然后试试这些谷歌云功能。使用构建包生成容器映像。看看你怎么想。 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这样的框架，将其应用到您的一些工作中，并帮助使软件成为您公司的竞争优势，而不是风险。

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