Techstrong TV: 19 Organizations Join OpenSSF
OpenSSF announced 19 new organizations have joined OpenSSF to help identify and fix security vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. Alan sits down with Brian Behlendorf, General Manager of OpenSSF, to learn more. The video is below followed by a transcript of the conversation.
Alan Shimel: Hey, everyone. Welcome to another Techstrong TV segment. I’m really happy to be joined once again by Brian Behlendorf. Brian is with the Open Source Security Foundation or OSSF, as we say, part of The Linux Foundation. Hey, Brian welcome to Techstrong, welcome back to Techstrong TV. Nice to see you.
Brian Behlendorf: Thanks, Alan. It’s great to be here.
Shimel: Absolutely. So Brian, I think most of our audience at this point, I hope, anyway, they’ve heard of “OSSF” before. But for those who haven’t, if you don’t mind, why don’t you give ’em a quick sorta primer? What’s the OSSF about?
Behlendorf: Course. Well, the Open Source Security Foundation got its start about two years ago, actually, at The Linux Foundation, where there were a bunch of folks asking really deep questions about, are there are some flaws or some problems with the way that we in the open source community write code when it comes to trying to really answer some deep security questions and address the fact that open source code is now critical infrastructure out there? It’s not just a nice, optional nice-to-have. It’s like major parts of society, perhaps every part of society, runs on top of software and open source software is a quarter of that. So it’s worth asking, what are things we can do to systematically improve the state of security across the entirety of the open source landscape?
And so a bunch of organizations came together and started working. And individuals, really volunteers, started to sort themselves into different working groups, some focused on education, some focused on the supply chain, some focused on tooling and how vulnerability disclosures happen inside the community. They formed a bunch of working groups, formed a bunch of projects outta those working groups, and realized that they’ve got something here that really has some legs. And so in October, we pulled together a set of organizations to provide some funding to go and empower these different working groups and projects and fund them to build new tooling, to build more educational resources, and really go help the rest of the open source community answer, what with Log4j in December and with so many other instances. Incidents are clearly an important thing to address.
Shimel: Absolutely. Brian, look, I’m a big believer in the OSSF. I’m glad that it has come together and it’s gaining the kinda momentum that it has. I think with the primacy of open source, let’s call it, with open source being just such a powerhouse in terms of the software and software development, we need something like the Open Source Security Foundation to make sure that the open source is secure, that there are best practices, that there is oversight, that there is everything that you guys do it, it’s gotta be part of the job. So really happy to see your success over the last two years.
You guys recently announced a project. I think was called the Alpha-Omega Project. Look, even a Jewish boy like me knows the alpha and the omega, the beginning and the end. Well, I did go to St. John’s, so I have an excuse. But anyway, talk to us. What is the Alpha-Omega Project?
Behlendorf: Well, the Alpha-Omega Project started as a white paper exploring, what are some of the most critical needs that go unmet out there in the open source landscape? And there’s kind of a recognition that there’s different needs from different ends of the spectrum, from the well-resourced and very well-organized open source projects like, say, the Python Foundation or Node.js community or the Apache Software Foundation or many of the projects at The Linux Foundation. Those you don’t want necessarily. Perhaps the use of the word “alpha” is controversial. But these are projects and have a very big footprint, as large organizations. But some of them don’t have well-resourced security teams. Some of them haven’t yet adopted some of the best practices and standards that are out there for how to differentiate well-run open source projects. Some of them could use a little bit of help.
And so the alpha side of the Alpha-Omega Project is, try to identify ways to help the 100 or 200 top open source initiatives, projects, foundations, however you wanna think about it, with essentially consulting, advisory work that then might lead to, well, here’s an opportunity to spend some funds to go and make a step function improvement for that organization. And it might be as simple as having a full-time person working on their security team to help triage reports that come in and manage a disclosure process. It might be, “Here’s a critical piece no one’s on. We don’t have the resources or volunteers to do a third-party audit on. So let’s provide some funding focused on that.”
And then the other end of the spectrum, say the top 10,000 open source projects, these are any components that are in kind of any degree of moderate use or above, what are some ways that we might systematically scan those projects and look for things that are worrisome, things that might be like, “All right. Here’s the bug in Log4j. It had to do with taking unparsed input and trying to parse it for format or, sorry, unvalidated input, parse it for format strings, and then feed that to a parser.
That’s kind of an anti-pattern. That’s kind of a problem. And it’s really hard to make that secure. How many other open source projects do that same kind of thing? And can we use tooling to systematically see, are there additional Log4Js out there,” based on that or based on others. So it would use all the standard tools out there, CodeQL or other scanning tools. But it would also engage the open source community in trying to figure out, what are the better questions to ask of this kind of infrastructure once you have a scanning infrastructure like that set up? And then how do we work with maintainers to, if we find problematic scenarios, get them fixed? Think of this like an open source Project Zero, if you well.
And so this span was put forward in a white paper by Michael Scovetta at Microsoft. And Microsoft and Google really started to rally around it. We’ve raised $5 million now to go and start to put this together. It’s a very human-intensive process. And so we’ve put out the first three job descriptions for individuals we need to hire to help us manifest this work. And so we’ve got those job descriptions up. And if any of you in the open source space who have a cybersecurity background are interested, please take a look at those open jobs. But it’s a long-term kinda bold initiative to try to provide the same safety for open source projects that one might expect other companies to do for their own proprietary products.
Shimel: So I gotta ask the question ’cause you brought it up. So where do they go to look?
Behlendorf: OpenSSF.org. We’ve got the jobs posted there, as well as at The Linux Foundation website, of course.
Shimel: Fantastic. This is a bold initiative, Brian, right? It’s Alpha-Omega. But what I like about it, though, is though the big guys, if you will, and it’s the same thing in many of the foundations today, rightfully so. These big, mega projects that have a billion-plus downloads and more, they get a lotta the attention. And they should, ’cause if you have a security problem in one of them, we all have a security problem. But what’s nice about this is that you’re taking the lessons from those big guys and the processes developed from those big projects and making them available to some of the smaller projects.
And some of them may grow up to be big projects. Some may not. Some may stay what they are. And that’s okay. But they’re all entitled to be, and we deserve to have them all secured as best as possible.
Behlendorf: Absolutely. Looking at the long tail of open source projects and how to help them upgrade and how to help them be more secure by default is a really big focus for us. One of the illustrations of this is we funded some research with Harvard that came out two weeks ago called the open source census. Actually, this is the second edition of that, so it’s called the Census II. That was published out there. And it gives a whole lot of basically top 50 lists of projects in the open source space that are deemed critical, actually, that, and critical by different criteria, critical to based on usage that we get from data that comes from some of the SDA vendors out there, to try to really understand what pieces depend upon what. ‘Cause we wanna find the next Log4j. We wanna find the next component everybody relies upon and everyone’s kind of taken for granted, and really help make sure that we’re focusing attention and resources on those unsung heroes of open source.
Now, in that 10,000, there’s gonna be a lot of these others, and we’re gonna need to continue to do more work, more research, more outreach to figure out where those other dependencies might be that could be problematic down the road. One of the interesting things that the census turned up, though, was there is a really big distinction between some of the different ecosystems out there. In the NPM ecosystem, for example, in the Node ecosystem, there’s a very big tendency towards single-developer projects where each module is like a hundred lines of code and written by one person. And that, to me, represents a risk. Because if it’s one person attached to that code, that person disappears, gets hit by a bus as we say, the bus factor on that project is pretty low. That could be a problem.
So one thing we’re trying to also ask is, what are some other signals that we might use to try to determine when a critical project is at risk? What are ways that we could suggest that’d be helpful? What might happen if you took five of those projects and suggest the five developers work together on kind of a single module that had those five different pieces together and then reduce the bus factor of that aggregate kinda whole? So lots of these interesting kinda conversations going on inside the OpenSSF about ways that we can be helpful to both the alpha projects and the long tail and really thinking hard about the kind of open source community that we’ve arrived at over the last couple years.
Shimel: Love it. Good stuff. Brian, I’m a fan. I love the progress you guys are making in a short time. So hearing these kinds of things makes me feel good. I wanna pivot, if we can, a little bit and talk about kinda upcoming OSSF opportunities or shows and so forth, where you’ll be at and events you’re putting on. June’s a big month. There’s a big Linux Foundation event, what was it, June 20 to 22?
Behlendorf: Yeah. So the week of June 20 to 24 in Austin is a basically framed by the Open Source Summit, which is the main Linux Foundation event for all of its different communities. During that summit, there’s a track called SupplyChainSecurityCon, which will be focused on all the different issues that come up in the types of work that we do. And there’s the CFP for that just closed and we have a bumper crop of submissions that we’re working through now, so we’ll get the schedule for that published pretty soon. But there’s lotsa reasons to come to Austin in that week.
There’s also, the beginning of that week, an OpenSSF day where we’ll pull together the leaders of our different communities under OpenSSF, talk about the projects going on, talk about where things might head. Anybody who wants to get more involved or wants to just know more about what we’re doing, please come to that event. There’ll be some webcasting from that, too, some streaming. But this is also perhaps the first chance in two years for this community to really meet face-to-face. And so we plan to take advantage of that.
And then there’s another event at the tail end of that week, one called the critical software summit, which will be all about, what are the issues involved now that the software is essentially the roads and bridges of modern infrastructure? So stick around for that that week, at the end of that week, on the Friday, as well as the Global Software Vulnerability Summit, which will be focused on, how do we find bugs, get them fixed, and get them distributed, and all those kinds of issues that come up. And so that’s been announced. And the CFP is still open for that. And that’ll be on Friday, as well. So that week in Austin. Come if you can.
There’ll be other things going on soon, too, now that conferences are starting to pick up, people are starting to travel again. So, and we’ve still got a heavy list, a heavy kinda focus on webinars and another kinda virtual events and outreach. And of course our community is wide open. So anybody anywhere globally, we want you all involved in the working groups and conversations. Or even just show up and ask questions. We really know we’ve got an educational and community-building task to do ahead of us. So really, everyone is welcome.
Shimel: No kidding. Hey, that’s the week, it’s The Linux Foundation, what’s the name of the whole open source…
Behlendorf: The Open Source Summit.
Shimel: Just the Open Source Summit?
Behlendorf: Yeah. We do one of these in America, and one in Europe each year, and one in Japan when we can, and had been doing one in China. Obviously, we all hope to get back to that at some point soon.
Shimel: Let’s hope so. And it’s the week of June 20. And if I’m from years, this is before COVID. I’m assuming it’s gonna be the same. Is one ticket is for the whole week, you don’t need to get a special thing for open source security day or supply chain day or…
Behlendorf: There are some side effects in this, but all those events I just mentioned are all one pass, one ticket to the whole thing.
Shimel: Love it. I’m gonna look into it. We need to have a Techstrong presence there. Maybe we’ll do some broadcasting from there.
Behlendorf: We’d love to have you there.
Shimel: If so, yeah, we’ll see you in-person there. Different background, but we’d love to have you. All right. Brian, we’re about outta time. We’re probably over time but what the heck. Anything else on OSSF you wanna keep the audience up-to-date with?
Behlendorf: It’s just the best kind of circus on the planet. There’s lots of things happening. If you’re deeply technical, good stuff happening in project sigstore and Salsa and other places. We’d love to have you participating. If you wanna focus on education and other kinda guides and things, lots that we could involve you in there. So just come to the website, openSSF.org, and raise your hand, and we’ll put you to work or help you be smarter.
Shimel: Brian, thanks so much for keeping us posted, man. Keep up the great work. Continued success with Open Source Security Foundation, OSSF.
Behlendorf: Thank you, Alan. Thank you, Alan. Take care.
Shimel: Brian Behlendorf with the OSSF here on Techstrong TV. We’re gonna take a break. We’ll be right back.
