How to build secure software supply chains

Introduction

Hey everyone, this is Stephanie Wong, Cloud Developer Advocate. We are back with our own Google Fellow Eric Brewer. Last time, we talked about his last ten years of building infrastructure at Google and Kubernetes' influence in the space. Eric mentioned how he is now focusing on creating processes for more secure software supply chains. So, Eric, how are you doing today?

Fantastic, it's good to see you again.

Good to see you too. Alright, so let's dive right into it. Last time we were talking about supply chains for software. You were speaking a bit about the risk space and companies tied to it. So how is the supply chain risk assessment happening today? Why is the risk so large?

Well, there's a lot we need to do here as an industry, and it's beyond the power of just Google. In fact, it's really quite a challenge for the whole planet. But, I would say the first thing we need to decide is which projects we want to bet on. Because in some sense, any project you're betting on for security, you'd like to make sure that there are people that care about that project and are paying attention to it and will fix security vulnerabilities as they arise.

In practice, 99% of our vulnerabilities—literally 99%—are not in the code you write for your application. They are in this very deep tree of dependencies, some of which you may know about and some which you may not know about. So, the first thing is identifying those dependencies. Which ones are well-maintained and which ones are not? We're starting to present that kind of information.

However, taking it up a level, it's going to be important for all industries to try to understand which pieces of software we want to bet on and why, and what to do about the ones that aren't quite up to par yet.

Yeah, and whether some companies know it or have come to accept it, Kubernetes has become the de facto way to build and deploy many applications today, or at least that's the North Star for many organizations. Now it has several hundred software library dependencies, right? What are we at Google Cloud doing to help reduce those vulnerabilities?

Well, there's tons of courses through CNCF, which we started as a home for Kubernetes. It's part of the Linux Foundation, which we also are heavily involved in and support financially. I personally helped create the Open Source Security Foundation (OpenSSF), which in my mind started in 2019, although I think it actually launched early 2020. That foundation is explicitly targeted at open-source security and the supply chain. It was created for that purpose, and fortunately, it was created before the issues really became so visibly bad. I could see it coming, and that's why we needed to start early.

The other thing worth mentioning is that Google has a long history of contributing to open-source. In our recent response to the White House, we've committed another $ 100 million to open-source in the coming years. It's important to set that precedent because the repairs we need involve a lot of mundane work to make open-source as secure as it needs to be. It's not fair to just tell volunteers and others to work harder—that’s not a sustainable path. In fact, I'm advocating for federal funding as well to support open-source security. I think we need to get to a sustainable model where the ongoing work of security, which is not easy, is financially supported, not just this year when it's a crisis, but for the foreseeable future.

We should think of it like other public infrastructure. We passed a trillion dollars to spend on roads and other things in the U.S.; open-source is a public infrastructure too. Like all public infrastructures, it needs maintenance and support. We need to figure out how that's going to work—it’s not an easy task, but data is part of the path to the future.

Yep, and it's really hard to predict. So I think having secure processes in place from build to deploy is key, especially as we've seen the detrimental work of adversaries coming to light.

Can you talk a little bit about our contributions and the work we've done in the open-source space? What are some of the organizations and projects we've worked on?

I'm a big fan of raising the level of abstraction over time. That gives developers more leverage and allows us to do more automatically on both the security and management sides. Autopilot is a great example of that. With Autopilot, we manage the nodes for you in your cluster, so you don’t have to. This improves security but also reduces toil. Why manage nodes yourself if you don’t need to? That’s probably not why you’re doing your Kubernetes job. You likely have something more important, like a business app, a website, or data analysis. Focus on those things, and we can manage the nodes.

That direction—managing more things over time, especially the ones that are a hassle—is the way to go.

Exactly, and I do want to dive a little bit more into Google Kubernetes Engine (GKE) and what we've been doing over the last couple of years. We just celebrated GKE's sixth birthday. Why don't we save that for the next episode?

Thank you so much once again, Eric. And to everyone else watching, stick around because we will have more soon.