Why Open Source Dependencies Are Your Blind Spot?
Table of Contents
A few years ago, JavaScript developers worldwide saw their applications failing to build or compile. It was soon learned that the outages were due to a developer pulling his packages out of npm, a dependency manager for JavaScript. The unpublished packages included an 11-line left-pad function that was downloaded 2.5 million times in the month prior to the incident, an indication that the function was extensively used in other applications. One of those applications turned out to be Babel, a JavaScript compiler of many popular websites. Babel contained a module that depended on the left-pad function. When JavaScript applications stopped compiling altogether in Babel, because the module cannot call the left-pad function, thousands of developers started panicking.
In the wake of the incident, questions arose on how to prevent the recurrence of the problem. Although npm took flak for its handling of the situation that led to the unpublishing of the packages, it took measures to prevent similar incidents from happening in the future. However, this has started some interesting discussion about third party dependencies, especially open source dependencies.
Open source direct and transitive dependencies
In 2008, Gartner published a report on the state of open source software stating:
“… if you don’t think you use it, then you use it; and if you think you do use it, then you use lots more of it than you know.”
Unfortunately, even now, years later, this is still true for the majority of software development teams. Why is that?
The main reason is that, in most teams, developers can freely choose whatever open source components they wish to use and integrate it with their software. They are usually required to document their usage manually but there’s no strict gateway to add an open source component to your software. The question is, as Forrester principal analyst Jeffery Hammond raises, can you really trust manual reporting when it comes to your software security and quality?
The other reason is open source dependencies. Developers are usually oblivious to the number of open source libraries they are using due to dependencies. Especially if they are using dependency management tools like Maven (Java), Bower (JavaScript), Bundler (Ruby) etc. that pulls in third party dependencies automatically.
There are two main types of dependencies: direct and transitive. Direct dependencies are the libraries your code is calling to and transitive dependencies are the libraries that your dependencies are linked to – basically, they are dependencies of dependencies.
Not tracking your open source dependencies is making you lose visibility and control over your software. Let’s discuss the 4 main aspects where it can come back and bite you:
#1: Open source licenses
You need to keep track on your open source licenses and ensure compliance, but it’s not enough to only track the licenses of the open source libraries you use. One of your dependencies might have a different license of its parent library. Some developers assume that they need to comply only with the licenses of the open source libraries they are directly using, or just with their direct dependencies. However, companies using open source components in their software products are fully obligated to comply with all open source licenses of the open source libraries they integrated into their products, its direct dependencies, and its transitive dependencies. There are no excuses.
#2: Open source security vulnerabilities and software bugs
When you import a dependency, you import all of its issues including security flaws and software bugs. For example, if an open source library used to generate a web form introduces an SQL injection vulnerability, then your entire software is vulnerable. Same goes regarding critical software bugs in your dependencies. It is equivalent to securing your front door with all the latest and greatest technology while leaving your garage window open. All hackers need is one entry point.
In order to keep track on security vulnerabilities and software bugs detected and reported in your open source dependencies, you must first be aware of the fact that you are actually using it.
#3: New versions update
Now, what happens when your core application has an update? How do you know it’s compatible with your dependencies? You can also look at it from a different angle. How do you know a new dependency update is compatible with your software? Just assume you did find out about a security vulnerability or a severe software bug discovered in one of your dependencies and decided to update the library with the recent patch or version. How can you avoid a domino effect? After all, sometimes a simple change to one module may have unforeseen consequences. This is why regression testing is important.
How can you gain full control and visibility over your dependencies?
If your team is using open source libraries, like almost any commercial software product in the market, you must keep track of all open source libraries you are using, including direct and transitive dependencies.
Mend integrates with your build process and detects all open source components in your software every time you run your build – including all your open source dependencies.
