Open Source Security Risks to Know in 2019
Published: 2019-05-15 18:57:15

---
title:Open Source Security Risks to Know in 2019
published: true
---
It is widely agreed upon that information technology operations need to turn an even more watchful eye to open source in 2019. Thanks to the growing popularity of open-source platforms such as Kubernetes and Docker, more than 3.5 million applications have now been put into containers using Docker. According to Docker, 37 billion containerized applications have already been downloaded. 

This goes to show that open source will move under a brighter spotlight. Not surprisingly, open source has not only held on to its spot as being the most popular operating system within Enterprise IT, but even more, growth has been predicted. According to [Red Hat](https://www.redhat.com/en/blog/red-hat-continues-lead-linux-server-market), Linux has managed to maintain more than 30% share when it comes to global server operating systems. This puts it just behind Microsoft's Windows Server in terms of adoption. 

Additionally, Linux is the lone endpoint operating system that is growing across the globe. This was revealed as part of an IDC InfoBrief sponsored by IGEL in August 2018. According to an industry report, the popularity of IoT-based devices is predicted to expand the use of Linux as a large number of virtual appliances are based on Linux. One of the reasons quoted was that distribution endpoints for Linux-based devices could be modified to provide direct updates with patches undergoing endpoint developer testing for stability. This has boosted confidence in security and optimization in terms of performance.

**Some Common Open Source Vulnerabilities of 2018**

**Glibc**
February of 2018 saw the critical flaw in the GNU C library exposed. The powerlessness of open source security spread to all Linux-based servers as well as web structures such as Python, PHP, Rails and other API web administrations that make use of the GNU C library. 

The flaw allowed programmers to access applications using a ‘man-in-the-center' assault. This increased the probability of hackers being able to take over a client's framework.

**Quadrooter**
Quadrooter was another open source weakness that turned Android-based phones vulnerable and allowed anyone to expose them to an application containing malware. The hacker was able to access the root of the device by misusing any of the vulnerabilities. 

This put every framework substance and controls like mouthpiece, counting touchy information, GPS as well as framework changes vulnerable to assault.  

**Zero-Day Linux Kernel Vulnerability**
The zero-day Linux Kernel vulnerability was another assault that impacted every Linux adaption that 3.8 or higher. It also influenced 66% of all Android-based devices. When the bug was abused, the hacker was able to access the root of the vulnerable user's OS.

**Critical MySQL Database Vulnerability**
The critical MySQL database vulnerability affected each version of Oracle's MySQL Database that was accessible. It was also able to clone PerconaDB as well as MariaDB. 

This vulnerability assisted hackers to get unrestricted access to the server through malicious settings injected into MySQL setup documents.

**Potential Risks in 2019**

**AI Powered Malware**
Earlier, attackers kept up communications with vulnerable systems by way of ‘command-and-control' servers (C2). In the situation that malware can use AI to determine ways to mimic normal behavior, hackers would no longer have the use for C2. The malware could potentially also become more robust to detect.

**Smart Phishing**
Artificial Intelligence also has the potential to boost phishing attacks where an email or similar message from a seemingly legitimate source is used to entice the receiver to provide sensitive information. A survey conducted by [CyberArk Global](https://www.cyberark.com/resource/cyberark-global-advanced-threat-landscape-report-2018/)found that 56% of 1,300 information security related decision makers were of the view that targeted phishing attacks were the leading security threat faced by their organization. 

**Vulnerable Critical Systems**
Critical national infrastructure contains systems whose operations are essential to a nation's security, the country's economy and the safety of its citizens. A fair amount of critical infrastructure is managed by automated industrial control systems. A good example would be in areas of manufacturing and energy. 

According to Kaspersky Lab's State of Industrial [Cybersecurity Study](https://go.kaspersky.com/rs/802-IJN-240/images/ICS%20WHITE%20PAPER.pdf),
31% of individuals responsible for the management of these systems faced an information security related threat during the past year.

**Tips on How to Secure Your Usage of Open Source**

**Develop & Implement Policies Around Open Source Usage**
Some organizations woefully lack even the necessary documentation on open source strategies. Organizations need to have a single responsible person or body entrusted with the management of open source usage. Well documented policies will help developers in their duties when it comes to how best to make use of open source software.

**Actively Monitor for Fresh Risks when Using Open Source Software**
Given that there is an average of more than 3,500 vulnerabilities related to open source uncovered annually, the task of following each vulnerability is never-ending. It does not stop once the applications are out of the development stage. As long as the application is publicly available, organizations need to monitor it for new risks continually. 

To make this happen, you can use the tools available for your repository. For instance, there are tools associated with NPM, Python Package Index, Ruby Gems etc. that help you find issues with your code and your dependencies. Furthermore, there are independent open-source packages like Dependency Check by [OWASP](https://resources.whitesourcesoftware.com/home/owasp-dependency-check), OSSIndex, [Bundler-audit](https://github.com/rubysec/bundler-audit) etc. that identifies vulnerabilities by checking your code against public and private vulnerability databases. 

Additionally, given the increase in the number of security breaches, many organizations are considering security testing as a critical part of a system's development lifecycle. 

**Maintain an Exhaustive Inventory of Open Source Being Used**
Organizations should make it mandatory to maintain an inventory of all open source components being used by various teams in the company. A robust open source inventory needs to incorporate –
- Every open source component being used
- The version of each element
- The download areas for every relevant project
- The person responsible for the specific project

Similarly, the inventory should also include all relevant conditions including the libraries that are being by the code and the potential libraries that the states are connected to. 

**Be Cognizant of Other Open Source Software Related Concerns**
The failure to be aware of licenses associated with the usage of open source software can expose organizations to a considerable danger of dispute over intellectual property that might lead to costly financial ramifications. 

Similarly, the use of low-quality or obsolete, outdated open source components can negatively impact the quality as well as the performance of the applications that use them.

**Conclusion**
The use of open source software within an organization is much more than just downloading and executing a free-to-use program from a website. Different security concerns beg consideration. These need to acknowledged and analyzed before an organization proceeds with adopting any open source software.  

That said, open source should not be misunderstood as a boundary to security. Instead, when used wisely, it can further strengthen security by adding many individuals as part of a community that can help in uncovering bugs and other vulnerabilities.