Strategies for Consuming Open Source Software Securely

author-image

By

It’s never been easier to use and consume open source software. Today’s developers stand on the shoulders of a generation of giants with an almost endless assortment of open source packages to empower any project, humble or ambitious. But with power and flexibility comes responsibility to wield these open packages carefully.   

In this podcast episode, we talk best practices for evaluating and consuming open source software, securely. Ryan Ware, Director of Open Source Security at Intel, shares insights earned over decades working with open source software. 

Katherine Druckman: 

Using open source “the right way” includes adhering to best practices as a consumer of open source software. What does it mean to be a careful consumer of open source software? 

Ryan Ware: 

There are lots of things you need to do and to look at, and there are a lot of good reasons why. The number of open source packages continues to grow at an astonishing rate. Take an ecosystem like Node Package Manager (NPM). The NPM registry has something like 800 or 900 new packages every day—not new versions of a package—that's new brand-new packages that people need to deal with.   

There’s also  more focus on the security of open source software. For example, CVEs (Common Vulnerability Enumeration from MITRE), the publicly known vulnerabilities in software— in 2022 there were over 25,000 vulnerabilities in the database, up 5,000 over the previous year, the largest increase ever. That averages about 70 brand-new vulnerabilities every day. It's hard for teams to keep up with. That said, open source software should definitely be used. It's great to work in the open source ecosystem; utilize open source software for your products and give back to the community. That said, there are a number of things to look at when you're choosing open source. 

Let’s try a thought experiment: What would be the first thing you'd think about when you want to use open source in your project?  

Katherine Druckman: 

Great question. I look at a lot of things when vetting, but I’d raise up to the top of the list how long it takes to address vulnerabilities. That's one of the big ones. 

Ryan Ware: 

That's definitely a great thing to go look at. I’d go up the stack even from there. Does the project actually have a maintainer anymore? 

Katherine Druckman: 

Yes, absolutely! I want to see the date of the last post in their issue queue.

Ryan Ware: 

Absolutely. I've seen projects used by teams that if you look at the upstream it hasn't had a commit or a response to any issues or questions for three, four, five or 10 years, even. And if that’s being used, it's really just completely unsupported software -- and the world has changed quite a bit in the last decade. 

Katherine Druckman: 

Yes, that would be a very red flag.  

Open source is everywhere now, right? It's the way software is made. Statistics say that 90% of commercial software contains an open source component. 

Ryan Ware: 

If you go grab a piece of software , about 70% to 90% of it’s open source, and the 10% or 20% that’s proprietary just utilizes that open source. There are great reasons for that. For example, let's say you’re building software, the choice isn't to create your own cryptography stack as opposed to using OpenSSL*. You might have fun building your own crypto, but it's never ever going to be a stack that can hold up against hackers or attackers looking to figure out how to exploit your crypto stack. The professionals who have been doing this all their lives and who have been crafting software stacks like OpenSSL and GnuTLS still obviously run into problems all the time with new vulnerabilities, and if they have problems and you're not an expert, you’re not going to be able to fix it. 

 

 

Katherine Druckman: 

Both of us have been around open source software a long time. How do you think the open source security landscape has changed in the last 15 years?

Ryan Ware: 

The original iPhone* was released slightly over 15 years ago, in 2007. Look at the changes that have happened because of that, where the ubiquity of software and web applications on mobile devices became just there for people to use all the time. I look at how non-tech people in my circle of family and friends went from being tech neophytes, not ever really using computers, or if they had to, just email and things like that. Now they rely on computing of some kind, whether it's mobile or a laptop, to do everything they do every day. There was an explosion of web applications in those 15 years. Web applications are what makes the world go around these days. If web applications suddenly vanished, the world would just halt. There are security implications to going from a few popular banks with web portals to paying for every bill you have through some kind of web application. The surface area of what can be attacked is just so much broader than it was.

Katherine Druckman: 

It's broader, but are these security concerns new or is it basically the same old thing, just more of it? What are the new security concerns?

Ryan Ware: 

It's interesting. If you look at what’s been done in the past to make things more secure, and I'll focus on the x86 software stack as an example, it used to be, back in the days of MS-DOS, you just ran your application with complete control of all resources in the platform. Then you realize that just running everything in Ring 0 is probably a bad idea, so you had to separate the operating system and applications, so you added a little bit of extra separation. Then attackers can't exploit things because you have privileged separation between user-space applications and the operating system, but they find something new, like doing buffer overflows on the stack, to figure out how to inject code and exploit the system.  

Then Intel and others added new technologies to prevent buffer overflows, so they start looking at things like heap overflows or SQL injection attacks or cross-site scripting attacks. As people continue to find new technologies to help protect users from being exploited by these various exploit techniques. The attackers start looking at more complex things, and that will continue for the foreseeable future. There will be attacks that come up in five or 10 years that nobody has thought of yet or thought, “Oh, it's going to be way too expensive or resource-intensive to exploit things that way.” Suddenly it will become easier.

Katherine Druckman: 

Low-hanging security fruit. There be Dragons. 

Ryan Ware: 

Absolutely. At the end of the day, an attacker will look for the easiest way. 

Katherine Druckman: 

A lot of statistics thrown are around about the increasing number of vulnerabilities and how long it takes to fix them and the huge numbers of dependencies that most software packages have today. Given how much software uses open source components, is it fair to say that these challenges are universal? What security challenges are unique to open source? 

Ryan Ware: 

It's a number of different things. First, dependency problems are based on what ecosystem you're creating your application for.  

For example, if you’re focusing on a C application, you probably only have a few libraries, and they're probably almost all direct dependencies. If you look at something like NPM or JavaScript* applications, in that ecosystem is you could pull in like seven or eight different direct dependencies into your application that you need functionality for, and those dependencies bring in tertiary dependencies that bring in 400, 500, 600 or more open source libraries into that application. Suddenly the application where you brought in seven or eight different things is now an application with 500 dependencies and you probably don't know what most of them are because they're all third, fourth, fifth-order dependencies you didn’t explicitly bring in yourself, so it's an interesting challenge.  

Web applications all pretty much focus on JavaScript in the JavaScript ecosystem, so it's a big problem in that side of the world. At the same time, when you're focusing on things like creating a .NET application or a Linux* C application, it's something that you have to keep in mind, but not something that you have to focus upon. It's much more managed.

For more of this conversation and others, subscribe to the Open at Intel podcast: 

About the Author

Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly.  A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.