Delving Into the Risks and Rewards of the Open-Source Ecosystem

The backdoor discovered in the XZ Utils data compression software earlier this year kicked off a flurry of discussion on the risks of open-source software. Addressing that risk is not as simple as enterprise leadership deciding to eliminate the use of open-source software. In fact, that course of action is next to impossible.  

“The overwhelming majority of programming languages (and their basic tools) are open-source, and the ones that aren’t are dying out. Without an iota of doubt, open-source technologies are the very foundations on which the digital world has been built,” Quazi Nafiul Islam, developer advocate at Sonar, a developer of open-source software for continuous code quality, tells InformationWeek in an email interview.  

A working paper from Harvard Business School, “The Value of Open Source Software,” estimates that the demand-side value of open-source software is $8.8 trillion, a staggering number that paints a clear picture of just how intrinsic open-source is to the modern world.  

What does reliance on open-source software look like today, and how can enterprise leaders balance the risks and rewards that come with it?  

The Use of Open-Source Today 

You would be hard-pressed to find an enterprise technology stack that does not in some way rely on open-source code. Vertical software stacks have anywhere from 20% to 85% open-source penetration, according to the Linux Foundation. More than 90% of web servers and internet-connected devices run on Linux, one of the most widely known and used open-source operating systems. And Linux is just one piece of the vast open-source world that contains both massive projects with thousands of contributors, as well as small passion projects launched and maintained by just a handful of developers.  

Related:‘Who You Gonna Call?’ OSS Security Stakeholders Urged to ‘Cross Streams’

In the collaborative world of open-source software, anyone can see code and potentially contribute to it, enhancing its functionality.  

“When programmers can share their work and build upon existing projects, this promotes a culture of continuous improvement and collective problem-solving,” says Islam. “Open-source initiatives also democratize technology, lowering the barrier to entry for individuals and organizations.” 

Open-source software has the collective power of people around the world using their skills to solve common challenges, and companies are built on that collective power. 

“It [is] basically an impossible ask of [any] organization to say, “Oh, we just create our own language framework. We’ll have our own packages and everything’s not built on open-source,” says Nigel Douglas, senior developer advocate at cloud security company Sysdig.  

Related:Rethinking AI’s Impact on Software Development and Testing

The People in the Open-Source Community  

Who are the people building open-source software? Many of them are individual developers who use their skills to contribute to a project they are passionate about; it is a labor of love. “You might never be able to hire them, but they're willing to contribute their time because this is something they find cool and interesting,” Tim Mackey, head of software supply chain risk strategy at Synopsys, a software company that services semiconductor and systems customers, tells InformationWeek.  

Some of these individuals may turn that passion into a career. Seth Michael Larson got started in the open-source space in 2016. He had an interest in internet and networking technologies, an interest he did not have the opportunity to explore in his job at the time. “I ended up working my way up to becoming a lead on one of the most downloaded Python packages, which is urllib3,” he shares. 

Continuing down that path, he applied for and landed a role as security developer-in-residence at the Python Software Foundation. Open-source foundations like this one often operate with outside funding. Alpha-Omega, an associated project of the Open Source Security Foundation (OpenSSF), is funded by technology giants Microsoft, Google, and Amazon. In 2022, Alpha-Omega committed $800,000 to the Python Software Foundation and Eclipse Foundation.  

Related:Getting Started With AI-Augmented Software Development

Large enterprises may employ entire teams of people to contribute to open-source projects. “Several of the large technology vendors (AWS, Google, Meta, etc.) have employed people who have worked extensively with open-source projects. These folks are then able to continue their work while being paid to work with the communities they are part of,” Paul Hawkins, CISO at data encryption company CipherStash, says in an email interview.  

Maintainers are the arbiters of what changes can be made to a specific open-source project. “The human who's coming in as a maintainer is verified fundamentally based on the quality of the code that they're contributing,” Mackey explains.  

While there are paths to become paid open-source contributors, many developers in the community volunteer their skills and time for free. The 2023 Tidelift State of the Open Source Maintainer Report finds that 60% of maintainers are unpaid hobbyists.  

“Unless the project becomes quite large and a staple of software development, there isn’t much compensation involved. Typically, projects will have a small ‘donate’ button, but that’s about it,” says Islam.  

The wide-open field of the open-source community -- contributions are judged on merit alone -- means that even students can get involved as a part of their education.   

The Risks of Open-Source  

All software, proprietary or open-source, comes with risk. On the one hand, the ability for anyone, anywhere to contribute to a project means open-source software has the benefit of more skill than an enterprise could possibly hire on its own. On the other, it leaves room for continuity challenges.  

“Projects die out for a multitude of reasons, such as not having enough people willing to continually maintain them or not enough compensation for doing so,” Islam explains.  

While the collaborative nature of the open-source community is an undeniable benefit, it can also attract malicious actors. “Attacker[s] will also have access to this code, and they can understand this code,” says Amit Malik, director of threat research at Uptycs, a cloud-native application protection platform. “They can identify the vulnerabilities inside the code, and they can take that vulnerability of those things to compromise the machines.” 

Although threat actors are always looking for ways to exploit vulnerabilities, open-source code is always available for scrutiny. “It means that there are many eyes on the code, which increases the likelihood that issues will be found,” says Hawkins. 

