 Thank you. I know you said that your talk was not going to be a lecture. Mine is definitely going to be a lecture. And you should definitely take notes. Today, I want to talk about our organization, the progress we're making, how happy I am to have as a part of the Linux Foundation. Our organization has brought together some of the most important shared technology investments in the world. And we are home to the largest technology investment in the world. It's a period, right? Open Source and Linux and the projects we are host to really do represent a multi-billion-dollar investment and are ubiquitous part of all computing. You're adding two members a month globally at the Linux Foundation. We're adding a new member every single day. We, every single day, have hundreds of thousands of developers working across the different open source projects that we host and have vast representation from thousands of companies representing hundreds of different industries around the world. Our membership represents is about a third here in Europe, a third in North America, and about a third in Asia. So we're pretty globally distributed in terms of representation. We'd like to see more representation from areas like Africa, the Middle East, South America. But I think the regions that we represent generally are where tech is being made. We're definitely more than Linux these days. GAB has been a real leader in terms of bringing financial services into the world of open source, both from a consumption and a contribution perspective. And I've spent about the last 20 years bringing many other vertical industries into the world of open source and really being able to realize in each of those industries the benefits of collaborative innovation. Examples include the film and entertainment sector. Our Academy Software Foundation is a partnership with the Academy of Motion Picture Arts and Science in LA, the home to the Oscars, of which someday I hope to be a seat filler at through our Academy Software Foundation effort. But this is something where we spent several years working with the CTOs and legal teams and engineering groups at Lucas Films, Disney, Pixar, et cetera to show them how they could collectively develop the computer graphic software, the CGI software, that creates the most beautiful films, the Star Wars and Marvels and all the different films that you know and love. And they ended up doing it. And the reason is they're in the storytelling industry. But the software development aspect of that community was insane. Every time you'd make a film, you'd have to build up all the technology. You would create the film. And then afterwards, you'd break it all down and you'd do the same thing somewhere else. And each studio was doing it differently. Now, because they do it all collaboratively, they have a standard set of development. They're able to really produce much better films more quickly. And that's what you're really seeing in the visual effects that are in so many of the brilliant films, Top Gun, I guess, being the most recent example of today. But we've also done it in cloud computing. We're home, as Gav mentioned, to CNCF. The CTO of CNCF, Chris Anicek, is in the back of the room here today. This is one of the largest and most fast-growing open source communities in the world. This fall, we'll be hosting 10,000 developers in Detroit at our cloud-native computing event, KubeCon. In the energy sector, we work with folks here in Europe. RT in France, the national grid operator, has a big problem in making the distribution of power more efficient. And as a national organization regulated by the government, they don't make money off of software. And so they came to us and said, we would like to give away the advanced software that we're building in order to create smart grid technology and collaborate on it with energy and utility companies in Germany and the United States and China. And that is exactly what we're doing. Over and over and over again, we're realizing the value of collaborative innovation. Each of our projects has a goal. And Finno's projects are no different than this, which is we want to find good project market fit. The technology isn't that interesting, or it's someone's PhD thesis on GitHub. That's not something we'd really care about. But if it's a global operating system or a core component of the financial services sector that really creates value, that's project market fit in our world. When you have that, people can code develop that software, and then they start using it in the products and services that they're offering to their customers. In the case of Kubernetes, all major cloud providers have a Kubernetes service offering. They make money off of that service offering. And as part of the profits that they're making from that service offering, they pay their engineers to fix the bugs that they discover in offering that service and improvements that they want in that software back into the project. Better project, better products, more profits. This is the positive feedback loop that we always focus on at the foundation. We have a detailed methodology about how to achieve this positive feedback loop, and it's what we're always focusing on. I think my slides continue to disappear with each click here. I'm not even, I'm just gonna remember what I was supposed to say on this slide. It was a last minute addition, and because we're here in the UK, I wanted to quote Dickens. And so with all the good stuff going on at the Linux Foundation and these critical open source projects that run almost all technology products and services in the world, we're really in sort of the best of times, but we're also in the worst of times. And I'll tell you what that's all about, and that's really the core of what I wanna talk about today. In terms of the best of times, we're really realizing the true value of open source. This is no longer a novel thing. Open source is not a bell that can be unwrung. Open source is now a fundamental part of how any technology, product, and service gets built. In 2022, you would have to be insane to build your own operating system, middleware stack, different components. It just, there are literally millions of reusable, very high quality building blocks out there that you can bring together, integrate, and build incredible technology products and services. The tech sector, now the financial service sector, most folks have figured this out quite a while ago, and that's why we have this incredible, two trillion package investment out there that people use to create this amazing technology. And so that is the best of it, but there also is in particular a big challenge that open source is facing right now, and I wanna spend the rest of my time talking about the challenge. I wanted to kind of butter you up with the good stuff that's going on in open source, and then now unfortunately talk about the bad stuff that's going on in open source. There have obviously been a huge increase in high profile security vulnerabilities in the global software supply chain, and in particular in some very high profile open source components. I know a lot of people mentioned that they had heard of Logforge vulnerability, but how many of you actually were involved in remediating it in your firm, like the working on Logforge? Okay, so a lot of you, yeah. Still doing it, I suspect. It's every audience I talk to who's in the tech sector is still working on remediating this horrific vulnerability that put all of us at risk. The amount of time, effort, money, and risk that has been injected is in the billions of dollars, from just one vulnerability. And we're seeing these vulnerabilities increase at a very high rate, and I'll tell you why that's happening. So while open source is the best of times right now, it's also the worst of times. I picture some popular node package maintainer and I'm like, can I have some more sort of asking for resources to help with security? And that's something that I think we all need to do. And the reason for that is because, as I stated, open source is a fundamental building block of technology. Next week I'm gonna be at the White House in the United States, meeting with the Commerce Secretary, talking about cybersecurity, the head of the national's cybersecurity directorate, Chris Inglis. And what I always talk to regulators about is, no, you can't just get rid of all the open source. Like that's never going to work. It would take 20, 30 years to rewrite all the software. So that belt cannot be on wrong. But now because of these incidents, we know how critical security is. To reel people's lives, energy grids get shut down. All of you stay up all night freaking out about who got into your perimeter. You're still freaking out, I suspect, about that with Logforge. So we understand how important this is. Adversaries, they're just getting better. And adversaries aren't just criminals, they are now nation states, as we've seen in the conflict in Ukraine. Sort of a low level cyber conflict that that has created. And then finally, regulators in this industry does not need to have this explained too much. The regulators are a common. So we need to either clean this up collectively or the government is going to start potentially doing it in a more ham-handed way. And that's something that I think we all need to consider and work on fixing. And so in order to do this, we have to answer a few simple questions. One, we have to decide what is the world's most important shared software? Package, version number, in rank order. Figure out if this particular component has a vulnerability, how many of us are gonna be impacted by it, right? Is it network facing? Is cryptography involved? Rank up, figure out what are these components by importance, figure out who writes this software, and then figure out whether or not it's secure. And not only figure out whether or not it's secure, continuously measure the security of this so that we all can continually understand these critical components are being maintained effectively or maybe they've been abandoned or maybe there's a certain number of vulnerabilities or maybe somebody new just showed up and started writing weird code, right? We should know this stuff. We don't know this stuff. It's embarrassing that we don't know this. The last thing we need to do is look at weak points in the global software supply chain and fix them in the way that code flows and I'll show you how we're gonna do that. The first thing we wanna ask ourselves is who writes this code? And this is interesting. I talked about the 760 odd thousand developers that work across the Linux Foundation every day but our research department did an interesting set of work in partnership with Harvard University to answer the first question I asked was what is the most important shared software in rank order in the world? And we did that and we came up with a list. What's interesting is the power law of open source. Of the top 49 of the top 50 software components, 23% of those projects are only maintained by one developer that writes about 80% of this code. So one thing we're just thinking about is just calling these individuals up. Can we offer you a secure coding course? How about a little bit of testing help? How about additional resources and so forth? And I'm gonna show you how we are literally doing exactly that through our open source security foundation effort at the Linux Foundation. Second, it's important to understand, this is the call to action from the folks in the financial services sector is that as much as you all think money solves all problems and I like to think it too, that is not what solves problems when it comes to developers. We went and surveyed like why do you work on open source and money was in most cases the last reason that these maintainers of these critical open source projects work in it. They use open source because it gets their job done more easily because they wanna be a part of something bigger than themselves. They wanna be a part of a shared mission. They wanna show their technical prowess and advance their career. Money was the last thing on their mind. The money's not gonna solve everything. Lastly, when we talked to these developers, one of the things that we realized is that they need better training. Literally, there is not a single computer science department in the United States that requires a secure coding class for graduation from a computer science degree, which is totally insane, which is in fact the topic of the meeting that I'm having at the White House next week with Secretary Ramondo. We've got to do better than this. And so the Linux Foundation has created a plan. I'm gonna go over that quickly with you because now I have 10 seconds left and as I said, it's a lecture, it's going over, take notes. I'll go fast. To solve this problem, what's important to understand is how code flows. Now I don't need to tell most of the folks in this room because you're all technology professionals how this works, but it's important to sort of simplify and understand how we attack this problem by looking at this. Code starts with the developer in their mind, in a repository, often on GitHub, GitLab, some shared repository, where they're writing the actual software, right? And in that part, there's all sorts of ways to mess with the code. You often don't have code review in a lot of open source projects, or people can bypass it, or you can compromise the actual source control system itself, right? After that, code keeps flowing and now we start to get into the whole remix aspect, which in particular in the last five, six years has become this fundamental way to create software. You're using node components from NPM, or Ruby gems, or you're using Java components from Maven Central or so forth. In each of these package managers, there is many opportunities for bad actors to squat on particular packages to sort of usurp these packages. We hear constantly about people coming in and compromising various node packages and then compromising all of us, right? Through these dependencies and bad packages and so forth. And so what we're identifying at the foundation is ways to address each of these things. And while I wish that the type was on this particular slide, I'm not going to remember every single component of the effort that we're doing here, but I think you get the gist. Our open source security foundation has efforts to look at how do we do best practices in writing code? How do we work on vulnerability disclosure? Does an open source project have a responsible disclosure policy period? Do they have a security mailing list? Do they have testing and tools that they can use in order to write their code, to fuzz their code in order to lint their code more effectively and so on and so forth? And so we've totally lost all of the text for my presentation here. What you should be seeing here for the first time ever is a comprehensive plan that we have developed. Can we get a little help in the back there because this is really the meat of the presentation? But all kidding aside, about a year ago, the open source security foundation kicked off with about a $15 million investment. So just before Log Forge, I called up the CIOs and CTOs of Amazon and Google and Facebook and Microsoft and many of you and said the same exact thing, sort of gave the same pitch and said, listen, we gotta get ahead of this. And we were able to get the open source security foundation together with sort of a CEO minus one executive commitment on the board to go work on these problems. And an initial seed fund of about $15 million. Then of course, Log Forge happened, I looked like a genius and we were sort of ready for this. And for the first six months of this year, that organization has developed a 10-point plan, which I hoped to show you today, but now I'm gonna have to describe it by memory, the first really truly comprehensive approach to how do we go answer these questions and solve these supply chain issues in a scalable way across the entire industry and across the globe. We presented that plan in May at the White House. We had the participation from a huge swath of technology industry participants and we raised an additional $30 million in resources toward that plan. And the plan really involves the stuff that I'm really hoping we can get up on the screen here any moment, but it involves a few things. One, training. We really need to create secure coding courses. I would argue that the Log Forge vulnerability would not have happened, and I hope the maintainers of that project are not listening to this because they'll be all pissed off at me, but the vulnerability, the nature of the vulnerability for anyone who had taken a secure coding class would have been quite obvious. And I think that that happens over and over and over again because a lot of open source developers, well very talented computer scientists and developers, just don't think with security in mind. I'll give you an example. Remember back in 2003 when Microsoft was having a lot of security problems? Bill Gates writes a letter to the whole company with his famous letters, and he says we're gonna stop all production at Microsoft. Everybody has to take a secure coding course, we're gonna introduce better testing, we're gonna have a trustworthy computing initiative, we're really gonna take security seriously. And the implication is stop all coding, do this, or you're fired, right? Because all these people work for Microsoft. But we can't go fire a million developers globally who work on these critical open source projects. So we have to provide them free resources and training, there you go, in order to allow them to know how to write code in a way that won't put us all at risk. This is securing open source production. We need to just figure out ways to then, once folks are writing more secure code, look at that code, trust and verify, right? Do better ways of testing, presenting analytics about the results of that testing and so that all of you as consumers of that open source project can understand the health of each of those components. If you go to the Linux Foundation's website today and look at our LFX security tool, this is the start of an open source reputation platform that literally measures based on scanning of code with commercial code scanning tools based on testing each of the projects on whether or not they've taken secure coding classes, whether they have security policies, whether they have security mailings and so forth, to give sort of a risk score for each of those projects. Go check this out. This is something we're investing in in order to make all of us safer. We're looking at doing just dumb, simple things like how about using package signing with cryptography? Wouldn't that be actually important? NPM finally got this done just recently. Just recently, they're using two-factor authentication for critical open source component maintainers so as to prevent that attack vector and so forth. Now, once we establish that baseline, we really wanna work on vulnerability disclosure and remediation. One of the things that we're working on right now is a project called Alpha Omega. We're taking the 10,000 most critical components and applying that reputation framework and a set of scanning and sort of automated testing components for security vulnerabilities and we're taking the top 200 most critical open source projects and we are literally doing an audit, we're using third-party audit companies to audit every single one of those projects in detail. And has anybody here been through a security audit of code where you actually have third parties read the actual code itself? Every time we run one of these, the Cloud Native Computing Foundation does this all the time with Kubernetes, we find zero days every single time. This is something that's critical to all of us and doesn't even cost that much money relative to the cost of a log torch. The last thing we're doing and I'm kinda skimming through this and there's a white paper up on the Open Source Security Foundation's website that presents this in great detail is we're looking at creating more liquidity in the world of software bill of materials metadata. So one of the big projects that we're investing in is automating the ingress and egress of software package data from repo to package manager to consumer so that all of you have a much easier and commoditized programmatic way of knowing whether or not you're vulnerable to log4j or whatever the latest vulnerability will be. Right now, just figuring out what you're using is so bad across so many sectors that we need to improve that. Software bill of materials metadata that's automated and easily distributed and is very liquid across the industry will be a force multiplier in enabling the faster mediation of things like log4j. Here's the punchline and I know I'm way over but it's really the people's fault in the back because I had to riff for so long while I was waiting for those slides. The punchline here is this is just a rough estimate of the cost and we're already well on our way as I mentioned to raising the money to do this but we're talking like $150, $160 million over a couple of years to seriously have an order of magnitude impact on our collective cybersecurity. This is a complete no-brainer. Like it costs a lot more than $150 million to remediate the log4j vulnerability, just one. I think some of the Equifax fines, I think for just one vulnerability, the struts vulnerability, just the fine to Equifax, I think was more than $150 million. One company and the fine itself wasn't even remediating it. This is something that I do want to encourage all of you to look into and participate in and it ain't just about money. If you have expertise at your firm that you can lend to the open source security foundation that can help with auditing, creating that reputation framework, helping with the automation of software build materials metadata across the supply chain, help with building a package signing across all the package managers that are out there in open source. We need both money and expertise. This is a totally doable thing. It is not a moonshot, it is a mobilization plan. There's nothing particularly innovative that I've discussed today. It's just a lot of freaking hard work that will make us all more secure. And so with that, I really thank you for listening to me today. I encourage you to do this. As bad as the security problems are these days, the value of open source is so much larger. Let's spend the next couple of years fixing this one problem that we have and I think all of us will collectively benefit. Thank you very much. Thank you.