Open Source Software Security: Current Risks and Future Outlook – Henrik Plate, Endor Labs
Henrik Plate, security researcher with Endor Labs, speaks about the direction of open source software (OSS) security, the top open source risks facing organizations today and where most fall short in assessing OSS vulnerabilities, and what we can expect for the future of OSS and supply chain security.
Transcript
This is Textron tv. Hey guys, thanks for the throw. We're here with Henry Ate, who is a security researcher for Indoor Labs, and we're talking about what the White House is up to as it relates to open source Sophomore Security.
They've had a request for some information and they've been kind of banging on this issue now for the better part of a year. But let's dive in. Henrik, welcome to show.
Thanks for having me. What should people make of this request for information? Because there was a summit last year and there's been a discussion ongoing, but is the White House getting a little more serious here?
What are, what are the implications? I would say the White House is pretty serious for quite some time already, and this is yet another effort they make in order to improve the overall security poster of open source software. So this is just one out of many, you know, efforts and works in that space.
And, um, what they try to do here is basically search, get additional input on where to focus efforts and funding in the upcoming months, maybe years. I don't know exactly the time timeframe they're targeting here, where to Yeah, which other areas to improve on top of what they have looked at in the past, uh, which are these, uh, memory safe programming languages, for example. So as part of that, let's just look at the programming languages for a minute.
I mean, is it feasible to convert everything into a memory safe programming language? We have lots and lots of code that has been running around for decades, and a lot of that old code is in government agencies, Right? That is, that is kind of a rhetoric question, right?
Uh, well I, first of all, I think it's not worth it to say that there are, there is a constant flow still of vulnerabilities related to, you know, memory management, let's say, um, done wrongly by developers and thus leading to vulnerabilities. And so it is still, it is still a topic and so I understand that they wanna do something about it, but I really doubt they will be able to, you know, rewrite all code bases that have been developed over the course of the last, I don't know, 10, 20, 30 years using those programing programming languages. So this is something that I feel a lot of money can be invested in without ever reaching kind of, uh, the end of this tunnel or ever seeing any light.
So, yeah, I, I share your doubts. Let's say, Well, well what about ai? We have seen a number of tools that are AI based lately that are converting programming languages from one language to another.
Is that practical or can that work because, you know, it's a lot of promise, but I'm not quite clear to me that the code is initially works or how much effort is required. Yeah, those AI probably can help, but what we have seen so far, um, is rather, you know, smaller snippets, smaller maybe single files. I have some doubts that we will be soon able to convert entire code basis of more complex, you know, software, you know, in one shot or even a few shots into, into other programming languages.
I don't see this coming anytime soon. Sure, AI will be helping us a lot, but you know, it's not something that they can do for us. Um, with a finger snip, A lot of the maintainers of these open source projects are small teams of folks.
There might only be two, sometimes even one of them. So as you look at kind of the guidelines from the White House and other places, what leaps out at you as stuff that's practical, things that they can do that might have a more immediate impact? Hmm.
I think what may, maybe this is an opportunity to discuss several of the kind of items that they, or areas that they proposed in this R F I. Right. So there is one big area, which is all, and lemme just scroll to this, I have it on, on my other screen all about securing open source software foundations or secure search foundations.
And, um, I think here we see a lot of technical topics that we have seen already in the past, such as secure by default or secure by Design. These are concepts that have been discussed for years and years already. And so it makes sense, obviously to also apply those principles to open source topics and other, or open source projects.
Another topic they, they look into is strengthening the software supply chain. So this is about detecting, for example, about detecting malicious open source components. This whole software supply chain topic of course, obviously also got a lot of push in the last two, three years.
So that I didn't find so surprising. And yet another area or sub area of this big topic is develop education such as improving the curricular of students. Again, something that the security community advocated for, you know, the last couple of years.
So here's, there's a big block with the relevant work that will certainly improve the security poster, but I don't find this, you know, so surprising. It was kind of expected and everything is good. It will increase, you know, overall poster.
What I find more interesting in the R F I, uh, the more economic topics, not so much technical, but about how, you know, how open source developers can be compensated whether to introduce liability in this whole software market. What about international collaboration? And, um, you know, the, the how to deal with the problem that open source projects are global projects with contributions from individuals all across the world.
Many times you don't even know where they come from. And so I find those, those topics more interesting. When I was reading the, the R F I, So let's say I have a small number of maintainers and an open source project, and it's basically a hobby and nobody, and they certainly didn't expect a large multimillion dollar company to build a software on top of that and kind of create some level of dependency on them to go fix a vulnerability.
So what is practical here? I mean, there's only two of them. I'm, they, they only have so much time in the day, and even if you pay them, they may not have the time to get to any of these vulnerabilities.
So how do we practically address that kind of issue? Yeah, I think, I think the only solution to overcome problems or vulnerabilities and, and other issues in these small open source projects is really to have all those big, bigger consumers, bigger corporations that build on top of those directly or indirectly support them in terms of, uh, contributions, fixing those problems, uh, you know, by creating a pull request, um, or maybe by, uh, hiring or dedicating some of their workforce to work on this. Um, or yeah, so this is, this is I think the only way to, you know, help smaller open source project.
As you say, giving those guys money, uh, will not, will not solve the problem. They may not have the capacity to, um, you know, spend enough time and do this and, or they maybe have just other priorities. I mean, there are so many open source projects that are just out there for the fun of the development, and the developers never intended that those projects are used by somebody else for commercial projects or whatever else.
And so they, they actually also don't care whether there are any downstream users. And so for me, this is again, showing that ultimately it is the responsibility and the problem of the consumer. And if the project does not have the capacity to fix and handle those problems or doesn't want to, it's the consumer's duty to either do it on their behalf or switch to another open source project.
Mm-hmm. At the end of the day though, should the liability not fall on the commercial entity that's trying to use that software because the maintainers are not necessarily making any money on it, so maybe we should just follow the money and associate the liability with the money. Of course, of course.
So when I was saying liability, I never intended to say that open source developers or open source project should be liable. That is, that is, uh, that is crystally clear to me. It should be the commercial software and services provider who, those who receive the money from their customers, um, or maybe also government agencies that, uh, you know, deliver services to, to their audience that should become liable for whatever they consume and whatever, whatever they build by themselves.
Do we need maybe a SWAT team to go help those open source maintainers who are, you know, specialists who will be cybersecurity folks that can drop in and kind of address some issues and then move on to the next project? Then we don't necessarily need every maintainer to become a cybersecurity expert. That is happening already.
I know that, uh, there are some, for example, the, um, alpha Omega project of the open s s F is a project that is, um, aiming to identify kind of the most important, most relevant, uh, you know, open source project. And, uh, one result of that effort is also to know which projects to support either by funds or by, you know, hands-on, uh, implementing security fixes. Mm-hmm.
Are you at all worried that a lot of this focus on open source software security is gonna push people back to proprietary platforms that they perceive will be more secure? No, there's, I, I don't see this happening anytime soon. I think the, the economic, it's just economically unfeasible or infeasible to develop the whole stack by yourself.
So I think there's no way around open source these days. If you decide to build all or larger portions of software by yourself, I guess you will be soon out of business because you can't manage to ship a product in a reasonable timeframe. And, uh, I, I think all those, you know, venture venture, uh, fundings and venture funds wouldn't, wouldn't depreciate.
If you say, look, I build it all from scratch, we will have a first alpha version in like three years or so. So, no, I think, I don't think this is a viable solution. All right.
Many years ago, president Ronald Reagan said the most dangerous nine words in the English language are, hello, I'm from the government and I'm here to help. So is this gonna make anything better ultimately, or, you know, should we, should they just leave everybody to their own devices and we'll figure it out as we go along? Oh, no, no, no.
Um, I am, I must say personally, I very much like those initiative initiatives of the government, this one included because they, I like it how much they, they, they, they state very clearly and acknowledge very, yeah, frankly, the importance and relevance of open source for today's world software world. Um, I think they have called it, uh, a public good and a good of national importance or, so I, I, I very much like how much they kind of value open source, and I also like that they seek input in the way they, you know, send those RFIs out. It's not, they're not sitting in their agencies.
God knows where they are and come up with ideas and try to teach open source developers or the, the software community how to do things, but they actively seek input and advice on how to solve and address those issues, which is very much in line with the whole, the, the whole spirit of those open source communities, which is all about inclusion, you know, getting and collecting feedback and discussion. So, I, I don't agree here with, uh, Ronald Reagan, Um, as you kind of think about this whole situation, every time we have a crisis, whether it's log four J or the 10 that happened before that, everybody says the same thing, oh boy, this is a wake up call and everybody's supposed to wake up and about a couple of weeks later, everybody rolls over and hits the snooze button and goes back to sleep. So is it your sense that things are getting better or, you know, is this just another instance where, you know, post log four j shell and we're starting to get distracted with other things and we're not quite paying as much attention to this as we should be?
Uh, So first of all, I completely agreed to this, you know, this perception a couple of years back. So, uh, um, um, uh, this incident in 2017 of this credit, uh, rating agency, um, what was the name? I, Equifax, right?
And back then I was already working on open source security. I told the guys, or when, you know, in discussions and presentation, I was basically pointing to the share price of I Equifax, and I said, look, guys, this is, this is how bad it can get for a company if you have an open source vulnerability in your stack, and you don't do anything about it because it fell, uh, yeah, in, in, in big way, big good, let's say significantly, I think lost, I don't know, 30%, 40%, it was significant. But then a year later or so, I realized, oh boy, the share price is as it was before.
So I wondered, well, there doesn't seem to be any financial or economic impact on the companies that do not handle it properly, like Equifax. And so in that way, I support your, you know, your feeling or your perception. But right now, after log four J and after all those government efforts, uh, I have the feeling that we are not hitting this news button and we are not, you know, falling asleep again.
All right, so my, my feeling is it's getting better. All right folks. Progress is being made slowly but steadily and hope springs eternal.
So cross your fingers and hope everything does get better as we go along. Henry, thanks for being on the show. It was a pleasure.
Alright, Back to you guys in the.