What are Open Source Security Challenges and How to Avoid them?

 The use of open-source software is a common way of web/mobile application development that benefits both the companies and the broader development community. It is one of the driving forces of technological progress. However, the openness it provides also brings its own set of challenges you need to be aware of. 

In this article, we will explain the significant challenges of applying open-source software and the ways of avoiding them.

What are open-source security risks?

Exploits in software applications are a natural occurrence both in open source and proprietary products. These exploits present possibilities for a hacker to shake things a little and compromise the security of the system.

These things can range from mistakes and oversights in the code to full-blown backdoors used to monitor and test applications (NSA loves that stuff). 

While proprietary products are relatively safe and under wraps, open-source software is under threat. 

You might think, “if things are so rough – then why bother using open source software at all?”. Here’s why.

In one way or another, software development revolves around open source products. Some companies don’t even understand how many different open-source tools constitute their products. 

The list includes: 

• Code libraries (NLTK)
• Operating systems (Linux)
• Various software applications for different use cases (performance testing tools, DLP, development frameworks, etc.)

According to a study by Synopsys, up to 96% of commercial software applications contain elements from open source in their structure. 

Why is it so? There are three reasons:

• Cost-effectiveness – there is no point in reinventing the wheel when it comes to software development. Making your own tools for a project can take a significant chunk of time. There many different libraries and tools available in open-source that can handle the majority of development needs.
• Flexibility – the variety of open-source tools provide enough room to figure out the best possible configuration for the project.
• Speed – working with already existing tools saves time for mastering the tools and testing the possibilities, and instead, lets the team focus on the development process entirely.

The most common results of taking advantage of exploits are security threats like Data breaches and Denial of Service attacks. 

• Data breach – when sensitive information is accessible to an unauthorized third party
• DoS – when the service is shut down, overloaded or otherwise impossible to use correctly.

Open Source Security Risks to Be Aware Of

Exploits are out in the open

One of the prerequisite features of an open-source project is that its code is available to the public. The availability of the code is one of the major driving forces for the rapid evolution of an open-source project. Any member of the community can contribute in some way, including identifying emerging vulnerabilities before others can exploit them maliciously. Hackers can do that. Given the fact that open-source tools may serve as a backbone for the product – this nuance creates a significant concern.

The handling of the open-source security risks is more or less a question of time. Either you get there first, and update the code, or this will be a cybercriminal who will gladly mess with the system.

National Institute of Standards and Technology (NIST) maintains the National Vulnerability Database (NVD) that keeps the developer’s community on the same page regarding the state of security in various applications.  The database includes all reported exploits found across multiple software applications. As such, it is a community’s way of keeping threats under control. NVD is an excellent source of information.

It is important to note that among the people who like to surf it is hackers. They tend to take note of the exploits, especially those that are yet to be fixed by the project development.

The most prominent example of taking advantage of an open-source exploit is the 2017 Equifax hack. The hackers found out that the system was using a version of the Apache Struts framework with several reported and unfixed exploits. This discovery led to one of the most significant reported data breaches. 

Possible infringement risks

The thing with open-source as a concept is that:

• it is a contribution to the community first; 
• the product second. 

Because of its free-for-all status, open-source does not operate under standard commercial regulations. 

This vagueness creates an underlying issue as open-source tools may contain elements of the proprietary code, i.e., somebody else’s intellectual property. 

On its own, this is not an issue in the open-source product itself. It becomes an issue when the open-source applications, with the unregulated segments of the proprietary code, are used in the development of the commercial product

One of the most prominent recent infringement cases is IBM v. SCO Group. Here’s what happened: in 2001, IBM had released an operating system called “Project Monterey.” It contained elements of UNIX System V code owned by SCO Group under a standard license agreement. At the same time, IBM had contributed sections of the Project Monterey with elements of UNIX System V code to the Linux kernel. 

This led to a long-running lawsuit from the SCO Group. The company claims that the alleged presence of the proprietary code in the open-source was a case of misappropriation of trade secrets that: 

