 Hi, this is your host, Sapna Bharatya. And today we have with us Brian Belendorf, General Manager of Open SSF at the Linux Foundation and Michael Escoveda, Principal Security PM Manager at Microsoft. Michael, Brian, it's great to have you both on the show. It's great to be here. Thanks. Great to be here. And today we are going to talk about Alpha Omega Project. If I'm not wrong, it's kind of created to one of the biggest challenges which is software supply chain security. I will talk about the project, but before I go there, because, you know, there was a White House meeting recently last year, there was an executive order also regarding S-bombs. So there's a lot of awareness going on there, especially from the, you know, public sector. But I want to understand from both of you folks is that in reality in the industry, how much awareness, how many people actually aware of the software security problem itself that, you know, then you're like, you know, let's help these folks. If they don't even know, then it's like, first educate them what it is. Yeah, I'll jump in. I mean, it seems like every six months, there's yet another privacy breach, yet another hack, yet another defect that causes all of us in the industry to go, well, now they'll take it seriously, right? Now they'll really understand the stakes that are involved in this. And the most recent of those, of course, was Log4j, which, you know, the Log4j developers, the Apache Software Foundation are professionals. They were building things, the best of their abilities. But we're all human. We all have bugs in our code. The best developers, Linus Torbalds, Vitalik Buterin, I don't know who you are or care who you are. You've got bugs in your code at some point. And what we need to do as an open source software ecosystem is get really much better at finding those bugs, at fixing those bugs, and then asking ourselves, you know, in the software supply chain, where are there certain assumptions that we've made because open source came out of a relatively high trust environment, you know, where you could get to know the developers behind all the packages you depend upon or behind that operating system you've preferred to build on top of. How do we move from that high trust environment to what is kind of a hostile low trust or zero trust kind of environment? Where, you know, you have to think about each of the points in that supply chain from your IDE to the way that you pick your dependencies that you're going to use, to the way that you package it and ship it and send it out and ask yourself where are those going to be attacked, right? And then the inverse of that is, if you're running an open source project, what should you be doing to help reassure your end users that you're taking kind of all the kind of, you know, baseline precautions and baseline actions, practices that help, you know, not only reduce the likelihood of a bug like log4j from happening in your code, but also help your end users when such a bug is found, update more frequently, right? So there's lots of things going on at the open source security foundation targeted at this. And in fact, in October, we raised about $11 million inclusive of the 5 million for Alpha Omega to focus on this problem. And we've got a whole bunch of great organizations that have joined and committed real capital to make this happen. Then a lot of our impact is in everything from education to best practices guides and the badging to all these different efforts. And on Tuesday morning, we announced the Alpha Omega project, which we'll talk about in just a bit. But all of this is really resonating with a community, with an industry that is recognizing, there's a whole lot that we can't take for granted anymore. And even government as one of the largest users of open source software, and now starting to create open source software, realize that they have a role to play in this as a peer to industry, but also as the kind of organization that we trust to worry about critical infrastructure and software and especially open source software has become critical infrastructure. Michael, I wanna hear your insight because first of all, Microsoft does a lot of work in security space as well, you folks are focusing a lot. And you also work with actually the users all the way to Azure or independent. So to talk about, what have you seen in this space? I think the biggest thing that I've seen, I agree with having that Brian said is that the amount of open source that's being used today is much greater than it was 10 years ago and 15 years ago. So if you look at a typical application is mostly made of open source. And this goes through for the largest enterprise applications to the smallest mom and pop shop, business running tools. So when you look at it, open source is the foundation of technology today. And it's where, so in some ways the stakes are higher because a critical vulnerability and just one component could affect thousands of organizations, countries. So it could not be more important and very optimistic that the current focus that we're now seeing on it is gonna pay off in terms of we're able to move the needle on it. Thanks for sharing those insights. Now, let's talk about the Alpha Maker project. Let's talk about, of course, Brian, you turned the point briefly, but I want to also understand what are the discussions that happened, how Microsoft Google and Linux Foundation, they're like, hey, let's do something about this problem. Well, a lot of it started with a white paper that Michael initially authored and led a kind of a process through many of our open SSF members and peers through iterating on. Michael, why don't you talk about the drivers behind that and then I'll add some flavor on top. Sure. So part of my role at Microsoft, I lead an open source security team. And part of our job is to look at critical pieces of open source that we use and determine if they're safe or not. And this goes beyond, are there the publicly known vulnerabilities to how can you use them in a safe manner? Have they been looked at are they still being maintained, things like that? But as we were doing this and as we were doing more of them, we realized that other organizations were probably doing similar efforts or at least aspirationally they wanted to do similar things. And we didn't think it was efficient or even effective to have every organization reviewing the same open source projects. So wouldn't it be neat if we could pull our resources to do end times as many or end times as much work across by not by choosing to not compete on the security of open source. It benefits no one for there to be a critical vulnerability in a piece of open source. So we started this conversation with Google a few years ago. It ultimately was kind of reborn again this past summer through and with open SSF to the point that we're ready to move on this together as an industry and agree to pull our resources and do this together. Yeah, and all that part of the thrust of Alpha Omega is to recognize that every viable open source project is different. It's different in how it runs at CICD, how it approves pull requests and what decisions it makes when it decides the balance between paying off technical debt and updating dependencies and adding new features. And it was important to try to figure out a systematic approach to addressing what is really the both ends of a spectrum of projects. The Alpha projects, the ones that are most widely used, the ones that are busiest, right? And the ones that are most critical perhaps to critical infrastructure, but then the very long tail of projects that get included in so many different software stacks out there and kind of get forgotten about from time to time, more the color.js types than the log for J types, for example. And addressing them requires some different techniques that kind of meet in the middle. On the Alpha side, we plan to really engage with humans, with the maintainer community and the broader community around a couple of chosen software initiatives that are at that upper end to try to say, where could we be helpful in the kinds of processes and practices that would improve your security posture, right? Take a very open-minded approach, point to things going on at OpenSSF, but potentially other places that be helpful. And if there's a need to cut a check to help with a code review here or some other kind of regular scanning there, happy to do that to help prove the value of the stakeholders in that community pooling funds to make security an ongoing process, right? At the Omega end, which is that long tail, the top 10,000, which even that is a subset of the millions of repositories on GitHub, for instance. There the question is, can we use automated tooling to try to systematically look for new kinds of vulnerabilities? Each time there is a problem that pops up like a log for J, how do we systematically query, is there a similar kind of functionality or similar kind of weakness across a larger range of open source projects, right? So think of like the first part is kind of the security equivalent of the Software Freedom Law Center, where we hope to work with projects to help them, rather than on legal issues, on security issues. And then the Omega ended that looking a little bit more like an open source version of Project Zero, which is how to systematically go and find new vulnerabilities and then work with the maintainers to get them fixed or even if they just look like weaknesses, try to get them updated. That's the big picture for Alpha Omega and it's in its high touch. And the 5 million that we've raised from Google and Microsoft is really just seed funding to get this started. And thanks for answering a lot of questions that I was going to ask there. So I appreciate that. You talked about the human aspect and the tech aspect. And there are two things I would talk about. Human also sometimes leads to cultural problem. I'm sure Michael is very much aware of that. It leads a lot of mindset changes, culture. We do talk about DevSecOps, but sometimes it looked like more of a preaching than practicing. So how do you actually really want to address that? I will also talk about the respect, but let's just talk about the cultural aspect. How do you want to change the mindset of people? How they should look at security? I think that culture wins, culture is king. So the way that we're approaching both Alpha and Omega is to meet projects where they are. We are humbled in the way that in that, industry at large has taken a dependence on open source in many, many ways. And some of these range from projects that are sponsored by a large company through passion projects, single developer. And we don't look at it as industry telling open source that they're bad and they're insecure and they need to do this stuff because we need to make money off of them or anything like that. There's really coming from a place where we want to help. But I think what's changed is that about Alpha Omega is that we're showing up with money and people, not with reports or dashboard or just dashboards or things just pointing out flaws. So in the instance of even Omega, where Omega's primary focus is gonna be on critical vulnerabilities. When we find a critical vulnerability, we're not just gonna ship a report out to the maintainer and say, in 90 days this goes live, we make this public or things like that. There's gonna be a back and forth. So we're prepared for that kind of, that deeper engagement. We will be writing code to help them. If they need a patch, we will contribute it. On the Alpha side, even more so, where because Alpha is a much smaller number of projects, we'll be able to go deeper and establish long-term relationships with these projects. What kind of collaboration or for the engagement we can expect from companies? Who can traditionally be competitors in the market? But with open source, we all work as collaborators as well. The conversation that I've had with Michael Windsor from Google and others, we don't wanna compete on the security of open source, period. So in everybody's best interest that open source is more secure, we hope that other large organizations and small feel the same way and are willing to join us in this endeavor. We don't think that anybody benefits from the current state. You know, at the OpenSSF, we've pulled together an amazing constituency of 60 different companies who are all interested in the same topic. How do we improve foundationally the security of the software that we all collectively benefit from? And of course, the rest of the world will benefit from the investments that they've made. And it really is like all the leaders, not just of like the Silicon Valley, quote unquote tech kind of tech circle, but we've got systems integrators in there. We've got Wall Street, who are major consumers of open source software now actually starting to produce a lot of their own open source as well. And you know, we've been building bridges to folks in government with other organizations to try to look at, you know, the interest that they have, you know, just like this White House meeting. So it's really great to see industry kind of converge on there's a common set of tools and techniques that we can all work together on. It benefits all of us. It lifts all boats sincerely. And you know, part of the role of the Linux Foundation is to play convener and facilitator for these kind of purposes. But I tell you all the hard work is being pulled in by the member organizations. And so with a broader open SSF, lots of different organizations pulling together with that, with Alpha Omega, which is part of it. We're starting with seed funding from Google and Microsoft and really, you know, lead by example kind of leadership. But we're very eager to involve other organizations and helping fund this work so that we can expand the footprint, expand the number of projects that we can serve at both ends of the spectrum. Since you mentioned these members, I also understand that since Alpha Omega is part of, you know, open SSF project, outside of the seed funding, who are the companies who will be involved or every member of OpenSSF, they will be involved or because the Linux Foundation, the unique is that every project, while they are part of Linux Foundation, they have their own sovereignty, they run their own governance the way they want it. So if you can talk about, you know, how things look like for Alpha Omega. So for Alpha Omega, just like other OpenSSF projects, really every Linux Foundation project, there will be channels for engagement that do not require payment, right? This is not a pay-to-play type of operation. We need volunteers to help us understand and define our approaches at either end of the spectrum. And particularly at the Alpha side, you know, the more that we see folks with a cybersecurity background, with a secure coding background interested in helping volunteer to work with us to go and engage those Alpha projects, the better. And even the scanning tools that we see using on the Omega side, even many of those will be open source, whenever there's software involved, that'll be open source software. I think actually engaging a broader community and helping us further develop those tools. Maybe there's even internal tools or proprietary tools that could be open sourced as a part of this. We're very eager to explore that. And then in terms of funding, you know, we have Microsoft and Google participating for two and a half million dollars per year to make this work. We're very eager to find other organizations willing to put in at that amount or larger. We'll have other opportunities to fund perhaps more targeted work or funded other levels, but we don't wanna spend all of our life fundraising, you know, and this is expensive work because it's personnel heavy. So we're really eager for those organizations that recognize the importance of addressing this problem to engage with them and allow us to be able to get out there and actually have boots on the ground to make some of this stuff work. What kind of goals, you know, or what kind of road map you set for yourself when you sit down again next year that you're like, hey, this is what we were planning and this is what we have achieved. I think Alpha Omega is an experiment. We are going to learn for the first six months. We are going to, we will do our best. We will get some things wrong. We will iterate and get better. But we think it's important to move and to try and to do initially. So a year from now, we will be a lot smarter than we are today. I'm expecting, you know, to have at least a reasonable small number of kind of Alpha engagements completed that we'll be able to iterate on and learn from. For Omega, some of, because part of Omega is about building the system that does the analysis, getting that out first is pretty important. And then iterating and going from there. So, you know, I don't want to try to plan too far out in advance because I'll be wrong, but I know that we'll be in a better place a year from now, at least now our ability to turn, you know, we'll have this machine, at least my hope is, my dream is that we have this machine that will turn dollars into better security assurance in open source. And the more dollars you put in, the more assurance we get out. Are you also working with other Linux foundation projects also because, you know, in the end, you know, security is everybody's problem. It's a process, not a product. Well, frankly, every Linux foundation project has some piece of what they do that's focused on security. Some are able to actually resource things like third party audits and, you know, paid security staff and that kind of thing. Most aren't able to fully resource those kinds of things, but I see this shifting of it where the, you know, boards of those projects and the stakeholders who help fund it will start to increase their funding that they direct to that kind of thing. We've also talked internally about adoption of many of the things coming out of OpenSSF, you know, the best practices badge and security scorecards work about the importance of multi-factor auth actually want to highlight that NPM just announced that they're going to start requiring multi-factor auth for their modules hosted in NPM for the developers who put it there to try to avoid account hijacking issues and that kind of thing. So we're starting to see more pickup of kind of these foundational baseline tools. The Linux foundation as a whole has been behind this. I mean, you might have even remembered when OpenSSL had its heart bleed issue who went around and raised some money to try to provide core funding for that staff and elevated them for quite a while to help get it to a better place, which we did. And we've also invested quite a bit in the SBOM standard called SPDX. That's now an ISO standard. But actually, and then I'll end with a whole lot of the inspiration for OpenSSF and a lot of the projects there came out of the cloud native compute foundation and the security tag that's there. I'd say that project more than any other has been a leader in thinking about securing the software supply chain and building that natively into the tooling so that it's just how things work is you get greater assurances from A to Z. So, yeah, it's an incredible collaboration internally at the LF. And hopefully through Alpha Omega we can bring that to the broader open source ecosystem as well. Brian, Michael, thank you so much for taking time out today and talk about Alpha Omega project and also talk about the wider problem that is there with security. Thanks for those insights. And I won't wait for the next February. I would love to have you folks back on the show before that. But thank you for your time today. Thank you. Thank you, and I'd love to come back anytime.