The Java library Log4j is very widely used. System administrators and programmers around the world integrate the library into data centers, company servers, network technologies and system components due to its functionality. The Log4Shell vulnerability was initially particularly easy to exploit. Once in the system, attackers could execute arbitrary program code, reload malware or steal data. Ultimately, this led to the potential vulnerability of several billion computers worldwide.

As expected, the Log4Shell vulnerability leads to a predictable outcome: executives and governments are increasingly concerned when the term open source is mentioned. Most of them are not necessarily aware that much of the software they use successfully is developed by volunteers rather than commercial vendors. Meanwhile, even some of the most critical systems use open source software. What often does not exist in companies, however, is a list of all open source software or all components used. Serious incidents from the past such as HeartBleed, Dirty Cow and the experience with Apache Struts and the resulting data protection incident at Equifax have led to audits by government agencies. It is not uncommon for the "bad" open source components, in this case log4j, to be replaced by a supposedly more secure alternative.

In all these scenarios, however, one aspect of open source software is often overlooked in our modern society: Open source enjoys a very high level of trust.

So much so that in some companies it can be freely downloaded and used as it is, without any significant security checks. Or to put it another way: Software downloaded from the Internet is rarely checked in the same way as software developed in-house. Do you doubt this? Ask yourself who in a company has checked Docker or libxml or even an open source database (which many applications rely on) for security problems. And even if they have: Most likely there was only a single check pass, and it's unlikely to be repeated with every update. This is a strong vote of confidence in open source.

The software supply chain

There are many reasons to choose open source technologies, but they can be broken down into three main areas:

• Firstly, open source software often waives a license fee. This is attractive if only because you don't have to deal with budget approvals or reviews at the time of allocation.
• Secondly, it is very likely that the open source technology in question has been developed by an expert in that particular field. If you wanted to employ such an expert in-house, it would be complex or expensive.
• And thirdly, open source technologies often offer a popular solution to a problem. For example, there are many options for container orchestration, but Kubernetes has the edge - meaning that the implementation is highly trusted by both experts and competitors.

What gets lost in the discussion about adoption is that open source software, just like commercial software, often consists of multiple components. There is no single Linux executable, nor is there a single Kubernetes executable. Each one requires a significant number of dependencies. The same is true for mobile applications, IoT firmware, and even simple logic functions in business applications like those deployed via AWS Lambda. They all have dependencies that are necessary for the application to function properly.

So when people talk about a "software supply chain", it is this list of dependencies that they are referring to, and it is this list of dependencies that is the biggest risk with open source.

The question of resilience

When an open source project is widespread enough to become a de facto standard, such as Kubernetes, many volunteer developers work on the code. Some companies even hire developers who are specifically dedicated to Kubernetes. That means resilience. If a developer takes a break or withdraws completely from the project, it still continues. Popular projects can therefore even cope relatively well when key developers leave.

The situation is completely different for smaller projects. There are millions of GitHub projects where the number of developers is in the single digits. And GitHub is not the only repository for open source activities. When just one developer retires, it's often someone who understands exactly why certain areas of code were written the way they are now. Such projects are most often found on the list of dependencies for an application. They often cover basic activities such as writing log data - as in the case of log4j.

Since the number of developers in open source projects varies so widely, it is not surprising that they react very differently to a security incident. Some, such as Kubernetes or the Xen project, have very well-defined security processes in line with their standing. Others treat a security problem exactly like any other bug that needs to be fixed - but rather at an unspecified point in the future. A well-defined security process is likely to link a patch to a disclosure in CVE format. Projects that treat security issues like bugs often simply fix the bug, but do not disclose it. This does not necessarily make it easier for an organization to realistically assess the risk in the supply chain and develop appropriate policies to reduce that risk.

A must: Comprehensive inventory

If you want to reduce the business risk associated with open source software, which is really a software risk, you should accept one premise: Companies benefit from open source software. Much of the business risk comes from the fact that open source software is managed differently than commercial software. The procurement and patching processes for both are different. Realistically, OSS and commercial software cannot be managed in the same way.

The author: Lucas v. Stockhausen is Senior Director Solutions and Sales Engineering at Synopsys SIG.

© Synopsys

If you want to reduce the risk, you should start with a comprehensive inventory of all software used in the company (asset management), regardless of where the software comes from and which procurement process it is based on. This inventory can be used to determine which open source components are used by the individual assets. This is done with the help of Software Composition Analysis (SCA). Software can be compiled into a binary file or be source-based. The selected SCA tool should therefore be able to process both binary and source-based assets with the same means. An asset inventory probably contains thousands of entries. It therefore makes sense for an SCA tool to actively point out changes to the security risk within the assets without the need for a rescan.

At this point, it is possible to determine how to deal with a changed risk due to a newly disclosed vulnerability. After all, it's not easy to patch something that nobody knew was there. Just as you can never be sure when new software with a vulnerable component will be created.