How to Safely Use Third-Party Code in Your Applications

In the early days of computing, it was customary for developers to write utilities and applications entirely from scratch. Many of us with old-school computer science degrees would often use what we learned in our data structures or algorithm classes to write tree traversals, linked list management or sorting code. It did not take long for each developer to build a personal library of frequently used routines.

I worked in database applications a lot in those days, and I built my own data browser with updating ability, specifically for the Progress 4GL environment. I tweaked and extended this browser include code for several years to fill the needs of many clients.

After investing the time developing these general utilities, many of us wanted to share our work with others. It was common for developers to share their favorite libraries with others via bulletin boards or other burgeoning online resources. That’s how third-party code was born.

Third-party code is any code written by an external entity that a software application includes in its software products, from a parameterized include file to a robust library. Regardless of the method used to integrate the software, the presence of third-party code means that an application relies on some amount of code that someone outside the development organization wrote.

Consequently, there is always some inherent risk in using third-party code, but there are ways to reduce that risk.

Reliance on third-party code is rising

In today’s development environments, complexity, time to market, and economy tend to drive development efforts. In other words, software developers are expected to create products that meet complex demands while doing so quickly and for as little cost as possible. To meet the quick turnaround times and low-cost demands, many organizations embrace third-party code. 

The advantages of third-party code are numerous. Another organization has already invested the time and effort to create functioning software. Avoiding having to recreate the wheel for each new software project increases development speed. As long as the functionality matches your needs and the price is right, third-party code can noticeably accelerate your software development projects and help curb cost.

According to the latest Veracode State of Software Security report, 97% of typical applications written in Java are made up of open source libraries. That means only about 3% on average of the code in most Java applications is original. That may sound odd, but nearly all of today’s applications are built on layers and layers of libraries.

Inclusion of any third-party code places a software application at the end of a supply chain. Providing software with third-party elements means that your organization’s software product is dependent on the quality and performance of external components.

Third-party code increases attack surface

Although there are many proven benefits to incorporating third-party code into the development process, including other people’s code includes their vulnerabilities and weaknesses as well. Third-party code generally falls into open source and closed source variants. Open source code is externally created software for which the source code is easily available. Closed source code is only available in compiled or object code formats.

Organizations that use closed source third-party code have no access to the source code for the software that is part of their application. This lack of visibility into third-party source code makes assessing that software for vulnerabilities more difficult.

Both open source and closed source code risks the inclusion of vulnerabilities. Many vulnerabilities have been discovered in popular libraries used in other organizations’ applications. For example, an article from The Digital Lifestyle described the Heartbleed bug, which was a bug in the popular OpenSSL library. When the Heartbleed bug was discovered, it meant that nearly every software application that included the OpenSSL library was vulnerable. Many software development organizations scrambled to deploy fixes to protect their customers.

Regardless of the application, including other people’s code increases your own application’s attack surface. That is not to say all third-party code is sloppy. Some third-party code is developed with very high security standards. The problem is that you do not know what standards another development organization uses, or how well they implement those standards. Always treat third-party code as insecure until you can demonstrate otherwise.

Steps to harden applications that include third-party code

The best approach to including third-party code in your software applications is to treat each use of third-party code as a distinct risk. If you manage that risk well, you reduce your organization’s exposure to damage.

Here are a few steps your organization should take to limit exposure to security threats while leveraging the utility and value of third-party code:

• Assess all third-party code for vulnerabilities before including it in your application. Research known vulnerabilities for third-party products your organization uses, and include security tests for all included code into your overall testing strategy.
• Scan applications periodically to identify third-party code and find any vulnerabilities. After the initial vulnerability assessment, you will miss newly introduced vulnerabilities unless you periodically conduct reassessments of all third-party code. The Kiuwan Insights Software Composition Analysis (SCA) product scans application code for open source dependencies and identifies any known vulnerabilities. Insights SCA also helps to remediate any identified vulnerabilities before you deploy them to your customers.
• Integrate automatic internal and third-party code scans. Static application security testing (SAST) can help identify vulnerabilities in source code for both in-house and third-party open-source libraries. Make SAST scans automatic for ongoing assurance of security and compliance.
• Implement a zero-trust security model for third-party code. As much as possible, limit how much your application trusts third-party code and avoid using third-party code for handling sensitive data.
• Limit the use of third-party code. Avoid using third-party code just because it is easy. Use it when it makes the most sense. Since your organization essentially outsources security and compliance when including third-party code, use it sparingly. This approach may result in more work for your developers, but it maximizes your organization’s control over risk.

Implementing each of these steps will not make your application immune to third-party security risk, but it will put you into a much better position to proactively manage any vulnerabilities.