• devalued their product; 
• caused unfair competition; 
• ultimately led to the company’s bankruptcy. 

As a result, they sought billions in compensation. 

That’s an extreme case, but it is a good illustration of possible consequences. How to avoid this kind of situation? 

• Proper due diligence of the open-source tools is the best way of keeping things under control. 
• Supply chain component analytical tools like DependencyTrack can automate the majority of the routine and let you react swiftly to any possible problems. 

Managing Licenses

The other issue that emerges from a lack of commercial regulations of the open-source software is the license conundrum.

Here’s why. The development of proprietary software often involves numerous open-source elements – libraries, frameworks, tools, etc. These elements are released under different license types (for example, Apache license for data processing frameworks) with distinct compliance requirements. 

As a result, the proprietary application gets entangled in the net of different licenses, all of which need full compliance. Non-compliance puts the company at risk of legal action, which is damaging for reputation and financial resources. 

An excellent example of the consequences of open-source license non-compliance is the recent case of Panasonic Avionics Corporation v. CoKinetic Systems Corporation. 

• CoKinetic claims that Panasonic had intentionally ignored the General Public License to hold back the competition.
• The thing is – Panasonic in-flight hardware uses a Linux-based operating system, which adheres to GNU General Public License. 
• One of the requirements of this license says if the GPL-licensed tool is used to develop a piece of software, this application requires a release in open-source under the same license. 
• Panasonic hadn’t done that, and from the perspective of CoKinetic, it blocked the competition and monopolized the market. 

The lawsuit is nowhere near protecting community standards. In reality, it is messing with the competition, as a kind of attempt to disrupt the workflow and damage the credibility of the company.

How to avoid this issue from happening?

• License tracking is a dubious routine that requires transparency and caution. 
• You need an excellent DevOps engineer to handle it and keep it intact. 
• The primary tool to keep open-source licenses under control is software composition analysis apps like Blackduck, SourceClear, and WhiteSource. 

This combination provides a full view of the software components used in the application and allows you to manage any emerging licensing issues with relative ease.

Operational Inefficiency

Operational inefficiency is one of the biggest technical challenges that come with open-source software. 

The chain of events is as follows: 

• you are using a version of a program for some purpose; 
• someone reports on the new exploit; 
• the latest update is pending. 
• the emergence of an exploit creates a security risk, and you need to react swiftly.

Here’s where the challenge comes. 

There are higher priorities to take care of when it comes to software development. You need to get the thing working, optimize it all the way through, fix bugs, and handle glitches. Things like open-source software updates, and emerging security risks, usually slip away in the heat of the moment for the sake of more important things. 

That’s how the Equifax leak became reality.

How to avoid this problem? 

• Provide transparency of the development inventory to keep the team on the same page regarding the state of the toolkit.
• Use software composition tools to streamline the management process and implementation of updates.
• In case of abandoned or infrequently updated open-source tools (which happens all the time), the developers need to fix the issue on their own. 

Faulty code copy-pasting 

The development process consists of routine operations. Code copy-pasting is one of them. While it is a standard operation on its own, it is what is copied and pasted that can create a significant security threat. 

The thing – developers often copy-paste the code directly from open-source libraries. As was previously mentioned, there is a chance of having an exploit inside a copied code. That is one part of the problem.

The other part of the problem is that once the code snippet is in the codebase – it is a part of an application. It is hard to update that particular snippet, and remove the exploit after the fact, without disrupting the workflow. In other words, it is like shooting yourself in the foot.

The solution to this problem is simple. 

• You need to forbid any direct copy-pasting from open-source repositories and insist on mandatory code reviews before implementation. 

What’s next?

These are all of the significant open source security challenges you need to be aware of to avoid getting into trouble.

These days the issue of transparency and trust between the company and the user is at its peak. If the company wants to establish their product as trustworthy in the eyes of the user – the use of open source security is one of the surefire ways of showing that. 

On the other hand, going open source paves the way for the further evolution of the product – the refinement of existing features, fixes of flaws, and addition of new elements.