The tech industry's perceptions of open source have come a long way. Even amid well-publicized open source vulnerabilities such as Log4j, open source software continues to gain traction in the enterprise at the expense of proprietary software. 

According to the recent State of Enterprise Open Source report from Red Hat, 89% of the 1,300 IT leaders surveyed believe open source software is as secure or more secure than proprietary software. 

More than three-quarters of respondents said they have a more positive perception of enterprise open source than they did a decade ago – a time when open source security was seen to be a weakness.

Vast open source libraries serve as the building blocks for software creation, a boon for companies developing software at a quick clip. Yet, the time saved can mean companies lose sight of where vulnerabilities could lurk. 

"Whether it's developed behind closed doors or out in the open, all software is going to have vulnerabilities because all software is written by human beings," said Vincent Danen, VP of product security for Red Hat. "Before, we may have seen open source as being risky, but all software has risk, and now it's no more risky than proprietary software."

IT focused on managing open source, not scrapping it

The top security benefits associated with enterprise open source are the ability to use well-tested code for internal applications, the presence of well-documented security patches, and the prompt availability of patches when a vulnerability is found, according to the Red Hat report.

"Log4j doesn't make anyone say they'll reduce their usage of open source, because the primary reasons for using open source are functionality and the ability to save time and resources," said Chris Wysopal, the founder and chief technology officer of Veracode. "What people did ask in response was, 'How can I better manage vulnerabilities? How can I understand what I'm selecting, and why?'"

With open source, it's common for software to pull in readily available code snippets or dependencies that have already been written, tested, and executed. This offers the advantage of shortening the development life cycle, as teams don't have to write code from scratch if it already exists.

Log4j is a case in point: The Java-based logging framework is in place in more than 90% of all cloud environments, according to an analysis from Wiz and EY.

However, this can pose problems for enterprise users once they deploy open source.

"There are a lot of pockets of software you need to be aware of," Danen said. "You may have a vulnerability in the dependencies that your code may not explicitly trigger, but the use of one dependency may use another dependency. You need to pay attention to the things that are used by the things that you're using."

Wysopal described this as a "nested problem" similar to when car makers issue a recall to address an issue such as a defective airbag inflator. The consumer is impacted not because they bought the airbag but because they bought the car that included the airbag that the car maker bought. 

"You could be vulnerable without knowing it," Wysopal said.

SBOM as a starting point, albeit with limits

One way to address this issue is through a software bill of materials (SBOM), a written record of the software's various proprietary and open source components. A May 2021 executive order from President Biden, any software vendor contracting with the federal government would be required to provide an SBOM.

SBOMs are valuable because they make it possible to maintain a database of dependencies across their open source software deployments, Wysopal said.

That way, when a vulnerability is discovered, IT leaders can search their database, see which software products are affected, plan a patch strategy – and see if any vendors have been slow to respond.

But the SBOM is just a starting point, he said, as it's just one level deep. To be truly useful, the SBOM needs to be structured not as a list but as a tree that better maps which dependencies are related.

"Open source is multiple levels deep: A pulls B, B pulls C, C pulls D – and D could be Log4j," Wysopal said.

The other challenge associated with the SBOM is that it theoretically only changes when the underlying product changes, Danen said. A new SBOM after a major software release makes sense, but it would be difficult for vendors to release a new SBOM every time a vulnerability it patched, especially given the frequency of patches for low-risk vulnerabilities.

"When you recall a product, you don't change the labels – you pull it off the shelf," he said. 

Log4j as a learning experience

Despite the security challenges, the move to open source is not slowing down. 

Over the next two years, IT leaders expect their share of proprietary software in use in their organizations to drop from 45% to 37%, Red Hat found. Use of enterprise open source is projected to increase from 29% to 34%, with community-based open source expected to rise from 21% to 24%.

IT leaders tend to use open source for emerging technology workloads associated with artificial intelligence, edge computing, and containers.

Part of the reason for this, Wysopal said, is that companies have been learning their lessons from large-scale vulnerabilities.

Several years ago, the Veracode State of Software Security report found that 35% of code libraries in enterprise open source applications had vulnerabilities, according to Wysopal. Then came the 2017 Equifax breach that took advantage of a Struts 2 vulnerability. Today, the figure is down to 10%.

"Libraries now have fewer vulnerabilities, and enterprises are using newer libraries more frequently," Wysopal said. "Equifax got people to manage open source better than before, and Log4j will do that again."