 All right, good morning everyone. So happy to be here. Let's talk about software supply chains for DevOps. I'm Isla Greenberg. I'm Senior Software Engineer at Google. I'm the Tech Lead of GCP's Container Analysis and Container Scanning Team. I co-maintain Graphics and Critics open source projects. And I hosted the first software supply chain track at QCon in San Francisco in 2019. So I've been in this space for a couple, for a few years. And I'm excited to be here. I would like my in the crowd. And I can be found on Twitter. So what makes challenges in software supply chains particularly unique? The concept of software supply chains isn't really new. We've had the term software development lifecycle for a while now. And the way I see it software supply chains is basically that, but in the cloud ecosystem. So what makes it especially challenging these days is that not only are we running our production work loads in clouds, which is just a fancy word for someone else's computer. But also we're now using the third party vendor dependencies, open source dependencies. So it's just increasingly more complex to vet every single thing that is going into building application, running it, the platform that's running on, and all the tooling that is involved along the way. Here's the diagram from the Salsa website. And you already saw that in the premiere of Operation Salsa. So what it shows here is the software supply chain from source and then it gets built with the dependencies pulled in. And then it gets packaged and shipped to the customer, whether it's a container image, binary, and so on. And as you can see here, every step of the way, there are multiple attack factors that make it very problematic for us to ensure that what we're running is what we intend to be running and it has everything we need and nothing else in it. So let's talk about DevOps in Cloud. We'll be talking a lot about the security aspects of it. So I wanted to cover the other side of it, the operational side of things. Same software supply chain as we saw earlier, just the one that we'll be using for the rest of the talk. So we have our engineer who writes source code. It gets built, tested, and then some static analysis tools run and then deploy checks, make sure that the right thing is deployed to production. And now our code is running a production. So now, imagine we get woken up at 3 a.m. by an incident, so our pager goes off. What do we do? The first thing we do is go look at our graphs, tracing some of the logs to try to figure out what's going on. And now that we need to do root cause analysis and impact estimation, everything across the software supply chain is now under suspicion. And so we will look at every single stage in what happened and what changed and what might be triggering this page. And so in order to be able to query for this efficiently, we need to universal artifact metadata so that we can look at everything that happened while the software was being built and then deployed to production. And then also we can look back at it so that when we roll back our software, we can make sure that we can still look at what happened in retrospect. So now let's talk about some of the existing solutions on Google Cloud. So for the first, for the source, we have our code source, cloud source repositories. And so it allows you to design, develop, and securely manage your code. Here's an example of what it looks like. You can deploy a specific version of your code from cloud source repositories using the cloud functions. And then this way it makes sure that you know which version you're deploying when you roll back to the version that was running okay last week. You'll also have a way to track that along the way. It also integrates with cloud audit logs so I can look at my error logs and then try to see what piece of code it's coming from, what line of code it's coming from, and then see if this is new code or a new traffic shape that is triggering this page. So what it allows me to answer is what new code could have caused this incident? So moving down the software supply chain, we have build test and cloud build allows you to build, test, and deploy on the serverless cloud CICD platform. So what it allows me to answer is how is this binary affected by the incident build tested and deployed? Did I miss any checks? Did I have the right build configuration and so on? Now going down further, we have our scan analysis stage and that's where my team comes in. So on-demand scanning, container scanning are the two products that my team owns. On-demand scanning allows you to scan container images locally on your computer or in a registry. What this looks like is we have a gcloud command which is basically a CLI that allows you to scan in Ubuntu image, for example, Ubuntu latest which is local on my computer, and then it will extract packages and make sure that all the analysis are run and then display the results as you see here. Container scanning is similar to on-demand scanning in that it scans images in artifact registry and GCR, but also it allows you to monitor vulnerability information to keep it up to date. So if a new CV comes out or there's an update, there's a fix available, severity has been revised, container scanning will give you those up to date results after you push the image so you don't have to repush it. So here's an example of what the vulnerability results look like here. You don't have to be able to read everything, walk you through the key parts. So when I'm walking up at 3 a.m. and I'm trying to figure out if this is okay with the rollback and I can go back to sleep or I should keep investigating, I see there's 74 vulnerabilities and there's zero critical severity so that's good. Next one, I'll probably dig into high severity vulnerabilities. I see that there are some fixes on this so maybe I'll check to see if this could have prevented my incident and then maybe during business hours if I really need to, I'm gonna dig into more of these vulnerabilities at medium and low severity. So the question I can answer with these products are what vulnerabilities am I exposed to that contributed to this incident? Going down to deployment parts. So we have binary authorization which is deployed time security control. It ensures that only trusted images are deployed on GKE and Cloud Run. So here's an example of what the binary authorization policy looks like. We'll set up rules, we can allow list images so if we trust the provider of the image I'm gonna say I know they'll do a good job of making sure that the images I use from them are clean and can be trusted. Then I can list them there and then I can create the policy. On the example here there are two types of policies so there is allow all images on the left hand side and then just allow all images on the right hand side and there's another kind you can configure where you specify only the images that have been attested can be deployed. So now on the left hand side the image is deployed successfully and on the right hand side the pod is blocked from deploying and then we get an error message. So the question I can answer with this tool is what policies do I have to prevent bad code from deploying? For example, I wanna make sure that nothing I deploy has critical vulnerabilities in it. And now tying all these stages together is the container analysis API and other infrastructure piece and products that my team owns. So it allows you to store metadata for resource and retrieve it to audit your software supply chain. Here is an example from the public documents. You see here another basically view of the same software supply chain with the more familiar one saying that source build, test, deployment checks they can all be represented compliance checks they can all be represented within container analysis API and retrieve. So the question helps me answer is tell me everything about this artifact software development lifecycle. So tying it together we looked at cloud source repositories, cloud build on-demand scanning, container scanning, binary authorization and container analysis API some of the existing solutions today that you can use to monitor and use this tooling for operating your production work closing cloud on GCP. Thank you very much.