Open-source software, unlike commercial software, is not purpose-built for enterprises. It may solve a specific problem many enterprises share, but open-source developers are not the same as vendors. Enterprise teams need to exercise caution when putting open-source software into service. It may solve a specific problem, but does it have the kind of baseline security enterprises would expect when purchasing a piece of software? 

“We have to accept that operating systems are built on a large distribution of different dependencies packages, and there is going to be a risk element involved,” says Douglas.  

While some risk is inevitable, enterprise teams need to have an understanding of that risk and use open-source software accordingly.  

“As a CISO, the biggest risk I see is for organizations not to be intentional about how they use open-source software,” says Hawkins. “It's extremely valuable to build on top of these great projects, but when we do, we need to make sure we understand our dependencies. Including the evaluation of the open-source components as well as the internally developed components is key to being able to accurately [understand] our security posture.” 

Open-source software is inherently different than commercial software, but it will not serve enterprises to treat this ecosystem as a completely free resource that will always be there when they need it.  

“If we just continue to treat this as an infinite, extractive resource without contributing back, without doing something to maintain that, it will just end up causing a huge amount of churn,” says Larson.  

The XZ Utils Incident and Open-Source Vulnerabilities  

The ubiquity of open-source software means that vulnerabilities could have widespread consequences. The XZ Utils incident is a good example of the potential fallout of a vulnerability in a widely used open-source component.  

The main actor involved in the incident spent two years insinuating themselves into the open-source community, eventually stepping into a maintainer role. In that position, they were able to inject malicious code into two versions of the XZ Utils software. XZ Utils is used in many Linux distributions. If the versions with this backdoor had made it into widespread distribution, it could have facilitated significant unauthorized system access.  

Although the incident sparked widespread alarm about open-source risks, in some ways it was also a showcase of the open-source community’s resilience. “It was a success for open-source because the visibility that this had, it allowed … best-in-class researchers and security analysts to weigh in within hours,” Larson points out.  

The XZ Utils backdoor was caught before it could cause major harm, but that doesn’t mean something similar won’t happen in the future, and with more success for an attacker. 

“Something like XZ … eventually will happen to some degree. We do not know when and how it will happen,” says Malik.  

Thousands of vulnerabilities, whether due to a mistake in the code or malicious intent, impact the open-source space every year. Whether or not those vulnerabilities are actually exploited is another matter.   

In late 2021, the critical Log4J vulnerability illustrated just how damaging an open-source vulnerability can be. “Log4j is an open-source logging framework within which was a vulnerability that enabled remote execution or the leakage of potentially sensitive information,” Hawkins explains.  

Vulnerabilities can highlight how so much can depend on very few people. Islam points to the Heartbleed vulnerability, discovered a decade ago. “The Heartbleed vulnerability … was caused by running a vulnerable version of OpenSSL, a library that is used to secure most internet traffic. While the project was maintained by a group of volunteers, there was only one paid full-time employee working on it,” he explains.  

In the wake of the Heartbleed bug, the Linux Foundation launched the Core Infrastructure Initiative with the intention of providing security support to open-source projects. Today, OpenSSF is the leader in championing security of the open-source ecosystem.  

The Future of Open-Source 

So, it isn’t feasible to ditch open-source software, and risk is part of the deal. For enterprises, that reality necessitates risk management. And that need only increases as does reliance on open-source software. “As we move towards cloud and these kind of highly dynamic environments, our dependency on open-source is going up even higher than it ever did in the past,” says Douglas.  

If enterprise leaders shift how they view open-source software, they may be able to better reap its rewards while mitigating its risks.  

Enterprises do not have to pay for the use of open-source software, but that does not mean it should be considered completely free. “Look at what the cost of ownership is and say that there is a certain cost associated with vulnerability management,” says Mackey. “There is a certain cost associated with ensuring that the functionality remains true to the purpose that they acquired it for in the first place.” 

In order to effectively have open-source vulnerability management, enterprise teams must actually understand what open-source components they are using. That task is easier said than done. 

“The real challenge is … understanding the current patch state, the age of the components, the sustainability, the maintainability of these components. They all start with having an accurate inventory because, fundamentally, you can't patch something you didn't know you had,” says Mackey.  

Enterprises can implement mechanisms to evaluate the security of the open-source software tools that are a part of their dependency tree. 

“The Open-Source Software Foundation Score Card … is a specific tool to check for … how active is a project and, for instance, what controls are there in regards to code review and branch protection and vulnerability detection and binary effects,” says Douglas. 

If an enterprise wants to see changes in an open-source project, it isn’t as simple as exercising contractual influence, as it could with a vendor.  

“Enterprise leaders need to really … understand that managing open-source is not the same as managing the vendor relationships that they have in a commercial software world. It just doesn't work that way,” says Mackey. “Enterprise leaders need to say, ‘How am I going to actually govern this in my world?’ as opposed to ‘How can I extend my current commercial way of thinking to apply to open-source and bend open-source towards that commercial mindset?’” 

Enterprises have a vested interest in a robust, secure open-source ecosystem, which suggests they have a role to play in contributing back to that ecosystem. “The real solution is actually to say, ‘Here are the open-source components that my organization depends on. These are the ones that are critical and without which I just wouldn't be in business,’ and then find ways to actually contribute to the success of that software,” says Mackey.  

Contributing to the success of an open-source project could come in the form of monetary support. Companies can work with Tidelift, for example, which partners with open-source maintainers and pays them for their work. Alternatively, enterprises can set aside dedicated time for engineering talent to contribute to open-source projects.