 Thank you for having me and thank you for teeing me up so well, Jim, with all the scary talk about cybersecurity and open source. Like I said, I'm gonna be reflecting a little bit on the last year in open source security. Last year, I kind of started off big with the log four shell cybersecurity vulnerability and it continued throughout the entire year. But this problem's been going on for a while. So I'll start out by introducing myself a little bit how I got interested in this space and then teed up with some of the things going on here inside of the Linux Foundation and in the broader open source community about open source security and supply chain security in general. So like you just heard, I've been working on and worrying about the security of open source projects for most of the last decade. I started my career at Google right in the wake of the operation Aurora attack on some of Google's internal infrastructure. Got to help out a little bit and watch the company build some of the best cybersecurity controls I've ever seen in the wake of nation state attacks like that. And then I started working in open source a few years later and I saw a huge shift in security posture that kind of got me worried. All those controls and preventions and source code integrity and provenance and metadata and software inventory like software build materials were missing in this new cloud native container centric Kubernetes focused world. And that got me pretty worried. I started working on a bunch of projects in that space. I found myself as a maintainer of the mini cube project having to look up how to do releases securely and open source. And I was basically told to go buy a Mac mini expense that put it under my desk, install Jenkins and then ship this binary to users all over the world to do their Kubernetes development. And that worried me a lot. So I started looking for alternatives that could help address this problem. This wasn't a very hot topic until recent years. So that's what I'm gonna be talking about. The transition to that why people started caring about cybersecurity and what we're doing about it today. So the state of open source security is actually pretty good. This is something I want to address a little bit here too. A lot of folks worry about open source security because we talk about it so much. But time and time again, the data always shows that open source security is better than proprietary software security or closed source security or any of the other options out there. So getting rid of open source is not an option that we can do. I just want to take that off the table at the start. But we're gonna talk about that a little bit too in some of that data. This last year has been pretty bad in the headlines. It started with that log for shell incident. There have been vulnerabilities every couple of weeks. There was even a very serious one in open SSL a month or so ago that drew a lot of attention. But there has been a lot of progress. I think everybody's probably seen these slides that show scary up until the right diagrams showing vulnerabilities and attacks every single year. I'm not gonna do too much of that. I'm not gonna scare everyone with those slides anymore. There have been a lot of wins and a lot of progress. So I want to make sure we focus on that because a lot of the people here in this room are probably responsible for that. But that doesn't mean it's perfect and we don't need to continue working or continue investing. So I'll talk about some of the things that aren't working and some of the ways we can continue making progress from here. So this is a rough high-level overview of the landscape of open source security. There's plenty more going on, but I like to call out some of these projects because they show kind of the ends of the spectrum and the different types of attacks and things that we have to worry about in open source security. Like I said before, this marks the one week or the one year anniversary this week of Log4Shell, the initial disclosure of that security vulnerability, and that really did shake the software ecosystem. That wasn't the first major software vulnerability in open source and it arguably wasn't even the worst, but it did present kind of a critical storm. The industry had been worried about supply chain security for that whole year because of other attacks, including on proprietary software, like the one on SolarWinds that happened the year before that. At the same time, the Log4Shell vulnerability was incredibly severe. It was about a worst case scenario. It was a critical vulnerability that was very easy to trigger and exploit in one of the most widely used libraries and one of the most widely used programming languages in the world. In fact, Log4Shell, the Log4Shell vulnerability was actually found on the Mars Space Rover, so it wasn't even just on this world. It was actually throughout the entire solar system. But as a positive, this event did lead to kind of a watershed moment in securing the open source supply chain. It drew continued attention that we hadn't seen before. Other attacks in that decade, things like the Heartbleed vulnerability, which led to an initial focus on open source supply chains, didn't really bring the carrying power and attention that we needed to really address this problem. Thankfully, these led to government regulations, mandates both in the United States and Europe and also here in Asia, because we already had this focus on the problem for so long. I'm hopeful that at this point, we can continue to make positive outcomes come out of these vulnerabilities as we address them. Right here within the Linux Foundation, this has led to a huge increase in funding and investment inside of the OpenSSF or the Open Source Security Foundation. Jim did a great job raising a ridiculous amount of money last year to help address this problem. They could just announce over 100 members in the OpenSSF now last week as well. So everyone here is paying attention, everyone is ready to help, we just need to help. Some of the projects here going on in the Linux Foundation where folks can pay attention are the SigStore project, which is part of the OpenSSF, as well as the overall SBOM initiatives. I like to call these out because they address very different risks. SBOMs, which you're gonna hear a lot more about from Kate coming up after this, power the software inventory systems that we use today. These aren't new, they've been around since, I think the initial version of the SPDX specification started in 2010, really focused on software licensing, trying to make it easy and safe to consume software for compliance. It turns out that knowing what versions of packages that you're using inside of your applications is important for way more than just licensing reasons. It's important for security as well. And then on the other end of the spectrum is the Project SigStore and other ones related to it like Salsa or S-L-S-A. These projects help make sure that your supply chain has integrity, that it can't be tampered with, that attackers can't take over, build systems, inject malware, and that the software in your SBOMs is actually the software that you're using and you can trust that data. So these two combined can present a trustworthy supply chain so you can make sure that your software is legally compliant as well as secure from attackers. So starting with S-BOMs or software bill of materials. These are very old, they're not a very new concept, they've been around for a while but they are seeing a huge shift in momentum. We've been doing polls at my company and through the different open SSF working groups to see how widely they're adopted and it's starting to pick up. A year ago, even though the projects have been around, you couldn't really count on, you could count all of the companies actually shipping them to their users on one hand in a lot of the surveys that we did today and that shifted rapidly because of the guidance and requirements from government organizations all over the world. This started early 2022 with some guidance from the US White House and an executive order earlier the year before that from the Biden administration but we're seeing similar ones here in Asia and all across Europe as well, requiring software bill of materials, requiring new cybersecurity standards to be implemented in proprietary applications. That push for security has really expanded the use case of this tooling that's been around for a while. So momentum is pretty hard to ignore at this point. Unfortunately, the S-bomb adoption isn't everywhere yet and we're hoping that it will be over the next couple of years because of the collaboration that we're doing here with tooling inside of the SPDX community and across the broader open source ecosystems just because companies need to produce S-bombs and need to consume S-bombs doesn't mean open source maintainers are really prepared to start producing them yet. It's important that we make sure that burden doesn't fall on maintainers that are already overworked and out of time, as Jim just said. So I wanna touch on this again. This problem is not unique to open source but because open source is open because we can collaborate on it, it does present a whole bunch of unique benefits that will allow us to solve these problems together. This is a common kind of thud or fear uncertainty and doubt point that's brought up a lot and folks worry about a lot when we keep talking about improving open source security. We can't get rid of it. It's too late. It's counterproductive to keep arguing about that. It doesn't help. All of the survey data shows that open source software makes up somewhere between 90 and 96% of modern applications today when you start a Hello World application. You're not building that from scratch. It's not only your code that you're worrying about. You have to worry about securing the entire stack from the Linux kernel, the millions of lines of code there all the way up to your application that's serving traffic. Because it is open though, it means we can collaborate and fix all of that together. We don't need to secure all of that privately inside of our own companies. We can work together on all of this. We can't get rid of open source. So let's take advantage of these properties to help secure it together. So some of the wins over the last year. There's been a huge amount of progress just in the last year alone. I think this is a little bit unique because we're seeing a lot of progress driven from standards and legislation that are coming out rather than innovation happening first and then standards getting ratified at the end like traditionally happens here. But cybersecurity tends to take that, tends to require that in order to make progress, unfortunately. I like to think that we can always be proactive and introduce security measures before we really need them. But sometimes it does take these huge security incidents and government regulations to force progress across the entire industry. So diving into these first two with a special focus on what's happening here inside of the Linux Foundation. We've participated here in all of these White House meetings inside of the US and with every other government agency to help shape these standards. When you do have standards and regulations being driven this way, the risk is that they come out wrong. These policy makers are not open source developers for the most part. They don't understand software. And frankly, seeing some of the initial proposals is a little bit terrifying. You can definitely tell that these people do not write software in their day-to-day life. So they are looking to the organizations like this, to companies like your own and to every open source maintainer for input on how to do this correctly. Software developers don't wanna do things insecurely. They want the time, the tooling and the funding to do it the right way. So helping shape these standards is incredibly important. On the standards front, SPDX late last year, early this year, just got ratified as an ISO standard, making it an international standard that can be used, that can be used for compatibility in sharing software, supply chain metadata across companies and around the globe, which is a big win for unlocking adoption across different companies. The open SSF on the resourcing side, resourcing and funding is not required. It's not the only important thing to fix open source security, but it is still critical. People need time, people need tooling, people need hardware, they need CI systems, they need funding to run fuzzers in order to secure these open source libraries. And the open SSF has been a great organization to help provide that so far. Some other highlights, there's a huge effort this year to start requiring multi-factor authentication. There was 80 million GitHub repositories that you mentioned before. Each need to be secured and against phishing and other tampering attacks. As those repositories keep growing, we're gonna struggle to keep up with that. So efforts like multi-factor authentication that can completely prevent entire classes of attacks like phishing are critical there. And through the open SSF we've funded and staffed a whole bunch of giveaways of hardware tokens to open source maintainers to get them the tools they need in order to turn technologies like this on. There's also a multi-language package manager working group that is bringing together folks from the NPM and Python and Maven Central and Rust repositories to talk about how to roll out these package manager security improvements together. It's the first time folks from these different language communities have gotten together to talk about security. And it's been a huge win so far this year. And of course you can't forget the introduction of Rust into the Linux kernel. Memory safety bugs represent a huge, huge outsized amount and percentage of critical security vulnerabilities in every language that is written in memory on safe code. The Android team at Google just released some data last week showing that up to 70% of the critical vulnerabilities in every Android release were due to memory safety. Since the introduction of Rust into the Linux kernel there have been zero memory safety bugs in any of that new Rust code. This is another pattern of introducing a new technology to get rid of an entire class of vulnerabilities so developers don't have to learn and don't have to fix each of these security bugs line for line as open source continues to rise exponentially. So unfortunately there is no single solution to securing open source. Let me start to talk about some of the different initiatives that we need to increase investment in going forward. All of these attacks, all of these problems are very different and unfortunately we can't just take all of that money the open SSF has raised and buy security with that. We don't know how to convert dollars into security yet so we do have to figure out exactly what is going on. We need to look at the root cause not just the symptoms of these security problems that are cropping up in open source figure out how to address them at those roots and it's not going to be one simple fix it's going to be a lot of hard work. And from the company perspective open source security is product security. These investments aren't just for GitHub they aren't just for all of the code on the internet. Funding these improvements letting your teams spend time building fuzzers letting your teams spend time improving security upstream does impact your product security directly. So we do have a long way to go even in spite of those wins. There are a lot of risks to open source code that we need to address because it is open source and a lot of these can address because it is open source. We can fix things because of these unique properties. One of the most challenging ones is the contribution risk. We see this pop up all the time at typo squatting maintainers getting their accounts taken over. One of the great things about open source is that anyone can contribute to it. Unfortunately for anyone that spent a significant amount of time growing up on the internet you quickly realize that not everyone on the internet is a nice person. And just because a project has a bunch of GitHub stars or looks like it's widely used doesn't mean you can necessarily trust those maintainers. We need tooling to better identify malware before it gets consumed inside of our organizations and inside of further upstream projects. Bad actors aren't going to go away on their own. And even though funding isn't the only thing important for open source security, it is still critical. There's a lot of funding available. It's a distribution challenge, making sure that funding can get to the folks that need it and that it can actually be used successfully to improve security in the projects where that funding is distributed to. Knowing all of that, finally wrapping all of this up, knowing all of that requires a deep understanding of the open source that is used inside of companies that is used inside of your projects. A large project like Kubernetes that's probably used in almost every organization here today isn't a single project, even though it's a single organization on GitHub. It has thousands or tens of thousands of dependencies that are maintained by different sets of people. If you don't know about all of those, then security vulnerabilities in those lower level libraries can have just as much of an impact as the final application itself, like we saw with Log4Shell at the end of last year. So using Sbombs, building high quality software build materials, improving software inventory can help us find those critical projects that are farther down the stack, that also need security investments, even though they're not the ones getting all of the attention at these events. So investing in Sbombs and investing in accurate Sbombs is gonna pay dividends for security across all of open source. So where do we go from here? We've talked about some of the wins, some of the problems that we're still facing. A lot's happened this year, but we're not done yet. Well, we need to continue driving education and awareness. If people don't know about the security risks, people don't know how to do things the secure way, then we're gonna keep facing this problem every year as new developers get on board, as new programmers start writing code and shipping it on GitHub and in other open source projects. The education efforts they were doing, 10,000 signups for the secure software development course are massive in educating the future generations on how to build code securely from the start. And we need to continue driving Sbombs usage. Sbombs require a flywheel, people shipping high quality Sbombs and people demanding and making use of the data in these high quality Sbombs before they're really gonna see equity across consumers and suppliers. We need to build better tooling both to produce accurate Sbombs and to give organizations insights into the data they get from Sbombs so they don't just become another security checkbox that get required when procuring something and then throw it into a bin and never looked at it again. Once you've figured out how to do that right, we need to start doing that by default. Developers don't have time to do all of this manually every time they do a release. We need to make Sbombs invisible so we can actually secure the long tail of open source with them. We'll have a bit deeper here before we wrap up. In order to make Sbombs work for everyone, we need to invest in tooling. We need to make that tooling accurate and we need to make the data useful. There's kind of a gap here between open source and proprietary software today or just because something is open source, you can look into the dependencies and get a pretty good idea of what's inside of that. But as software flows through open source products, those products then being used to build other source code, we're losing data, we're losing fidelity there and there's a lot of gaps that we have to fill in in the software supply chains to get a good graph for source code all the way from the top of the stack down to the bottom. This is gonna require composition tools so that we can stitch these Sbombs together as they do transfer across organizations and across projects. And we need to continue improving the standards. The standards are great today but as they start getting used where to start figuring out gaps and the way they get used and to prevent different use cases from this data. Naming is one of the hardest problems in computer science and there's so many different ways to name the same package that they might look like completely different ones and prevent us from doing accurate vulnerability queries and making use of the data in Sbombs. So we need to make sure that we don't think of these as just the checkbox. The way we're gonna do this is with secure by default tool chains. If we do all of this right, folks shouldn't even have to think about Sbombs. I hope a year from now or two years from now we don't have as many talks about Sbombs. I'm sorry, Kate, but I hope that all of this is just built into compilers and tool chains and package managers and we can stop talking about it and we can just go on with our day and build software securely. We need to embed this into tool chains directly. That's some of the work that we're kicking off in the open SSF starting this year. So thank you for having me and thank you for helping improve the security of open source together.