Open-source code is public, but are the right people looking at it?

Perceptions around the inherent security of open-source code and open-source software vary – but these perceptions matter.

On the one hand, some view open-source code as less secure. After all, there are fewer commercial incentives to secure open-source code, compared to code written by a for-profit vendor with a reputation on the line.

On the other hand, there is a view that open-source code is more secure simply because open-source code is open to scrutiny. The argument goes that this openness outweighs any commercial incentives. With more people looking at open-source code, it should make it easier to identify the flaws in open-source code.

In this article we take a closer look at the “openness” of open-source code and the security advantages this should bring – but often fails to deliver on. We’ll also examine the view that, in fact, too many of the wrong people are scrutinizing open-source code for opportunities, and too few of the right people are working to find and fix security flaws.

Content:

1. OPEN-SOURCE CODE OFFERS SOME SECURITY ADVANTAGES
2. ENTERPRISES DEPEND ON OPEN SOURCE, BUT TAKE SECURITY FOR GRANTED…
3. WORSE, THE WRONG PEOPLE ARE LOOKING AT OPEN-SOURCE CODE
4. THERE IS “GOOD” SCRUTINY, BUT…
5. Incentives and awareness

Open-source code offers some security advantages

First, there are valid reasons why open-source code is perceived as being more secure in comparison to closed-source code. There are reasonable arguments that underline why, in certain circumstances, open-source code can offer security advantages.

The main train of thought is that, because open-source code is public and open to scrutiny, more eyeballs are looking at the code. Where code is widely used it should be the case that it is more closely examined for security flaws. Therefore, the code should be more secure as flaws will be found and fixed more quickly. Though that may not be the case for code that is used in smaller projects, in code libraries or highly specialized code.

The second security advantage of open-source code is that companies that use open-source code can more quickly repair flaws before these flaws become dangerous. More quickly, in any case, than relying on a commercial vendor that may need to go through extensive testing of their proprietary code.

Viewing these two arguments in isolation can leave the impression that the open-source code is a better option because of the security advantages, but it is a point of view that misses a few key points.

Enterprises depend on open source, but take security for granted…

Almost every company deploys open-source code at scale. They may do so explicitly, by using a product such as Red Hat Enterprise Linux, or implicitly as even commercially licensed, closed-source software contains open-source.

A 2020 analysis by Synopsis found that 99% of codebases audited for the report contained open-source code. Much of this code is old too, with 91% of the code audited for the report containing open-source code that has not been updated for four years or more.

Essentially, it doesn’t matter whether your company explicitly deploys open-source solutions or not, open-source code is so pervasive that you must take the threat seriously.

Unfortunately, companies often take open-source security for granted. Either because they do not realize how much open-source code is supporting their workloads, or due to the perceived security benefits of open source code.

This is a risky approach and there are countless examples of how large enterprises delivering key services are caught out by a flaw in open-source code. One of the most prominent examples is the Equifax breach in 2017, which exposed highly personal financial records for over 147 million people.

In the case of the Equifax breach, hackers exploited vulnerable code in Apache Struts 2, a framework used by the Equifax website portal. It took the company six weeks to notice the breach, leading to a very large volume of data being stolen. For Equifax, the cost was immense, both in terms of the financial settlement and, of course, the public fallout.

The Equifax example is by no means unique. Part of the problem lies in the fact that developers will easily and rapidly pull into their applications a range of open-source capabilities. From large chunks of functionality through to individual libraries.

They would do so without real scrutiny – and often without cataloging the components. The result is that companies have little idea of what open-source code their tech solutions depend on. Yet it is almost certain that open-source code will be hiding pretty much everywhere.

Worse, the wrong people are looking at open-source code

Everyone can examine open-source code, including the bad guys. The pervasiveness of open-source code gives malicious actors the motivation to look for flaws that can be exploited.

In some cases, this hunt is simply for monetary gain – criminals want to find ways to hack into systems to steal valuable information or to hold a company ransom. Other groups ranging from advanced persistent threat (APT) teams through to state actors have specific goals that can be realized by exploiting security weaknesses.

Finding flaws in widely-used open-source code gives these actors the tools that they need to intrude on otherwise secure systems. Sometimes, malicious actors identify flaws in open-source code long before the users of open-source code or the open-source community identifies these flaws.

In other words, these security vulnerabilities are in the hands of hackers – but patches and fixes are not yet available. It gives criminals and nation-states the opportunity to exploit flaws in open-source code before the necessary patches and fixes are published.

There is “good” scrutiny, but…

It’s not that the open-source community is ignoring flaws, or carelessly writing code simply to forget about the code and where it is used. But the sheer volume of open-source code in use – 31 billion lines of code by some reports – means that it is almost impossible to thoroughly check code for errors.

In practice, we often see old flaws in open source code emerging decades after the open-source code was added to a codebase.

Take the recently discovered libcurl bug that was disclosed in April 2021. The underlying code was added to the codebase in August 2000 so it’s taken more than twenty years for the vulnerability to become public. There is no way to tell which malicious actors had knowledge of this vulnerability across the last few decades, and what they did with this knowledge.

Likewise, the bug behind the widely publicized Heartbleed exploit was found 15 years after the code was originally included in the OpenSSL libraries. Again, there is no way to know who else may have known about this vulnerability before it saw the light of day.

It simply comes down to the fact that the good guys are not spending enough time looking at open-source code. Yes, there are efforts to secure open-source code. But these efforts are not a like for like match against malicious actors that are systematically examining code to find exploitable flaws.

Incentives and awareness

The incentive problem around finding weaknesses in open-source code is known to the open-source community, to security experts and to vendors that rely heavily on open-source code. As such, there are programs designed to incentivize open-source developers to find errors in code.

The EU’s bug-bounty program, for example, offers up to EUR 25,000 for developers that find vulnerabilities in specific open-source projects. The Linux Foundation also made a number of recommendations in its 2020 free and open-source contributor survey, in part because that survey revealed that open-source developers find fixing security problems a soul-destroying task.

But incentives will never plug the motivational gap between criminals, threat actors and the open-source community. That’s why awareness matters.

For enterprise users, the first step is to acknowledge that open-source code is everywhere. Buying software from commercial vendors that use proprietary code is not an insurance policy as this code most probably relies on open-source code such as open-source libraries. Yes, commercial vendors have a bigger incentive to secure code, but in reality both proprietary code and open-source code will remain vulnerable.

Another key step is to remain responsive. When a flaw is discovered in open-source code a patch or some other method of mitigation usually follows rapidly. Companies must patch fast and thoroughly and where this is difficult to do, consider using live automated patching tools that do the heavy lifting – without the disruption.

Finally, enterprise security will always be about security posture. It can make the difference between rapid mitigation of an attack in progress and a public apology six months later. Making broad assumptions about the public scrutiny of open-source code will never benefit secure operations.

To wrap up, it is hard to definitively say that open-source code is more secure or less secure than closed-source, commercial, proprietary code. The argument is simply more complicated than that. There are countless flaws reported in proprietary closed source code as well. Just don’t assume code is more secure simply because it is open. In and of itself, that guarantees nothing. It takes significant effort, the right incentives and the technical know-how to secure code, not just access to the source.

Companies should remain aware that yes, open-source code is often rapidly patched and highly secure due to its open nature. Yet, on the flipside, open-source code can also hide vulnerabilities in plain sight – for decades on end.

Continue reading: OPEN SOURCE: ENTERPRISE-GRADE SECURITY WITH OPEN CODE?