 Thanks for having me. My name is Fabio Rapacelli. I'm a senior staff engineer with VMware. And you can find me on Twitter, which is probably the only social media I still use. So, at Fabio Rapacelli. Today I want to talk about sort of like the worst nightmare of all the public relations departments out there, which is your company making, you know, national news because of a security breach. Before we get started, though, I just want to knowledge something. Like, it's great to be back in Europe. It's great to be back in person. I'm sure many of you can relate with the meme up there on the screen. And I can't wait to see old friends and making new ones here in Valencia this week. So if you see me around, stop me. We can chat. It's great to see everybody back. Let's get down to business now. So do you remember this headline from a couple of years back? If you don't remember this one, you might remember this one. Or maybe this one. Or maybe this one. So the sort of wins hack pretty much sparked so like this intense debate on and exposed the importance of the software supply chain. In a way that I've rarely seen in my life, honestly. And you know, I've been in this industry for like 20 plus years and this is the first time I see such an uproar in terms of like, you know, legislation and so like discourse around this specific problem. It was not the first time that there was a, you know, something similar to that happen actually, but the target the scale and so like the blast radius that this attack had was unprecedented. Now it was a humbling moment for, you know, for many involved in the software development lifecycle business, myself included. Now look at this figures here. They're taken from the synopsis open source security and risk analysis report made in 2022. This is made from by the same company that makes the BlackDoc scanner you're probably familiar with. You know, there's a number of interesting findings there and there's a link, you know, when you get to see the slide, there's a link to the report there. But the two metrics that sort of caught my attention were these two. You know, look at them. That means that three fourth of all the code bases that were audited, which means that, you know, code bases from all sort of companies you know, not just from, you know, software development companies, but this is like from all industries and all geographies, three fourth of their code base is open source software. This means that three fourth of their code base is software, you know, pulled in from GitHub, pulled in from all sort of sources. And 81% of that code is at least vulnerable with one vulnerability. Now, if you stop for a second and think about your own stack, think about how deep is your stack like all the dependencies you're relying on, you know, if you look at the blast radius, it can sort of like impact your company if one of these dependencies get attacked in some way. And we had recently that example. I mean, think about what happened when we lucked for J. You know, that can make or break companies sometimes. And there are so many attack vectors too in the supply, in the modern development lifecycle and the modern software supply chain. You know, you could have post submitting malicious code changes to the repo if you didn't have like strong review mechanism, you can have your build platform compromised from the inside or by an attacker externally, which by the way is what happened to SolarWinds in the example before. You can even have malicious package maintainers. You're depending on some random package from the internet. And this package maintainer maybe out of spite or out of protest sometimes. And we've seen that with the war in Ukraine recently, they can either wipe out their dependency from the face of the earth and it's not going to be available anymore or can embed, you know, backdoors even in the code. And if you don't do anything about it, then you end up with backdoors in your code, in your shipping code. Now, it's obviously easy for me to point out the problem. The reality is that as engineers, we tend to value so like, you know, velocity and making progress way more than we value compliance in general. I mean, I'm guilty of that myself. So we deal with compliance only when we have to, which is usually when you have somebody knocking on your door, which is usually the security team or the legal team, if things get worse. Back in 2017 I was the architect for a product at VMware and I was dealing with license compliance. We have a large code base in Go and we had a number of packages there. And Go is, as many of you know, at least back then, you could only get statically compiled binaries. So it means that you have to, like, scrutiny your licenses because some licenses are incompatible with each other. And we're trying to make our CI-CD tool smarter to, like, you know, catch license creep early on. So I built the tool and I went to a conference in Paris called .Go to present it. It's still available on YouTube if you check it out. And at the time I was saying, you know, there's actually more than 2,000 packages. This slides it from 2017. There's more than 2,000 packages made with Go that are GPL2 license. That means that this is like a hat scratcher for a lot of legal teams, especially in product companies that are building product to sell. So I'm going to start tackling some of these fundamental issues in the software supply chain these days. Now it's hard to pinpoint a single solution, but there are ways to do this. And software building materials is probably not the, you know, it's not the newest concept, but it's you know, it caught a lot more sort of like attention in the past three or four years, mostly because of the attacks that I was talking about before. And it has sort of like started accelerating the adoption of you know, these concepts and these practices. And to me, the important shift here that has to happen is sort of like moving away from the, you know, what I was calling the compliance because you have to to sort of like the compliance because you want to, because you want to be compliance because it means creating a virtuous cycle where you know, a flywheel where you have, you know, there are tangible benefits in adopting something like this for everybody involved, not just for the legal team, you know, being able to sleep at night. So, but what goes inside of an S-bomb? So there's a number of competing standards for S-bomb. There's there's SPDX, which is backed by Linux Foundation. There's CyclingDX. There's a bunch of other standards out there. But they're not very opinionated in what goes inside an S-bomb. They're just opinionated in the type of, like in the way it is described, not in the way that you're putting information inside that. So right now, it's all like a common belief that you know, having vulnerability scan results, the license audit, the metadata on the build system that actually built the artifact, all the dependencies that are involved in sort of like building that specific piece of code, that specific piece of artifact. And so like the relationship that exists between the components that are actually built, you know, it's sort of like an acceptable, you know, list of information to generate, you know, a viable set of tangible benefits to the teams involved. And why? Why is that? Because you can identify, you know, vulnerabilities that are known. You can, you know, count and manage your license, which was, you know, my original use case for something like this. You can identify compliance, you know, obviously at the license and security level, because you have both information available to you. And you can start evaluating and quantified the risk of your software as a whole. And most importantly, it's also forward-looking because by having a list of all the things that you, and all the components that you have, all the dependencies that you have in your software, it means that when there's a new CVE coming out or a new, you know, security problem that to mitigate, you actually have a list of things you can go and check on and say, okay, I have, you know, out of the entire software state that I have, you know, I'm using this library that is vulnerable in all the software packets so I can go and fix them. And I know exactly where to go instead of trying to scramble and, you know, out of the code base when there's a day zero out there that is sort of like, you know, impacting you. Now, if we take a step back, you know, now we have Sbom in our toolbox. You know, let's take a step back and look at how that fits into, sort of, like the overall security of the system. Now, having an Sbom generator is great. It's fantastic. But there are several points where the supply chain can actually be attacked. Now, you know, securing all this is obviously hard. And it's, you know, probably there are teams, entire teams dedicated to fixing this problem, many companies, you know, VMware included. Now, though, how do we do that? It's actually pretty hard. So there are two, so like frameworks that are so like standing out these days. One of them is the salsa framework, which was, you know, initiated by Google and sort of like, you know, something that is, you know, something that is, there's a lot of buzz around it right now. And also there's like the OS protective control framework. They can help you integrate, you know, practices and automation into your supply chain, trying to leveraging the same platform and tools that, you know, your developers and your SRE teams are also using. So like creating a connection between the two and sort of like adding sec into your DevOps cycle, into your DevOps practices. Now work in this area is still pretty nascent. If you look at, especially if you look at salsa, salsa has four levels, level one and two are pretty well defined, three and four, not so much. So if you're a security expert, if you're a security practitioner and you're interested in this, I would suggest you to like go check out salsa, which is L S L S a dot that and, you know, take a look because it's it's interesting stuff. And in closing, I know I'm over time already, but I'm trying to wrap up early as much as possible. So how do you get started today? Now so Joe, Joe Beda is one of the Kubernetes co-founder and there's one line that he always uses when talking about Kubernetes that I really like, which is Kubernetes is a platform platform, which means it's a platform to build platforms. Now what you see up here, it's a set of tools that are available today to sort of like build your own secure supply chain platform right? I want to highlight some of these notable examples here, but there are many more out there. So this is not like a complete lease by any stretch of imagination. So if there's nothing here that fits what you need, go check out the CNCF landscape because there's likely a project that is, you know, is built for you. So let's quickly look over, you know, what we have here in total performs attestation. So it, which is basically authenticated metadata on your software artifacts. So while you're building your software, you create attestation and then you cryptographically sign them and you basically take them along your secure pipeline. You have, you know, cartographer, which is a choreographer, sort of like similar concept to orchestration for secure supply chain. This works in conjunction with, you know, a task executioner like, you know, tecton or even Jenkins. And then you have six store, which is, you know, toolkit for automatic signing and verification of artifacts. And if you looked at the recent, you know, release of Kubernetes 124, Kubernetes 124 is the first release that is signed and can be verified using six store. So go check it out. And as I mentioned earlier, there's salsa and OWASP as security framework. Again, go check them out. And last but not least, OPA, which is pretty famous. And I'm sure that if you're running a Kubernetes cluster in production, there's a pretty high chance you're already running OPA or open policy agent for enforcing policies out there, it's going to be extremely useful also for creating secure supply chain. I hope this was helpful and, you know, hopefully also informative in a way. Good luck in securing your pipelines and have a great time here in Valencia. Thank you.