On Friday 9 December 2021, the information security world was rocked by the disclosure of Log4j (CVE-2021–44228), a zero-day vulnerability in the widely used Java logging library Apache Log4j, which allows attackers to remotely execute code and gain access to machines. This has been described as one of the most serious security vulnerabilities in recent years. The reported log4j vulnerabilities have impacted over 35,000 Java artifacts from Maven Central, causing broad fallout across the software industry. Lack of visibility into the project’s dependencies and transitive dependencies has made it more difficult to take quick actions to provide patches.
Third-party vulnerabilities have been huge news recently in the software industy after the Apache Log4j Vulnerabilities were revealed. Using existing libraries is often easier and quicker. However, if you are not careful you can end up in a mess. Are you aware of the third-party dependencies being used by your project and the risk they made to the enterprise security?
In this article, I’ll give a breif introduction to third-party dependencies and their key advantages & disadvantages. In my next blogs, I’ll explain more aspects related to third-party dependencies.
A third-party component is a software developed by an entity that can be distributed as an open-source or commercial component (sold) to other entities who can reuse it to develop.
Building a new application from scratch requires a lot of time and effort. Third-party components allow developers to reuse common functionalities instead of reinventing the wheel. Using third-party components, like web servers, frameworks, or libraries, makes the development process easier for the developers because they allow developers to use already tested software. Hence, time and sometimes the cost of development is automatically saved.
Advantages of Third-Party Libraries
- Save Time and Cost
The most important benefit of using third-party libraries is that it saves development time and cost. But, you’ll still need to spend some time reading the library’s documentation and understanding how to integrate it, but typically this is just a fraction of the time that would be required to develop and test its functionality from scratch.
- Domain expertise
One of the most common reasons for using third-party libraries is a lack of domain expertise. Authors are usually experts in the library’s domain area. This will ensure that you get the appropriate implementation.
These libraries have the significant benefit of being used by others in addition to you. A well-known library will have been used in a variety of environments and use cases. Bugs will have been reported and fixed as a result of the feedback loop. If they don’t correct them, it’s a good opportunity for you to contribute and give back to the community!
- New features
They will appear in your product automatically and without effort. If you are using the reporting engine from vendor X, and vendor X releases the new feature Y, you will be able to provide the new Y feature to your customer at no cost, with very low effort. You can think of the library’s authors as additional teams that work for you for free or very little money.
Disadvantages of Third-Party Libraries
When you rely on a third-party library, your code is bound to that library. If you are forced to switch libraries at some time, your code may need to undergo considerable changes to adapt to the new library.
Using too many libraries can lead to issues such as dependency conflicts, which are difficult to identify and resolve. An excessive number of libraries will bloat your software, increasing its size and consuming more memory. As a result, your product’s performance will suffer as a result.
- Security Vulnerabilities
The use of third-party libraries might raise some security concerns as vulnerabilities in open source libraries are increasingly targets for hackers.
You are adding a dependency to your project, but that dependency will probably have their own dependencies. While the added dependency acts as a direct dependency for the project, it can be added a set of transitive(indirect) dependencies to the project with that dependency(Figure I). As a consequence, vulnerabilities also can be pulled as direct or transitive vulnerabilities(Figure II).
Sometimes fixing security vulnerabilities might take a lot of effort. And also related to transitive vulnerabilities, simply fixing the problem in the indirect dependency might break the upstream vendor’s code, so a seemingly simple bug can sometimes be very problematic to fix. However, to fully understand your security posture, it’s important to be aware of all vulnerabilities found in your dependency chains.
- Vendor lock-in
When using a third-party solution, you’re inevitably dependent on the provider. A possible risk is that a library could be abandoned by its author. This poses a risk to the stability of your software. That’s why it’s a common practice to write core application features from scratch and use third-party solutions only for its non-core elements.
- Risk of rising costs
Being reliant on the provider also means that the application’s costs may rise if the supplier’s pricing changes. It sometimes happens that the costs of third-party solutions grow drastically at a certain scale.
Choosing third-party libraries is an important part of almost any software development effort. A well-maintained external library can save many hours of engineer time by allowing you to concentrate on your own product’s fundamental differentiators rather than having to re-implement common functionality. On the other hand, poorly implemented libraries can be difficult to use and expose security vulnerabilities that put your organization and your customers at risk.
At this point, I hope I gave you a brief overview of third-party dependencies. In the next blog, I’ll elaborate more on the risks associated with these third- party libraries in software development and what are the factors to consider before adding a third-party library in development.
Thank you for reading this article!