How can you ensure that your open source components are secure?

The use of open source libraries and 3rd party components in assembling software has increased considerably. These days, a typical web application may have over 90% of its functionality implemented using open source components, while the custom business logic may be less than 10%. This means that most of the attack surface of an application consists of open source components. Some of the risks associated with usage of open source components like known vulnerabilities and licenses are well understood but I have noticed that many developers still fail to appreciate the scale of the problem. In this article, I will summarize some of the work we did at SourceClear in the past year to improve the state of the art in open source component security.

New vulnerability types

I am sure you are familiar with the OWASP Top Ten list of vulnerabilities which includes A9-Using Components with Known Vulnerabilities. Thus, you should always be careful of known vulnerabilities while using open source components. However, it is extremely difficult to keep yourself up to date and track new issues in libraries. The public databases like NVD/CVE are inadequate as they only have a very small percentage of total vulnerabilities. The SourceClear Registry is the only complete and accurate database of vulnerabilities in open source libraries. In addition to the public known vulnerabilities, we include information about the following new vulnerabilities types that are specific to open source components.

• Half Days: Developers are notorious for doing silent patches to fix security issues in open source software. These undisclosed vulnerabilities and fixes may not necessarily be new but unless you are aware of the problems in the components you are using, you will not be as inclined to update them. Earlier this year, we open sourced commit watcher to enable anyone to identify such issues in their own projects. Since then, we have worked on machine learning and natural language processing based techniques to detect half days using a variety of structured and unstructured sources like bug reports, change logs, e-mails, commit logs, web pages, tweets, gists and many more.
• Copy-paste Vulnerabilities (CPV): Open source components promote reusable code, unfortunately, reusable code also leads to reusable vulnerabilities. Copy-paste vulnerabilities are a new class of issues that affect open source software. We have found all kinds of such issues in the wild where entire vulnerable libraries were copied, or, some vulnerable files from the library were copied, or, some vulnerable code from a particular file in the library was copied, or, some vulnerable code was ported to a different language. Given how prevalent copy-paste code is in open source components, it is important to identify and detect CPVs.
• Embedded Vulnerabilities: Most but not all of the open source libraries used in your application are going to be declared using dependency managers. There are several cases where the open source component is embedded in your application directly, e.g. it may be a Jar file that is available on the class path, or it may a runtime library. Thus, it is important that to identify such embedded vulnerabilities as they are directly related to use of open source components.

Patching components

Identifying a vulnerable component is just the beginning of managing your overall open source risk. You need to clearly understand what your options are once you know that your application is using vulnerable dependencies. When it comes to patching vulnerable open source components you can use the following to help you decide:

• Vulnerable Methods: Just because you are using a vulnerable library, it does not mean that your application can be exploited using that vulnerability. Vulnerable methods are a way of providing more detailed information about the vulnerability using static analysis. We can tell you if you are calling the vulnerable methods of the open source component to validate that you are exposed to the vulnerability. As it turns out, 9 out of 10 times a vulnerable open source component is used in an application, it is not directly exploitable.
• Safe Versions: The usual remediation for component vulnerabilities is to upgrade to the fixed version of the component. But if that version is itself vulnerable then you just keep on going down the rabbit hole without making any progress to reduce the risk. Instead, it is much better to think of safe and unsafe versions of the open source component that can be used to patch your application based on the particular version that is already in use. E.g. the following table illustrates how a given library may have several safe versions across different ranges (v5-v6, v11-v12, v20-v22 and v27-v29).

Beware of library-based malware

Vulnerabilities are one of the most important risks associated with open source components, but they are not the only one. Another issue which is likely to become more prevalent in the coming year is the rise of library-based malware. We have built proof of concepts for the following kinds of attacks based on open source components:

• Ransomware: The total amount paid by businesses to ransomware crossed over 1 Billion USD this year. We have already seen attackers use novel attack vectors like IoT devices and social media to spread ransomware. Open source components present another potential vector for attackers to use against developers and infect business or enterprise applications.
• Backdoors: Most open source components are installed during the build process by the dependency managers. As all build systems allow command execution, it is very easy for attackers to build backdoors in open source components that are installed when the application is built.

Earlier in the year, we open sourced build inspector, a forensic sandbox for continuous integration environments. It allows you to inspect the network, file system and process changes during the build to detect potential malware activities.

I hope I was able to highlight some of the subtleties in managing open source risk based on my experience of research we have done at SourceClear. Now that you have a better understanding of the problem, what do you think about it? How do you manage and secure open source components in your own application? Do let me know in the comments below. Until next time, keep calm and code on!