 Welcome back, everyone, to theCUBE's live coverage here in beautiful Vancouver. I'm John Furrier with Rob Stratche. Breaking down all the action here on theCUBE, we've got two great guests talking about OpenSSF. Not SSL, my mind goes there immediately. Get two great guests. Omar Carr, Arastham, general manager of OpenSSF, and Brian Bellendorf, CTO of OpenSSF, CUBE alumni, great to have you guys on. Thanks for coming on theCUBE. I know you got a keynote to give. Top of the hour. Thanks for coming on, appreciate it. All right, the security foundation is super important. Funded, up and running. I saw your talk at CloudNative SecureCon. Security's top of mind. Security and AI are like the two hot major pistons pushing a lot of change in open source. We're feeling it everywhere. Obviously AI will get laid, but security right now is top of mind. What's on the agenda for SSF? Who's involved, who's funding it, what's happening? Well, the openSSF.org website has all of our great funders, the premier members all the way down to some of our public sector friends as well. We're interested in really ensuring that our software supply chain is secure for the benefit of the public good, and that's our mission statement. As we look forward, there's a number of initiatives that we have underway to help ensure that we realize that goal. We've made a number of great accomplishments over the last few months, and I'll probably turn to Brian for some specific details because this is day 10, and I don't know everything yet. What's just on the history? When was it founded? What's the starting point? How long has it been in existence? Brian, did you want to check that? Sure, so the project really got to start in 2020 as it coming together of a whole bunch of initiatives that kind of touched on the security of open source code and the software supply chain after things like the SolarWinds hack, that sort of thing. And then in 2021, we pivoted to kind of a funded operation to allow us to go and be a bit more bold about our initiatives, tell the world about it, but organize ourselves into broader themes. And we looked like geniuses because a few months later, Log4J had a little bit of a problem that ruined a whole lot of people's winter holidays, but that really helps crystallize for us what we had to go out there and do in terms of, I mean, try to find the next Log4J would be perfect, you can't do that, but you can go, what are the risks out there and how do we address those risks and drain risk from the open source ecosystem as a whole? Making software secure the North Star, get the mission, what are some of the challenges you guys are addressing right now? What's on the plate? What's the current goals? What are you guys doing right now? What's the priorities? So some of the areas that I would like to see the organization lean in and some of the areas where we've had some great progress, I think Alpha Omega has done some great work and the idea behind Alpha Omega is that we catch both the most used open source programs on the Alpha side and then we raise tide on security issues on the Omega side and they've made some great strides in some of the automated scanning work that they've done, as well as providing grants through the Alpha side for organizations like the Python Foundation in order to secure supply chain. I think we've also done a bunch of great work when it comes to SIGStore, to S-bombs, to areas such as that which will provide the base foundation and structure to allow us to do more secure things. S-bombs on their own aren't going to fix our problems, but they give us telemetry. We did it all day yesterday actually. That's going to come. Do you work across with other organizations like the CD Foundation had their discussion of CD events yesterday, for instance? How does that tie into what OpenSSF is doing? Brian, did you want to? Sure. So organizationally, there's a lot of overlap. Obviously, being all of us in the Linux Foundation really helps at the staff level. We share a lot of knowledge and understanding of who folks are, but there's actually on the ground a lot of developers who are part of each community who bring ties with them, right? So, for example, there's a tough TUF, which is the unified framework for security that has been a CNCF and a CDF project, and that is something that SigStore builds on top of and solves the references to try to pull together these different aspects of security in the software supply chain. So, CDF as like the home for continuous delivery is critical to that part of the software development life cycle. Lots of other pieces to come together, but that is actually one organization in particular that we work closely with. Yeah. I think a big piece of it, I think to your point, was trying to make sure that S-bombs just don't become a checkbox. Yes, I've done it because, I mean, having lived in that world on the IT side myself and built out SAS-delivered product, you start to look at the supply chain that you have in the S-bom, and as soon as you've gone and produced it, it's out of date, like an hour later or a day later at a minimum. It really, it cannot be, I mean, there are lots of regulations that are being proposed out there for hardening the software supply chain from various governments, and all of them put at the top. We've got to have S-bombs, got to have S-bombs, because the biggest perception is we don't know what we're running in this infrastructure, and when the log for shell breach hit, governments didn't know when they were done, right, in remediating. A lot of them still aren't done because they don't know where it's been compiled as some jar file somewhere. So an S-bomb in theory, even if it just listed the components that are inside would have that value. But even just that listing isn't enough. You want to know are there outstanding CVEs that aren't yet addressed? Are there gaps in the build process that, you know, that could lead to problems not just like log for J, but colors JS and left pad and some of these other supply chain attacks that we've seen over time, so. Brian, that's a great point. Oh, go ahead. No, my apologies. I was just going to add to that. If some of the more advanced things that we want to do in terms of supply chain security, if you don't have the visibility as to what went into the recipe, you're, and to your point, it's all point in time. We were discussing this with some other colleagues yesterday, and I used an example of, hey, an S-bomb's like a speedometer, and our colleagues said it's even worse. It's a picture of a speedometer. Exactly. I saw the pie example too was a good one on stage, but picture of pie, what flavor is it? I don't know. So this brings up the point about data. So I love, I think S-bomb is probably one of the most important concepts that's on the table right now for the industry. It's super valuable. Everyone can see the concept. I get it. What are the critical factors it needs to solve? Is the data observability? Is it marrying it in real time? Is it automation? Is it, it means is it a data problem? What is the problem space to solve the S-bomb? So there's no, by the regulation first. I think too much regulation will slow it down and anchor it and drag it slowly, but what's the core problem space? Because this is super valuable. So I think if we zoom out, and apologies, I've been in security for 20 years, and a lot of these are sometimes rehashed ideas in my opinion. Yeah, okay. If we look back to the sans top 20, or I guess this is now known the CIS top 20, number one has been asset management for the last three decades. If we extend that thinking to our assets no longer being servers and laptops and network kit, but also software assets, that is what the S-bomb seeks to address. Do I have a good inventory of the things that are going into my end product? Provided that, I think once we establish that that's important, which is an important beach head, having consistency in terms of the format, as Brian was saying, to say S-bomb, yes, but what format? What metadata should it contain? Is it going to contain my compiler flags? Is it going to tell me about how my compiler was built? All of these things matter when it comes to security. So I think S-bomb and establishing that as important is the first part of the journey. But then talking about how that evolves and how the data structures are supported through operational process. Now I know I have log for J. Now what, what do I do? Do I turn everything off? Brian, what do you think? I think you said it entirely correctly. I think there's a term that we're starting to float out there called S-bomb liquidity, which is really, how do we make sure that this metadata, through the software supply chain, captures as many of the different artifacts and aspects of its build, not just for reproducibility, but for verifiability and ultimately to be able to audit those kinds of processes, to be able to build dashboards that show you green, yellow, and red, like where are my problem areas? And I think if we do that, we can turn up, here are the open source components that are underutilized, under-resourced, vastly overutilized, but under-resourced, right? That I think log for J caught a lot of people by surprise because they had no idea that they were running it. Can we find those things that appear like problem areas and decide, okay, if we spend 100K to do a third party audit of that component, we then drain billions of dollars of risk out of the whole system. So S-bombs are key, but it's a structure, it's a vehicle, we've got to fill that with something. It's got to move from a mechanism to something more, I don't want to say organism based, like something more dynamic that could adapt to changing conditions, to whether it's data or some environment. That's the feeling we're hearing from people is that, how do you talk about that? Because software, they just want to write software. How do you, I mean, no one wants to do security. Security's got to be somebody else's problem, right? You know, like we pay insurance companies to worry about keeping our homes from burning down or something like that. It's like the rough mental bath that people, most people do, and they'd rather somebody else did it. I think what we're realizing now, especially in the open source space, is security is everyone's problem, but if you don't have the tools to measure it, you don't have the tools to know where the problem areas are or to know when you're improving, you're obviously going to try to write it off and push it to somebody else. If we can build those tools. Are you guys in triage mode right now? Because I mean, I can see the demand high for what you guys are doing right now. How do you guys take us through the day in the life of like, you guys get on zooms or meetings, like, is it like, tomatoes at each other? It's like, let's do this problem. I mean, you got so many things to work on. Weirdest starting point, what's the strategy? How do you guys look at what to take on? First, is there a playbook? Take us through that. Yeah, I mean, that's a great question. I think a lot of it today, and this is why we've got such a great board of directors. A lot of it comes from both the people producing software, the people consuming software, the other foundations, and we get input from everybody. And we then use our industry knowledge as well as their input in order to synthesize what the order of operations are. Now, prior to me coming on, I think Brian did some amazing work with the mobilization plan to help ratify some of that. Did you want to cover off those priorities? I think it's best understood by being kind of a mix of bottoms up and top down. Bottoms up, like every open source community, it's kind of driven by those who show up, right? And the people who want to work on interesting stuff have shown up and brought us SIGStore and Salsa and something called the Best Practices Working Group. In fact, that work is kind of organized thematically into a bunch of different areas we have under the tack. And then the top down overlay on that is when Logfriar Shell hit the White House asked us, these are some cute experiments. What are you actually doing to solve these problems? So what will it take? So that's when we developed the mobilization plan which said, top down, here's minimum viable product offerings in 10 different directions that we think, again, drain risk out of the software ecosystem, not just open source, but everybody's software. And that's been a useful guide to think about what areas should we go into next, where could we pull some resources to tackle this or that. We'll be updating that plan. We're also building an overarching architecture, if you will, for how these disparate pieces really fit together into the tool chains of the world. In fact, one example of this is GitHub has recently adopted something called NPM Providence, which pulls together SIGStore, Salsa, and a few other pieces to allow you to have full, verifiable traceability for your NPM package back to the root. How are you guys enabling the cross-connect with research? We're seeing, at RSA, we covered a lot of Independence, MITRE has a group in Cambridge, Massachusetts. They're funded, nonprofit, to go in and look at a lot of the securities kind of in the battlefield of what's happening. Try to get the data. Are they involved? I know Amazon's involved. You have the big cloud players. Now you've got other companies that discover here that are called end users. Like, I mean, I guess they're called end users. But they're companies too. They're deploying open source. What's the makeup of the key personas and how do you guys thread for the folks watching that might be independent research, academic too? So one, I mean, as Brian mentioned, being an open source organization, more participants the better. We welcome participants helping along and helping to guide our decisions and helping to provide us input. Personally, the way that I categorize the different actors in our use cases, I think of people producing software such as the Googles and the Microsofts and the Amazons of the world. I think about, you call them end users, we have an end user work group with the Citibanks and the JPMorgans. And the capital ones of the world. I think about our public sector as well. Our governments are deeply involved with ensuring that the direction they're providing their citizens be they domestically here in the U.S., I know we're in Vancouver, or abroad, North America, or abroad, they want to seek input because they recognize that this can only be done through public-private partnership. And then last but not least is the research, be it from academia or peer security researchers in their classical sense. I think we do need to take on input from all these stakeholders. So you're open for business for anyone, basically. Pardon me? You're open for business for anyone to come in. We're open for business. And I think the ideal state that I would like to get to, and I think Brian as well, to achieve that goal of securing our supply chain for the greater good is I want to get out of mosquito swatting. And I want to get to the point that we have the proverbial citronella lamps everywhere. And by that I mean actually ensuring security software that's secure by design. I identify as a software engineer that's been doing security for 20 years. I'm inherently lazy. I want the defaults to be secure. I want it to be very difficult to be insecure. And for anyone that's tried to use the Borrowchecker in Rust, this is the perfect example of that. But I want to enable that more broadly so things like memory safety are just there. We don't have to think about it. The Cloud Infrastructure Code has proven that developers can program the infrastructure. This is super valuable and it's a great initiative. For the last minute we have left, could you guys share real quick, a plug each of you for what you're looking for, audience out there, what you're looking for in terms of support, engagement, put a pitch in or a plug for the organization. What would you like to share to the audience? We'll start at the moment, I'll go with you first. We can only build secure software for the greater good if we're all participating. So I'd encourage everyone to participate. OpenSSF.org is where you can find more information about how to participate. Brian, what would you add? Brian, lay it down. I'd say to all the developers out there, we've got a tremendous number of resources on the OpenSSF website that you can use to be a better developer, to write more secure code, come and consume it, and to all of their bosses out there, give your developers the time and opportunity to do that. I know adding features, fixing bugs or priorities, but you've got to pay off the technical debt, you've got to do the hard security work, or you'll be the next log for shelf. This is a super important initiative. I mean, security has to have the guardrails. They've got to make the developers more productive. Everyone's shifting left as we're talking about at KubeCon and CloudNativeCon, Rob, so it's a good time. Yes, yeah, no, I think this is great, and I think it's, like you said, it has to get out of the swatting mosquitoes aspect of it. And I think this is great that you're putting a roadmap, basically, together to help these companies get there, so. Yeah, thanks for coming on. Brian, real quick, I know you've got a keynote, you're going to walk to it right now. What's it going to be on? Obviously, security, give a quick plug for the talk you're giving. It's about baking security and the defaults and the tools that developers use. How do we make it so when a developer falls out of bed, they do it securely? Awesome. Oh, great to meet you, Brian. Great to see you, Kube. Well, I'm nice to hear. This is the Kube coverage in beautiful Vancouver. Our view at our office is beautiful. We showed you the shot. We're looking at the ocean and the mountains. It's beautiful. This is the Kube getting all the action here at the open source summit 23. Thanks for watching. We'll be right back.