 Hi, this is your host Abhinav Bhartiya and we are here at open source summit in Dublin And we have with us once again Van Beldorf a general manager of open source security foundation Brian is great to see you in person after a long time. Yeah, it's great to see you again. Yeah And you are here at the event now when we talked about we've been talking about open source for a very long time Now we're talking about security as well We just kind of a change from the in early days There are a lot of kind of misconception around that first of all open source and security You know if you're open source, but that is not the case open source does not mean security by default I will talk about all those topics as well, but I also want to talk since you're here at the event What kind of environment you are seeing here when you talk to people how much awareness understanding is already there about security? Well a lot has changed. I think since December when the log4j breach The log4j shell compromise as it's called suddenly woke a lot of people up to to a need to be more proactive in this space I actually say, you know open-source software has had a pretty good reputation for security in the early days There are a lot of people building things, you know, including us on the web server project at Apache and others who took security very seriously We would be very diligent. We'd respond quickly when someone found holes and we approach things as a team Right, you know if one of us peeled away others needed to be able to step in to fix bugs and respond to concerns and that kind of thing But the open-source world has changed quite a bit since the early 90s, right? Goes without saying but there's an awful lot of open-source code with just one developer behind it these days And that person can feel overburdened and and not have the resources to be able to Think about long term. How do I make the code? How do I protect my end users? How do I respond to it to a crisis? And then you know the amount of scale, you know When you're building an application today the number of dependencies that you have might be in the thousands Whereas early days with like the web server We had maybe a dozen different libraries or APIs we call that kind of thing And so it's so much harder these days to build secure applications and to some degree that good reputation that open-source has had It was deserved by some projects like the Linux kernel But others didn't really necessarily deserve to have is kind of an irrational exuberance around that And I think that's what led a bit to this surprise that happened with the log for J breach Which frankly should not have caused caught us by so much by surprise I think had we understood both the criticality of log for J in You know it's ubiquity out there in Java enterprise deployments, but also the fact it was kind of under resourced And they had these these features that the core development team didn't really know much about that ended up being exploited to cause that bug You know if we had had greater awareness We might have been able to catch that and so all of this has served as a real galvanizing force for the open SSF Which it was formed to try to address not to write the silver bullet, you know that would solve every open-source security problem, but instead to have a mix of software and specifications and Education and maybe even some services that would go and try to systematically up-level how the open-source community writes code from a security point of view to help both the the alpha side of the Projects, you know that the ones that are pretty well resourced and run and just help them be better But also all of those small single-person projects How do we how do we help everybody across the ecosystem? And so happy to talk more about that but once again very well said and Well in early days also we see software what I mean you give example of Apache But the beauty of open-source projects was a company was that the patch will be released You know as soon as it was you know, it was up to the you know players and vendors to actually implement the Google Struggle a lot, you know the patches were there but folk will not be implementing it even the facts We have seen the patches were there, but it was not applied there So I also want to understand a talk a bit about the the ground reality where open-source projects are really good at Fixing things, but those fix don't get into the end product that you and I use at you know home organizations So how important is that problem and also that also become the problem the whole supply chain to make it easier for folks Because first of all security is not an afterthought anymore But if you look at the complexity of today's stack as we talk in a lamp stack of old days But persist today's stack it is very complicated. We don't have a skilled people So so if you look at the foundation, how do you kind of also make it easy for it so that you know The security is not a roadblocker for them. They're like, you know the patch is there and let's just roll it So there's there's three problems In fact, we had a conversation with the National Security Council in January as part of the aftermath of the log for J Breach, you know, they they came and asked us along with Apache and ten other companies in this meeting that we had with Folks from the from a couple of different government agencies Who kind of very kindly asked, you know, is this is this the new normal for open-source where we get these kind of disruptive kind of changes And and we said it shouldn't be the new normal. We'd like to kind of fix things We talked for six hours and coming out of that was a commitment by those organizations in the room Including the government to have to help help us with this to address Three big problematic areas the the first is how do you make the writing of open-source code more secure from the beginning, right? The second is how do you more quickly discover vulnerabilities and get those vulnerabilities fixed, right? The third is how do you accelerate the deployment of those vulnerabilities out into the marketplace out into adoption by Organizations and and have the pull not just the push right not just platform vendors deciding when to push fixes up But have the end user organizations doing pull so on each of these three fronts The open SSF has a number of initiatives, right on the first trying to make software development more secure This is where educational and training materials that we've developed here are intended to really help uplift everybody working in open-source code And we have this training course that has about 20 hours of content not a lot You know it's just enough to help that covers most of the ways in which these you know severe vulnerabilities are Breach basically when developers forget forget to treat user contributed input as hostile You know or worse try to parse it for format strings Like there's there's these patterns that you see as somebody who's been through several of these You know that if you can just teach those patterns to every software developer open source or not you'll end up with higher quality code Right other things that we're doing to try to make the development of code more secure from the beginning include Looking at the software supply chain and going how do I have greater integrity checks across as I'm pulling these dependencies together as I'm pulling that npm module for example How do I know that that npm module the is actually Related to the source code that it claims to be that's sitting in the github repo, right? How do I know that this object hasn't been corrupted on its way from the developers to me? So that's where source code projects like sigstore and the guidance that we provided to npm developers around how to Do secure packaging for example all sorts of things that we're hoping have a positive impact on that front I should also mention we have another initiative called alpha omega that has been distributing grants to major open source organizations like the python saft software foundation and we just announced to the rust foundation To help secure not the code that they've written But the processes and the infrastructure that they use to coordinate their activities and to resource a security team as well to help Those kinds of projects More systematically build better code and respond quickly. So that's that's that first goal the second goal Which is about how do we find bugs quicker? We have again another part of this alpha mega initiative is a scanning platform for looking at the top 10,000 projects and understanding, you know, here's the bug and log for Jay that was caused by Parsing of user contributed input for format strings. Who else out there is doing that kind of thing for example And if you get a set of here's 50 projects that do that how many of them do that in securely You start to invest some human effort to whittle that down and you know, you're likely to find some new zero days So think of it like Google's project zero, but for open source code, right? So so that's one of a number of things that we're doing to try to help make the discovery of code and the fixing of that code faster We're also funding a lot of third-party audits of open source code And when you do that, you also need to fund the the fixing of the bugs that you find because you can't just go to a development team And say hey your fly is down, you know, you've got you know, these problems You have to fix it because they'll just like react very negatively to that the third thing is the hardest thing How do we get companies to upgrade more frequently, right? Which gets back to your original question and and you know open source has kind of limited impact on that because you know There's organizations like red hat and every open source vendor who act as kind of the plat bit of packages for the last mile So to speak and they they try to provide guarantees around quality and updates and they offer update streams If the if the end user community picks them up But there's a whole lot of open source code that is just pulled off of github and then put directly into end user Organizations and people forget that open source is open like beer free beer. It's open like free speech But it's it's also free isn't puppy, right? You'd have to take some care and feeding if you're going to pull directly from the the upstream source, right? And that's where a bit of education for end users on how to evaluate What is one of the more secure projects out there is pretty important and we published a concise guide to evaluating open source code we're also looking at the development of an a to a Basically a website a dashboard that lets you see what are all the risk factors involved in Understanding the trustworthiness and the likelihood of a severe defect existing in this package of software or code coming from this community And that that initiative would build on top of the scorecards work that we're doing and all these other kind of automated tools to try To get these this objective set of metrics some of them even based on things like the chaos tools for understanding community dynamics Is there just one developer behind this or is there actually a group? So that third piece what we hope is simply to make the end user world a lot smarter about how they write code About how they consume open source code My hope is that it also encourages them to take much more of a patch often patch frequently kind of kind of perspective on things update frequently and That we can move the community to a more more solid basis a final piece of that is a lot of the emphasis That's gone into the software bill of materials world s-bombs by the US government by the health care sector by lots of industries They're now starting to realize we need to know what are the ingredients inside this bottle of ketchup so that when you tell me You know, there's a there's a breach and a major component of this I know where I'm affected that was one of the biggest costs of the log for J breach is very few people had a very Few organizations had a better way to tell like am I affected by this then LS-LR pipe to grep, you know looking for the log for J jar or something like that Which if it's embedded inside of another jar might be really hard, right? So that was a big part of the scramble just knowing if they're affected There's some and so s-bombs are a way to try to address that and we think there should be s-bombs everywhere That it should become like an install dot txt in a standard Distributed software distribution and and that you can aggregate these things together and help Organizations understand if they're affected by vulnerabilities new vulnerabilities within moments of them being announced excellent So thanks for explaining three aspect one initially you're talking about There are some projects which are underfunded and Linux Foundation, you know initially they funded a lot of project They're only one guy running it There's still a lot of projects and the problem with open so not any software code But especially with open source because when you go to propriety, there's but big vendor shipping the whole monolith with open source There's small components. We are using so how big you see is the challenge of like there may be a project that a lot of folks Are using but it's just maintained by one guy who is working at night time and so this is a big problem And they say the scope is so massive. How do you look at it? That is easiest problem And what Linux Foundation is doing or can do to kind of meet you not mitigate essentially But also I mean you cannot fund all the projects in the world, right? I wish you folks can but you cannot people understand, you know The Linux Foundation is not a big we're not like the MacArthur Foundation or the Ford Foundation We don't have this big endowment that we're just you know trying to pick in and direct funds to open source projects Everything that happens at the Linux Foundation. It happens because we've found a set of stakeholders Whether it's around cloud technologies or enterprise blockchain or security or whatever and those set of stakeholders fund just enough of a program management office frankly to oversee and harmonize and Coordinate but in most cases not to write the code, right? Not to do the security work not to not to do some of the hard things that need to be done to make open source projects Actually useful, but to do the meta work the stuff that enables the the smart developers and the companies to come in and Contribute and pool their things and most constructively create something right and so I think whenever you have an interesting domain You should have that set of stakeholders around that domain who are helping fund all that meta kind of work now That could include things like the third-party audits of open source code There's a whole lot of communities at the Linux Foundation who say, you know It's worth the fifty thousand dollars or a hundred thousand dollars to go and audit this component The cloud native compute foundation does that quite a bit with it's more more substantial more important things It's also an appropriate place to start to set standards, you know to say hey Maybe every maintainer should be somebody who's taken that secure software development course, right? Or maybe there's other practices and policies, you know things like filling out the best practices badge application, you know right to to make sure you've got a security team and you've got the good practices for handling a Bug that's been reported that is has security implications. So there is a lot of role for I think foundations to play in leading to more trustworthy code They go beyond simply having a brand name having a dot org website having a 501 c3 you know and and some of the projects out there like again Python and Rust and The Eclipse Foundation Are starting to realize that they need to take a very active role in enhancing the security offerings of the stuff that come in Through their communities and of course with the Linux Foundation We've got projects like the Kernel project, which are very well financed But others that aren't so much and so that this is a conversation that foundations will have to have that relate very much To the trust in the reputation of the brand name, you know things like Apache Log for J was trusted because it had the Apache name behind it, right Apache doesn't always third-party audit things I don't know that Apache's ever paid for third in an independent third-party audit now those happen Sometimes the community does though, you know resources those kinds of audits But there is no requirement no mandate for that to happen Likewise with other other projects now scaling down all the way to that one person 300 line piece of code npm module if I were the developer of that I would I would be I probably wrote it very quickly on my way to solving some problem threw it over the fence and said Here the world can use it if they find some value But that's that's different than taking pride in your work and realizing that if there's a million users of this They have an obligation to you because they're using it for free and you should they that some subset of them should recognize Hey, they should be Participate in its care and feeding and be a part of it But there's some obligation on you as the developer as well to open that door and say I really want other Co-contributors I want people who can help me build this and make this better And people who will answer a bug if I'm on vacation, right or answer a security issue if You know I'm on vacation or I simply want to hand this off to other people so I can move on to other things And that might mean that's one 300 line module on its own is kind of a risk to people using it But maybe if I partner with a couple of other folks who are working on Complementary technologies and I make this a library of code and we all kind of look out for each other and work together on this Larger thing then that is ultimately more stable for the rest of the community And that's why I think things like the chaos metrics around the health of a community are actually a very reasonable thing to look for And trying to judge the risk of using a piece of code or not And I might prefer to use the thing that has three people around it than the thing that has one person around it No, you kind of you know this has been a big problem in office or sometime talk to us most of time people say Hey, you know I did it on that if you want to use it use it if you don't want to use it You know, I don't care but the obdiction part that is really important But the problem in most of these offices that also we are mostly introvert also We don't know how to interact with it so it kind of become working with somebody it can feel daunting I think this is where I'll give credit to a lot of open-source foundations that prioritize Community development in some cases community development over code right in fact that was explicitly part of a patches principle is community over code Like it almost if you don't get the community dynamics, right? If you don't build a multi stakeholder a multi developer kind of thing around a collection of code You are kind of running at risk, right? You're doing a disservice potentially to your users out there, and so yeah That's part of what I think has changed a little bit about the open-source landscape and some ecosystems have this worse than others But I think it's why the end user community should try to prioritize looking for those foundations and looking for these other signals That indicate I'd rather use this other code here because you know, even if it has fewer features It has more of this safety around it that comes from the the community dynamics and and the investments people make into security One more question is that you know as the the consumption or usage of open-source is no more and more Commercialized in a way that commercial companies are using it and a lot of companies are releasing their code Which and sometimes when they release a code sometimes they try to put it in the foundation And that's where they try to focus more on building a community around it versus a one-person's code Do you think that will over a feeder of time in Improve the security posture of these projects also or how much you're seeing that code is coming is still from individuals Where says, you know, well, I first of all, I think there's this unfortunate dichotomy that's created between individual developers and big corporations as if they are in opposition to each other and in most cases the individuals I know working on open-source projects are employed by companies with a stake in the success of that project, right? directly or indirectly because And I think we need to move away from this kind of contentious Dynamic and and assume that that you know, people can't Represent their employers when they're on these projects and instead have this understanding of open-source projects as an amalgamation of the interest of all of its end users and contributors and We should be encouraging more companies to get involved I do think also sometimes companies view contributions of IP as the important thing when really It's not as important as the contribution of in of individual time, right? Software is not an asset like a bar of gold software is an asset more like a head of lettuce Where, you know, it's good for a little while But then it starts to decay and it needs to be refreshed and much more important is built capacity building of the community around Whatever problem you're trying to solve So they're there to do a 2.0 and a 3.0 and a 3.1 and to fix that security hole You know like to to build that constituency on an on a long-term basis Rather than you know, here's this mountain of really valuable stuff that we're just going to open source and then walk away from right so That's the dynamic. I hope shifts more towards Stewardship and more towards kind of long-term thinking than then just throwing things over the wall and where I think rightfully some companies get criticized by For the wrong kind of donation if you think of it that way We're almost at the end of 2022 if I'm not wrong about the year because of COVID I don't know which year we are in but you know if you can talk about what are the things that you folks are like either working on And there are some problem areas or industries that you're like, you know, we still have to get them there We're both a very bottoms-up kind of community and in the last few months We've now in response to some of these questions from governments and other places. I also looked at a very kind of top-down kind of vision of what are the problems out there in the software world and When it comes in the when it comes to security and how much you actually close those issues How much you actually solve those issues things like trust in the supply chain to the provenance of code, right? and the conditions under which they were built or Getting s bombs not just a great s bomb library developed But actually getting it adopted and baked into the build and development tools out there So becomes a zero lift for developers and so in addition to continuing to support new projects that are again You know educational or services or software or whatever and and having an open door to that and making sure that the best to breed Rather than a thousand flowers bloom There is been work in putting together a plan to go and address these these ten top-level issues Some of which speak for things that aren't even started yet at the open SSF things like a security and incident response team that you know for that when the next time Something like the the log for J bug hits, you know, who did they have to turn to? They did turn to the Apache security community Which was able to be helpful but not able to provide the kind of full-time expertise and and and guidance to that community to help them avoid things like Committing and leaving a commit message that said had the name of the CVE attached to it, right? Which is what triggered all sorts of red red alarms and inadvertently divulge the log for J Vulnerability to a much wider audience than they had anticipated. So this response team Capability it's specced out. We're starting to figure out the pieces to it. It's not yet launched But I think it's going to be a critical piece to answering this Answering to answering. How do we prevent when the next log for J? Happens the next log for shell happens. How do we at least make it less disruptive for free industry, right? There's a couple of other ideas in the mobilization plan that are still emerging and I just encourage folks to check that out at open SSF org and We are a circus where we've got so many things going on. I would just love every open source developer to get to know better Here's the resources available to you Here's the ways that we're going to try it We'd like to try to help you and produce more secure code and a look out for the interest of your users better And if you see things that particularly resonate and you want to help us with it Let us know we'll make sure you get plugged into the right slack channel or work group or email list and and can really Participate in in helping secure the the open source landscape brand was again Thank you so much for sitting down with me today, and it's great to see you in person And hopefully this will become a new norm We'll sit down and do these interviews future as well, but I really appreciate your time. Thank you. Thank you Swapna