OpenSSF is excited to announce the Alpha-Omega Project to improve the security posture of open source software (OSS) through direct engagement of software security experts and automated security testing. Microsoft and Google are supporting the Alpha-Omega Project with an initial investment of $5 million. The video is below followed by a transcript of the conversation.
Alan Shimel: Hey, everyone. Welcome to another segment for Techstrong TV. My guest today is Brian Behlendorf. Brian is with the Open Source Security Foundation – that’s the OSSF. The Open Source Security Foundation, of course, is part of the Linux Foundation and it was – it’s a relatively new organization. It was – was it announced at KubeCon – CNCFCon back in, I guess, September, was that, Brian?
Brian Behlendorf: We announced kind of the second generation of the project in October. The project has been around for about a year longer than that – actually just over that as a collaboration between some things that Microsoft had started and Google had started. The Linux Foundation said, “Let’s put this in the same pod” and a tremendous community of volunteers stepped up to do all sorts of things and get plates spinning on top of poles. And then, around about October we realized, hey, there’s some places where spending some money would be helpful and here’s a whole bunch of companies willing to come in as sponsors and really fund some of that work. And so, that also freed me up to be able to focus full time on it as well.
Alan Shimel: Absolutely. And we’re going to get into what those companies are and what you’re doing in a moment, but I really kind of short-armed you on my introduction because we jumped right into OpenSSF. Brian, why don’t you tell people, what’s your position with the OpenSSF and maybe a little bit about yourself?
Brian Behlendorf: Sure. So, I’m General Manager for OpenSSF. At the Linux Foundation where a whole bunch of these different kinds of projects and – typically we pull together a small staff around some of the major ones like the Cloud Native Computer Foundation, like Hyperledger, like the Automotive Grade Linux. I mean, so many here. And so, my role is to help kind of make sure that the community is developing things within the scope of what it’s charter is, that we’re making sure everybody who shows up to help, to volunteer, to – with an idea, with something they want to do has a place to land that and be supported to that, and then connected to the set of sponsors that are providing the funding to be able to go and not only have a staff to help build the community but also get the word out about what we’re doing. Also, put together projects like some of the ones that we’ve announced recently, like Alpha-Omega, another one called sigstore, and provide some resources to help those projects really take off.
Alan Shimel: Excellent. All right. Brian, before your position with OpenSSF, what kind of was your – what’s your background?
Brian Behlendorf: So, I’ve been with the Linux Foundation for just about six years now. I joined in 2016 to perform the same kind of role for another initiative called Hyperledger, which is in the Blockchain technology space, kind of at the other end of the spectrum from all the cryptocurrency and NFT kind of craziness. But that’s been a great run. That project is still thriving and has – and I passed the baton on that successfully.
Before that, I’ve done a number of different things. I was Chief Technology Officer for the World Economic Forum for a few years. I worked in the Obama administration in the Office of Science Technology Policy. I started a couple of companies. I was an early employee at Wired Magazine. I cofounded the Apache Software Foundation and have been on the boards of the Electronic Frontier Foundation and the Mozilla Foundation for over ten years.
Alan Shimel: That’s great. Some impressive wins there and impressive experiences. What a great person. What a great asset for the Linux Foundation. Brian, you know, for some folks in our audience this may be their very first exposure to OSSF, so why – maybe we should start with the – what’s the charter, or what’s the mission of OpenSSF?
Brian Behlendorf: Yeah. Well, we’re really focused on how do we raise the baseline of security across the open source ecosystem, recognizing that open source is embedded entirely inside – very widely inside of even proprietarily licensed software out there, cloud services and every phone, Android and iOS, inside of consumer products and cars and everything like that. Even when the software is kind of a proprietary kind of end stage, there’s so much open source software included inside of that, that really addressing the security of the entire software ecosystem depends upon increasing that in the open source space.
And in particular, we think – you know, open source was kind of developed at a time when we had a really high-trust environment. I could make a decision about whether to use OpenBSD or FreeBSD based partly on features but also partly on who were the leaders behind those projects and how seriously did they take security or networking protocols or the like, and what were their policies about when somebody could accept a pull request, could accept a patch?
So, that doesn’t work anymore in a world where you’ve got thousands of components that get pulled in in a modern NPM-based kind of system or simply just the proliferation of choices. Which fork of a popular package do you want to use? Well, all of those will have different approaches to security around them. And what has emerged over the last few years has been a set of standards and best practices and tooling and such to really help raise that floor. And so, the OpenSSF is here to try to organize those into one kind of consistent picture, to support everything from best practice guides or training for developers on better security work to standards like Salsa or Project sigstore, or the further promotion of SPDX as an SBOM standard – apologies for all the acronyms. Happy to explain any of them if you’re interested. And then, some software as well. Project sigstore, for example, is a collection of software for signing of releases using short-lived keys, much like Let’s Encrypt, for promoting the adoption of TLS across the Web. So, all of that is kind of under one roof and it’s about hardening the software supply chain at the end of the day.
Alan Shimel: Hey, and of course software supply chain and software bill of materials is on kind of the top of everyone’s mind this year. But you know, Marty, as I – excuse me. Marty? Brian. I don’t know why I said Marty. I said Marty earlier. Brian, as I sit here and I look back, so I’ve been – I think I told you off camera I’ve been involved in the security space 20-plus years, 25 years. And when I first got involved, when we talked about open source security there were kind of two forks. There was open source security tools like a Snort or Anessis or ClamAV, these kinds of things, where these were actually security tools that security pros used that were open source. And they were some of the best. They were on par or better than many of the commercial tools.
And then there was securing open source software. And back then – I mean, we’re probably contemporary ages and stuff like that, so you know – back then the prevalent theme was open source software had a lot more eyes on it because the source code was open to everyone, so it – inherently somehow it was more secure. And some people bought into that. A lot of enterprises didn’t because, well, open source didn’t come with support, it didn’t come necessarily with training, and there was always this security bugaboo hanging in the background. “Well, I don’t buy into the more eyes on the code argument.”
And so, it was hard. Open source software back then was getting snuck in the back door, if you will, of enterprises. But we fast forward to today and 90, 95 percent, I bet, of enterprises are using open source software one way or another. So, the idea that we’re not going to use open source, that’s done. The idea of how do we secure our open source, though, is still marred in controversy or not clarity. It’s not clarified because, number one, I don’t think most people understand what are the open source components that make up a lot of the applications that they’re using or software they’re using that can – has open source in it. And then, number two, even for the ones who are using – are fully aware of open source projects and software that they’re using in their network, they’re not really clear how to secure it. I think just the way they depend on the community for the software, a lot of them are depending on the community for the security of that software. And I guess that’s your mission, right?
Brian Behlendorf: Yeah. The comparison to the old days is a really fun one to make. I mean, one of the reasons why the Apache’s Web server project got started in early ’95 was we were – all of us were users of the NCSA web server and there was a security report that had come out about a way to bypass authentication, that because NCSA had lost their developers to Netscape, this new company at the time called Netscape, no one was home to issue an update. And so, a bunch of us said, “Well, maybe we should kind of self-organize as users of the software to go and fix that bug and then pull in these other patches that we had been trading around like baseball cards” – that was the origin of the name “the Apache web server,” or Apache server.
Alan Shimel: Okay.
Brian Behlendorf: And that, to me, represents really what’s different here compared to the proprietary software world, is it’s kind of like when people criticize the Wikipedia for having inaccuracies. Well, the Wikipedia, it might not be perfect but it’s perfectable. And likewise, open source software might not be perfect – in fact, I can guarantee you there’s a bug in every piece of software out there. The last bug is fixed when the last user has passed away. But it’s improvable. It’s – this is something that we need to think about as we – what are the approaches to improving that baseline of security is – but the virtue of it being transparent, the virtue of being able to fork and add improvements and that sort of thing is really a key part of the approaches that we should take.
And then, it’s really about asking “Is there a community of people around a given piece of software who prioritize the security of it and recognize their role now that this stuff is critical infrastructure?” Now that it’s highways and bridges, now that it’s – society – parts of society could go down if certain things were taken down, especially given nation-state actors’ participation in cyber attacks these days. And so, what is the obligation that not so much an individual open source developer, because open source developers have lots of motivations for submitting pull requests, for being a maintainer, but really of the organizations in this space that have formed around open source. The named communities. The ones at the Linux Foundation, for sure, but also groups like the Python Software Foundation or the Apache Software Foundation or the Free Software Foundation. What obligation do they have arguably to their downstream customers, so to speak, to adopt some practices or to at least telegraph “Here’s the amount of vetting that we do. Here’s the amount of attention that we pay. Here’s the last time we did a third-party audit of the code.”
You could even start to venture into places like – back in our time you’d get to know that Theo de Raadt on OpenBSD kind of took security seriously. He was kind of a jerk about it but he took security seriously and he attracted people around him who did. And so, I’m comfortable using OpenBSD for my border routers and other high-security kind of spaces, even if it had fewer features. You can’t do that these days with the thousands of programs available. So, are there other ways to do things, to add data to be able to manage the fact that we’ve been incorporating all these dependencies?
So, things like – you’re probably familiar with the – well, it used to be called the Core Infrastructure Initiatives Best Practices Badge. It’s not been branded the OpenSSF Best Practices Badge. This is a set of questions to open source projects and the foundations about how you run your projects. Do you have a security team? Do you have a process for responding when somebody reports a vulnerability to you? And lots of projects now display that badge or their percent of the way towards completing getting that badge, which is how many of the items on the checklist did they knock off? We have another thing at OpenSSF that builds upon that called Security Scorecards, which is a more automated tool to ask “Are you doing things like updating your dependencies?” which would have avoided the whole faker.js, colors.js kind of thing that happened last month, to try to respond to the fact that we live in a world where people are updating their dependencies without doing a test and pushing these things to production. Maybe that’s not a practice y’all want to really do.
So, those are just a couple of the things that we’re doing at OpenSSF to try to answer the question: How do you get a better sense for the risk posture of a given piece of open source software? What are ways to improve that baseline? And then, what are ways to be able to, in aggregate, nudge developers, also companies towards choosing packages with better security postures, and creating incentives for developers to follow some of these things, rather than “Here’s a 300-page ‘Thou shalt’ kind of document that will tell you what to do.” I think that’s the approach that we’ve all got to take to improve that baseline.
Alan Shimel: Great. Love it. All right. Let’s pivot a little bit if it’s okay with you, Brian. You mentioned the sponsors, and some of the sponsors have now kicked in monetarily, which has enabled OSSF to do a bunch of stuff. But let’s call out some of the leading sponsors and let’s talk specifically about what that money has enabled. What’s happening? What’s news around it? And there’s a lot on there but I’m going to let you cherry pick what you want to highlight.
Brian Behlendorf: [Laughs] Well, if you go to OpenSSF.org, you’ll see our members roster there. We’ve got members who participate at a premier level who are part of our governing board and approve the budget I submit to them and how we spend their funds and really help set kind of the strategic direction. And then, a body of general members who are here to lend their support, lend their – obviously contribute some funds as well. And then, some really key partners as associate members. And what’s fascinating is how companies like Google and Microsoft and Facebook, who also participated, are really competitive with each other but none of them have a competitive interest in security. Security is a baseline. When there’s a problem out there, when there’s a new hole discovered in an open source package, it affects everyone.
And so, this is one of the easiest places in all of the Linux Foundation I can think of to make the case there really is shared – a shared pain that comes from not solving this problem earlier. And so, their work has enabled a bunch of our communities that have been very much driven the way the best of open source communities run, which is through public participation, public ideas. There’s a tremendous amount of ideas coming out from that that we can’t take credit for having instigated, but what we’re there to do is to provide them support for – all right, so we’re running Project sigstore. Well, let’s think about what does it take to actually support the service side of that, because just like Let’s Encrypt there’s a services side, not just provision of open source software to consume. So, how do we make sure that that is a service that can always stay up so that developers can always sign their packages?
So, that’s one kind of thing we do. We’ve also looked at and have started to fund third-party audits for some of the software that’s either in OpenSSF or that’s peripheral to it. More on that will be updated soon. We launched this thing yesterday called Alpha-Omega, which is about building a course that software experts will go and be able to engage with open source projects and help them understand how to adopt different security practices and policies, and when they need help with a third-party audit, when they need help thinking about threat modeling, to actually be there and help deliver that.
So, all sorts of things going on on this front. But it’s also been great to see many of our members start to pick up on the technologies party because we’ve had this high-level engagement. So, for example, the NPM – as I mentioned, the NPM maintainers have picked up – are now required to use, or will soon be required to use third-party – sorry, second-factor auth to be able to authenticate themselves to update their packages, which is a pretty important thing to do in trying to avoid one attack scenario, which is compromised credentials on key infrastructure. How the software gets distributed out to end users is this blind spot I think a lot of us have as a weakness. And so, it’s great to see GitHub make a number of security-focused changes, Microsoft, and other tooling space has started to do that. Google for sure. Google committed $100 million to improving the state of open source software security. We haven’t seen all of that money yet [laughs]. We’ve seen a fraction of it. But they have done a number of programs to improve that out there.
And so – but also, there’s some folks who are quiet about it. So, Fidelity and Citibank and JP Morgan are huge consumers of open source software. They’ve started to be more public about that fact. They’ve started to contribute open source software back upstream. And they want to know – I mean, they have a keen interest when there’s a new log for j-style vulnerability. “How quickly can we update our systems and how quickly can we get back to a point where we’re not threatened by this?” That’s driven their participation in the program and even their involvement in some of the key underlying programs that we have.
And so, really we’re here to try to synthesize all of these interests into what’s the greatest common denominator of everyone’s agendas, and can we get resourced to work against those?
Alan Shimel: Cool. Hey, Brian, we’re running low on time but I wanted to just also mention – I know Linux Foundation is planning a lot of events this coming year, both virtual as well as in-person. Let’s keep our fingers crossed. Any plans for OpenSSF participation in any of them? Or maybe an OpenSSF?
Brian Behlendorf: Yes. In fact, there – coming up in June the Linux Foundation is hosting its yearly open source summit event in Austin. The Open Source Security Foundation will be there in the form of a side conference called Supply Chain Security Con. This first debuted at KubeCon last year and had tremendous support. Now we want to make sure that’s opened up to the broadest part of the open source ecosystem. So, we’d love to see folks there in Austin – well, there will be a virtual side to that participation as well for those who won’t be able to travel. But we’re really looking forward to that. And putting together plans to have presences at other major events and make sure that the folks who are working on important stuff in our community are being well represented basically everywhere software is being talked about. So… But Austin in June, we’d love to see folks there.
Alan Shimel: Great. Brian, I know you mentioned the website earlier, but would you mind repeating it again for folks who maybe didn’t catch it?
Brian Behlendorf: OpenSSF.org. O-R-G.
Alan Shimel: Got it. Hey, Brian, good luck. Best of luck with the OpenSSF. We’re excited. We’re fans here of it. Anything we can do, always reach out. And keep up the great work. Thank you very much.
Brian Behlendorf: Thank you, Alan.
Alan Shimel: All right. Brian Behlendorf, General Manager, OpenSSF, part of the Linus Foundation. That’s OpenSSF.org. We’ll take a break here on Techstrong TV and we’re going to be right back.