Third-Party Libraries – When the Angel becomes the Devil

Securing the Software Development Life Cycle

Third-party libraries are necessary evils; they offer domain expertise, faster development and cost benefits in application development. It is not surprising that roughly 80-90% of all applications are comprised of third-party libraries and that 50-60% of the code in an application comes from third-party libraries. They are unavoidable because they make the product development process more efficient and speed time-to-market.

However, there are always two sides of a coin. To understand the other side of the coin, let me begin with a story about a recent incident.

A couple of years ago, I worked on a project for a telecom company. The company was acquired by a major software company, that was looking to gain entry into the telecommunication industry. Before the acquisition, the company used third-party libraries without being careful enough,  in many of its products. However, this proved to be a bane when the acquiring software company completed the acquisition.

Subsequently, the new parent company engaged with Aricent to reduce third-party usage due to security and legal complications. The Aricent team devoted a significant amount of time and effort on software remediation rather than roadmap features, which impacted the business adversely for many products as competitors started eating into the market space. The consequences and costs of using third-party software libraries can be high and if not corrected can threaten the business.

The situation is grim, even today

Despite a plethora of information already available on how to develop secure software, we continue to encounter vulnerabilities. The reason lies in a lack of understanding in using third-party libraries, which presents a risk to enterprise security. It puts the organization at risk when it uses tens of thousands of lines of code that were not written by the internal team and perhaps never passed mandatory quality checks.

Lately, attackers have been focusing on applications directly instead of servers and operating system because applications are an easy route to gain access to sensitive information. While most critical vulnerabilities in third-party libraries are often disclosed as common vulnerabilities and exposures (CVEs), the applications that use them are not updated promptly, often resulting in vulnerability getting exploited by attackers.

Here are two popular examples of security vulnerabilities that are found in many common third-party libraries:

1. Heartbleed: A very widely used library called OpenSSL was found to have a catastrophic vulnerability that allowed hackers to obtain encryption keys used for secure web communications.
2. GNU C Library: A domain-name lookup function known as getaddrinfo() contains a buffer overflow vulnerability that could cause a system crash or allow attackers to execute malicious code remotely.

Third-Party Libraries – The Risks

Using third-party libraries brings with it lurking dangers. Your “friend” that you have become so dependent upon may become untrustworthy and turn into a foe of your application. This is as true for paid libraries as it is of free libraries. Here are four common sources of vulnerable code:

1. Botched Responsibility: There is no assurance that security is being addressed properly and no surety on timelines for a patch in case a vulnerability is discovered. There is no reliability that the provided patch is tested properly or if the patch creates another set of problems.
2. A Myriad of Libraries: Sometimes you use hundreds of libraries in your application and managing them is a hassle. A lot of outdated libraries can crack well-crafted defenses of your application. The challenge is knowing where to look and what to fix, which only adds to the confusion.
3. Risk of Malicious Intent: The integration of third-party libraries without due diligence can sometimes introduce the risk of malicious intent. It is possible that unethical developers could infuse malicious code e.g. Trojans into the library.
4. Open Permissions: Typically, open permissions, input validation and representation errors or vulnerabilities in security top the list of the most common vulnerabilities in open-source libraries.

How to live with third-party libraries

Can you do without third-party libraries? It’s difficult to imagine. You can’t go back and re-invent the wheel because you’d risk lagging behind the competition. Use of a significant amount of open-source software is a fact of life in today’s enterprise-application environment. To maintain the risks at an acceptably low level, organizations should consider both technical and procedural controls, such as:

1. Dedicated Teams: Managing third-party libraries is not an isolated task. You must have a dedicated research team that examines the database regularly. The frequency of third-party library checks against the database should be high.
2. Robust OSS Policy: Often big software companies have separate corporate security teams that formulate and enforce security policies so the third-party software acquisition process should be robust and well defined.
3. Training: Developer awareness training regarding the risks of open-source software should be a mandatory part of the software development life cycle.
4. Security Audits: This is essential for any open-source software in use.
5. Software Repository: Create and maintain approved internal repositories of open-source software and restrict the downloading of non-approved software.

Taming the beast - Best practices in using third-party libraries

They are here to stay so you need to learn to manage them. For this, you should follow the practices detailed in Figure 1 scrupulously.

Third-Party Libraries – When the Angel becomes the Devil
Figure 1: Best practices in using third-party libraries.

The best practices outlined in Figure 1 are not the be-all and end-all for managing third-party libraries. Companies should use them as cues and clues to handle the consequences of using the libraries. Aricent has adopted industry best practices and developed a robust policy-based system for managing third-party libraries based on our deep experience with clients. We are ready and willing to provide evaluation and remediation services to help companies avert becoming the next Yahoo.

About the Author


Gaurav Agnihotri
Principal Systems Engineer

Gaurav Agnihotri, is a Principal Systems Engineer at Aricent having 14 years of experience in Telecommunication industry with expertise in network monitoring and analytics. He has been leading various software development teams in multiple products for a leading telecom company and contributed significantly in their network monitoring and analytics solutions. He has strong background in GSM and LTE core network with rich experience in developing VAS applications. He is passionate about developing software solutions with world-class quality.


Leave a Reply

Your email address will not be published. Required fields are marked *