Open Source Software Security Concerns with Spike Curtis

This is Textron tv. Hey guys, thanks for the throw. We are here with Spike Curtis, who's principal engineer for Coder Technologies, and we're having a little chat about the state of open source software security, because there's a lot of gnashing of teeth lately around this subject Spike, welcome to the show.

Yeah, thanks for having me. What is your take on what's going on here? Because, well, not all open source projects are the same, but in theory, we're supposed to have peer review and that results in better security, but we certainly hear a lot about of instances where that's not necessarily the case.

Maybe it's just the projects are too small, but what should we be thinking about here? Well, um, there's, like you said, a really big sort of range of, uh, kinds of projects that, you know, qualify as open source from these little kind of passion projects that's like one developer in their free time to these big massive projects like the Linux kernel or, uh, Kubernetes. That's, that are backed by multiple companies and have, you know, hundreds or thousands, um, of contributors.

So like the, the state of security, you know, in, in open source is, is one that's pretty varied. Um, and the, uh, kind of dashing of teeth that I've heard lately is around like, uh, software supply chain. So we've had these like high profile attacks, um, that, uh, was actually more of a near miss, like the, um, XE util, uh, thing that happened last year, um, where, um, a very committed attacker, um, found a popular but relatively under-resourced open source project, kind of went in, made friends with everybody, became a committer, and then, um, introduced some malicious commits into, um, the repository and sort of pressured this, uh, popular, um, library to get included in Linux distributions.

And then, um, trying to use it to launch attacks on SSH. Um, but it was actually near bis because other open source people noticed weird stuff happening and, um, basically caught the, the issue before it made in itself kind of widely, uh, distributed and things like that. So, um, like I said, a a really big kind of, kind of range of things, but, but my perspective on, on open source software is that, um, you know, it's not a time where things are getting worse and scary.

Um, the, the community is, is, um, supporting more and more projects. We have people paying attention, um, and I think open source software as, as a place to, to go for, um, se secure, uh, things is still, uh, a good, um, option for people. I don't think people are walking away from open source.

I think that would be too problematic. But there has been some discussion about maybe not using passion projects and not letting that into our enterprise environments 'cause there isn't enough resources behind it to make sure that whatever patches or updates need to be made or made in a timely way. I think that that's right.

That, like, you have to look at at things at an individual level, like lumping everything together as like, oh, this is open source, open source is great, or this is not, um, or open source is bad, is is the wrong way to, to think about it. And like a, a sort of, uh, table stakes for, for using open source well is to do your due diligence on the projects, right? Understand, um, who's building this thing, um, what kind of support you're gonna get.

Um, this focus on, on supply chain, I think also is, is a sort of really narrow focus on probably a minority problem. Like the bigger issue in software in general, um, is, uh, just vulnerabilities that are put in not maliciously just by mistake. Um, there are are some high profile instances of, of people deliberately inserting back doors, but it's very, very rare compared to the kind of random vulnerabilities that you see, right?

There's, there's thousands and thousands of ces that are issued every year, and only a tiny fraction of them are like, you know, the supply chain, uh, kind of problems or deliberately targeted attacks. What is your take on AI as it relates to improving or reducing the number of vulnerabilities? I'm asking the question because some people say that they're seeing more vulnerabilities, at least in the short term, using these tools.

Um, but longer term, might we not just reduce the number of vulnerabilities that we're a, creating and b, fix 'em faster? Well, I think that, you know, it's reasonable to expect that automated tools, uh, will get better over time. That's not a new thing, right?

Like, um, static analysis of software looking for security vulnerabilities is something that we have had and something that should be part of your toolkit. Um, and, uh, I don't think that there have been convincing demonstrations of the current, like generation of generative ai, you know, your copilots and, um, oh chat GPT and things like that. There's not been any convincing generation of those models, uh, finding security problems in a, in a systematic way.

