Table of Contents:

Ensure Your Open Source Software Usage Won’t Make You the Next Cybersecurity Victim

Software Vulnerabilities Within Your Supply Chain

Finding Potential Software Supply Chain Risks in Code Repositories

RunSafe Can Keep Your Supply Chain Secure

Open source software is widely used across various industries and applications. Some developers estimate that more than 80% of the code in a software delivery is open source code. Open source code is helpful for developers because it can be more efficient to reuse code and reduce the amount of work needed to be done.
In many cases, open source software is more secure than proprietary software. This is because a broader set of contributors are testing and fixing code without limiting budgets that may affect the code quality of proprietary software. With that said, not all open source software is mature let alone secure. As such, it is also imperative to thoroughly understand the open source software used your products can pose security risks, if not tracked and monitored.

Software Vulnerabilities Within Your Supply Chain

Hackers are able to find any open source software repository used within an application with ease through platforms such as GitHub and GitLab.

As a result, hackers are able to analyze and attack areas of vulnerability. Understanding how to mitigate this risk is critical in order to prevent hackers and maintain the integrity and security of open source software. 

At RunSafe Security, we wanted to understand the levels of maturity of open source software and the potential areas of risk while recommending ways to protect your software assets—all without breaking the bank.

Finding Potential Software Supply Chain Risks in Code Repositories

We set out to analyze several open source code repositories across GitHub and GitLab and understand factors that could identify potential risk in code. Our preliminary research shows that some of the numerous risk factors include the contributors, date/age of the software, and the geographic location from which a contributor works.

Our Initial Hypothesis

Using ParseHub, a web crawling tool, we collected data from over 450 repositories. Our initial hypotheses including the following:

1. Individuals that have contributed code to open source software for many years are much more trustworthy than those who have recently joined. This is due to the fact that they have been with the software for many years and most likely do not intend to create any potential vulnerabilities. Furthermore, these contributors have a track record of delivering code without nefarious intent.
2.  Repo contributors that include their location and company can be observed to be more reliable, specifically if the company is one of which is reputable or well known. As an example, some contributors mentioned that they worked for Red Hat or Microsoft, both reliable and notable companies.
3. If a repository has versions that are consistently released, the repository can be seen to be more secure as constant updates are being made. These updates allow for any issues and vulnerabilities to be solved, reducing the amount of risk in the open source software.
4. Repositories with a high amount of stars can be seen to be more reliable with practically fewer vulnerabilities. This is due to the fact that a multitude of people are following the repository and are interested in it. Thus, the repository is usually more credible.
5. The date of the last commit can also aid in recognizing vulnerabilities. A repository that has been updated recently can be seen to be active in use with contributors continuing to develop itIn contrast, repositories that were last committed years ago are more likely to have vulnerabilities and hackers attack them. This is due to the fact that there are not constant updates being made of the repositories and the code is staying the same, prompting hackers to find and attack areas of vulnerabilities.

Overall Findings

Our data findings suggest software maturity practices and maturity are helpful to understand but likely insufficient to predict where attacks could come from.

• Most repositories with a high number of stars also had a high watch count and fork count. In addition, many of them had multiple versions.
• A large number of the repositories with over a thousand stars had commits dated recently. Comparatively, their repositories with fewer than 1,000 stars typically had their last commit several months if not years ago.
• All of the repositories had fewer than 800 contributors. The number of contributors did not seem to have a large effect on other factors, such as the star count. There were many repositories that had a few contributors, fewer than 5 in some cases, but still had a large star count.

How to Protect Your Software Supply Chain

Overall, our efforts to understand risk within your software supply chain led us to find straightforward ways to protect your software, including:

• Build from a trusted repository and verify you are working from the same version published by the open source repo.
• Add software hardening into your builds when you are using open source software. By using RunSafe technology, for example, you can eliminate the exploitation of an entire class of vulnerabilities – namely memory-based vulnerabilities—so that you are protected even if a vulnerability exists and a fix is not available.
• Update your software versions on a regular basis. Yes, it is expensive to update software because changes may impact other components and may necessitate additional testing and compatibility checks, but the alternative is to chase your tail after an attack. Notably, you can add protections in with RunSafe to help smooth out when these updates need to be applied because you will often be protected from the most devastating and common types of attacks (memory-based ones) on open source software.

RunSafe Can Keep Your Supply Chain Secure

In conclusion, open source software has tremendous benefits operationally and security-wise. However, you need to monitor your entire software supply chain to reduce risk of exploitation. Though there are indicators that will help you avoid some attacks, adding security protections to guard against memory-based exploits should be used so you can streamline your software development processes and your security practices.