Software projects are becoming increasingly complex. As organizations expand their online presence through web applications, mobile apps, and other software, they become more and more reliant upon open source and third-party code to implement critical functionality.
However, this external code can contain vulnerabilities, and these vulnerabilities are often passed along to the applications using it. The GitHub Security Lab project is designed to help reduce the instances of vulnerable code by performing large-scale analysis of projects on its platform. However, this program won’t catch everything so it's necessary for organizations to take other steps to manage their supply chain risks, including deploying solutions for identifying and blocking potential attacks like runtime application self protection (RASP).
Supply Chain Threats of Open Source Code
The use of open source code and existing libraries is widely considered best practice for developers. In general, most of the commonly used third-party code that is imported into a software project implements complex or common functionality. By using a trusted implementation of the code, an organization can reduce development time and likely is using a better and more efficient implementation than they would produce in-house.
Another common argument in favor of open-source code is that, with access to the source code, anyone can review it. This allows developers to identify functionality bugs, potential vulnerabilities, or embedded backdoors and to have them corrected before using the code. This is typically not possible with closed source code, where the developer only makes a compiled version of the code available.
However, while code analysis is possible with open source code, that doesn’t mean that most organizations perform it. In fact, 40% of developers say they don't perform software composition analysis (SCA) at all. The purpose of SCA is to identify vulnerabilities in a program’s dependencies. Failing to perform any analysis at all means that developers are using open source code as it is.
In some cases, this is acceptable. Some code that an organization imports into its projects will be commercial products of companies or the product of strong open-source communities, like the Linux Foundation. While this code can definitely contain bugs and vulnerabilities, it is likely that the developer has performed at least some rudimentary testing.
The same cannot be said for all projects on GitHub, Stack Overflow, and other open source code repositories. Many commonly used code snippets or projects are developed by amateurs and have undergone no formal review process. Since many developers simply “copy and paste” code from these sites to solve specific problems in their code, they are likely to introduce bugs and exploitable vulnerabilities into their products.
GitHub Security Lab
GitHub is the biggest repository of open source code in existence. The primary function of the platform is to act as a distributed version control system, allowing many developers to work on a project in parallel in an organized way. However, the fact that projects can be made publicly visible on the website has led to it becoming a site where developers commonly post their code to show off their expertise or make it available for reuse.
The fact that a large percentage of this code contains bugs, and even exploitable vulnerabilities, is well-known. There is no formal review process before code is pushed to GitHub, so the site contains a large amount of shoddy and vulnerable code. However, the GitHub Security Lab project is working to fix this.
The GitHub Security Lab program is a coalition of security researchers from a variety of different companies. These organizations have acknowledged the importance of open-source code for modern development and have in some way contributed resources to the project.
The GitHub Security Lab project is intended to provide a scalable approach to vulnerability discovery and remediation in code posted on GitHub. GitHub has released an open source tool called CodeQL that allows security researchers to write queries that run in code. By developing a CodeQL query that uniquely describes a particular vulnerability, security researchers can scan the entire GitHub codebase for instances of that vulnerability in code. As the library of CodeQL queries on GitHub grows, software bugs and vulnerabilities in code on GitHub will become rarer and easier to detect.
Securely Using Open Source Code
The use of open source code and third-party libraries is encouraged as part of making software development more efficient. “Reinventing the wheel” every time will only result in code taking longer to create. It is also likely to produce lower-quality code since developers may not be experts in code optimization and every type of functionality that they may be called upon to write. Using high-quality code developed by someone with expertise in the field is almost always a good idea.
However, verifying that code is “high quality” can be difficult. On GitHub (and similar sites), it can be difficult to differentiate between a high-quality project and bug-ridden code without in-depth code analysis. As software contains more and more external dependencies, most organizations don’t take the time to perform this in-depth analysis.
The GitHub Security Lab project will help with this, but it won’t be able to identify and eliminate all vulnerabilities in third-party code. To reduce exposure to supply chain vulnerabilities, organizations should deploy security solutions like runtime application self-protection, which wraps around an application and can identify and block bugs and attempting attacks by identifying abnormalities in the application’s inputs, outputs, and behavior.