But, um, it's very early days for this sort of thing, right? If you actually sat down and said like, I'm gonna train, um, a model that's gonna look at software and find common problems, um, you could probably, um, have, have some success with that. But it, it's very early days.

I think that it sort of remains to be seen whether, um, AI is gonna be able to build us tools to help us, uh, find vulnerabilities. Um, I will say that like the current state of the world of like having, um, chat GPT and copilot and these things write code for you does worry me a little bit around security vulnerabilities because, you know, you have people, um, putting a bunch of code into the system really fast, um, generated by, by some ai. Um, and, uh, it can, I think, accelerate, you know, the, the rate at which you're making these, these sort of, uh, introducing these vulnerabilities and things like that because you are not sitting down there carefully analyzing things.

You're using this thing as a speed boost to sort of get more code into your editor faster. There's always criticism level that the enterprises that are consuming open source software for not contributing enough to the community to help resolve some of these issues. And, uh, I'm not quite clear how reasonable an expectation that is or is that just something we kinda wish would happen, but it is never gonna happen.

Yeah, I mean, I think that like there are companies out there that like, uh, are absolutely pulling their weight and probably pulling other people a along with them in terms of how much support they they give to open source, what they release, what they, their people sort of do for the, the open source ecosystem. And then there are other companies that sort of sit on the sidelines and, and consume open source. And like the whole idea of an open source license is you're saying like, I am giving you permission to use this.

And so I don't think that it's at all fair to, to sort of have a permissive license and then criticize somebody for using that. But there is, um, you know, some open source maintainers have had issues with, with people, um, being very imposing on them, right? That, that if you're in this project and you're doing, you release this open source license and then somebody like wants a feature done or finds a bug or something like that, they kind of come at you with this expectation that it's your job to, to fix it.

Um, and I think that that's the thing that, that sort of puts people off. I think most open source, uh, contributors are not worried about a company, um, using the software and not contributing it back. You sometimes get a little bit of, uh, soreness around somebody forking it, doing something and then not contributing that back.

But again, the licenses don't say or don't always say that you have to do that. So I, I don't think it's that's necessarily fair, but, but when you sort of get into these interpersonal relationships and get put upon, that doesn't feel fair and that doesn't feel good. And I think that that, um, that's something that, that people definitely need to be aware of as they interact with open source communities.

The other thing is, is like, um, like this XE util, um, project, it, it became way more popular than, um, was sort of really able to be handled by, by a single contributor. And there are other projects that, that sort of fall into that category where, um, they're started by a small team or started maybe by a large team, but then people sort of peel off and do other things, and there isn't enough people left around to really handle the, um, maintenance of, of the software as vulnerabilities are discovered and things like that. And that puts everyone in a really awkward position.

Um, and I think that if you are, are a company that's using open source and you find yourself in that situation where you depend on a package, but you don't think that that package is being, um, uh, being taken care of the way that it really needs to, that I do think, you know, it is, uh, a good idea for for companies to step up and say, you know, look will dedicate some of our engineering time to maintaining this package because it's important to us, it's important to other people. And, and we can sort of see that, um, while maybe at one point it was really well, uh, maintained, um, you know, uh, unpaid or people, people aren't necessarily being paid to, to, uh, work on these things. And so, um, somebody has to step up it or you have to sort of get out of it and say, look, look, too dangerous.

I have to find a replacement package or something like that. There's also a lot of talk about, well, we need to compensate these folks that are creating this open source code and they'll respond better 'cause compensation drives behavior, but it's not clear to me that that's gonna work either because, well, it's a passion project and some folks have a life, right? Yeah.

I don't think that that, that the idea of like, we'll just compensate them is necessarily that sustainable of a model. Like sometimes it is where, where people are working on something and, and they, they just have a little tip jar and that's kind of enough to, to sort of keep them going. But, um, the sort of, uh, short term like, oh, I had this problem.

Let me, like, you know, dump $10,000 on you or whatever, um, is, is not gonna sustain things in in the long run. It might grab somebody's attention for a while, but there's not really anywhere in the world where, um, well-trained software engineers, um, don't have like better prospects, um, than, uh, than that to, to be able to grab their attention. So, um, you know, the, the model that I think does work is, um, one that we've had for, for a number of years where, um, people are working at companies, um, full-time, you know, maybe building proprietary software for that company or maybe building only open source, but also part of their time is spent building and maintaining open source, um, projects.

Um, so that, that these things get maintained, um, and you sort of benefit from, from people coming together where, where the, the project itself is not some sort of, um, competitive lever for a company. Um, being able to contribute it, open source, um, allows everybody to kind of share in, in, in that value. And that's, I think, a sustainable, um, way to go about it, right?

It's the way that the Linux kernel, um, has kind of been sustained over the years. You have companies like, um, Ubuntu and Red Hat and all these other, um, downstream distributions. They have people on their staff that are working on those projects.

Um, day in and day out For a while people were kicking around the notion of creating a, uh, quote unquote SWAT team that would be responding to these crisis whenever there was an issue with an open source project. But it doesn't seem like that's panned out all that well. What's the challenges in kinda maybe having some sort of collective response team?

It's kind of like the fire department, but I guess if the fire only happens every once every three years, it's hard to keep everybody on call. Yeah, I mean, it would be like having a, a fire department for the entire world, right? Like, there's just a huge variety, right?

You've got people who, um, are living, you know, in bungalows and people who are living in high rises and, and you know, people who are just like living in yurts in the, um, um, in the desert or whatever. Like, um, you can't just have like a SWAT team that's gonna like jump in when whenever there's, there's a problem because the sort of scale of problems and the range of different projects and stuff is just, it's just too big, right? So, um, the, yeah, the, the idea of like, you know, some sort of short term, uh, kind of thing is, is I think pretty pretty out there, right?

Like even if you had this SWAT team that was like ready to go and you had a, a project that found a vulnerability, um, and, uh, needed to be patched quickly, it's not like you could sort of just sort of parachute some new engineers in, um, that haven't been trusted by the project and like, are gonna go in with the maintainers, like maintainers of these projects are not gonna like just accept randos from, from wherever kind of coming in, um, who don't necessarily know the, the code well and, and are up to speed. You know, it, it, it really doesn't work like that with software. You can't just sort of jump in and, um, and fix a, a major problem and then, and then run off.

I fear that this issue may get worse before it gets better because the band guys are discovered AI tools as well, and they're using that to scan for vulnerabilities that then they're gonna have like a zero day exploit for, um, because they didn't analyze the code in ways that previously was, took a lot longer. So, you know, what's your sense of going into this coming year? What should we expect?

I don't get the sense that AI enables bad actors, particularly more than it enables, uh, good actors in, in open source software. Certainly like, um, if you were like, uh, worried about AI tools being used in bad ways, there are lots of interesting examples of like, you know, voice impersonations and like stealing, you know, calling up people and sounding like their mother and, you know, asking for personal information and stuff like that. That's the kind of stuff that worries me.

But, but in terms of, of, uh, software vulnerabilities and stuff like that, you know, we've had script kitties and, and like automated, uh, vulnerability scanning, um, for, for decades now. Um, so like there, there's this constant, uh, sort of battle of, um, find the vulnerabilities, fix the vulnerabilities. So where you want to invest is security researchers, um, going out there, finding vulnerabilities in important packages, and then, um, investing in software developers being able to maintain those important packages.

Actually when the vulnerabilities are found, be able to patch them issue, um, a, an update and let people know that, that they need to upgrade. Um, the war will go on basically between, between attackers and defenders, um, in, in software, um, and AI changes things, but it, there's no particularly strong bias between attackers and defenders in, in software that I've seen so far. Hey folks, you heard it here.

Yes, there are things to be concerned about, but I don't think there's any need to panic just yet. Little common sense will go a long way still. Spike, thanks for being on the show.

Yeah, thanks for having me. Nice night. And back to you guys in the studio.