on Ben White Unsplash Disclaimer: This article is a high level overview of how package management and the associated licensing issues work. It is meant to make new javascript developers aware of the concerns which can arise for their project/client/organisation and is not meant to discourage the spirit. The Javascript landscape has significantly over the years. It, now, offers developers many tools to easily manage the complexity on the client end of the application. If you are a developer who has written some non-trivial code in Javascript before when was not the standard for DOM manipulation you know we have come a long way. I still remember my first ⭐️ moment with which made two way data binding so simple. However, although we could go on about how every new front-end library/framework has made our life simple, this article would quickly loose its focus. changed jQuery AngularJS Javascript community pushing the boundaries 💥 Why do we need these frameworks/libraries though ? Javascript is an implementation of the specification. Who is supporting the implementing of these new and upcoming specs? Our very own favourite browsers! Each browser adopts a javascript engine which is responsible for executing the javascript code which we write. Since we/our users are spoiled for choice when it comes to browsers this leaves us with implementation differences of ECMAScript specification. If browsers with their respective javascript engines were consistent with their approach and were keeping up with the latest developments made by then honestly, for most of the things we wouldn’t need these frameworks and libraries. But lets be realistic! ECMAScript TC39 This is so not true Package Managers for javascript packages & are the popular package managers for javascript libraries. They have made life really simple in terms of installing, shipping front-end apps e.g. if you need to install a library like all you need to do is npm yarn vue <package-manager> add/install vue and that’s it! It downloads everything it needs to run and you are good to go. Based on the environment (dev/prod/test) in which the app needs to run, you can configure which packages you need for your app to run in that specific environment. What happens internally when we install packages ? Every engineer working with npm or any other package manager should know the answer to the above question. A detailed answer can be found else if you are feeling lazy and just want to know the basics then keep on reading. Every new package brings with itself other packages which are required for it to run smoothly and those other packages install even more packages for them and before you know it your project has a set of packages about which you have no clue. Lets say if you install a package for your app then you have a direct dependency on this package and if it needs a package then you have a transitive dependency on package and so on. here B A C C Why should we bother about transitive dependencies ? In any application, the graph of dependencies is complex and is not visually appealing also 😛 when compared to the graph below. Depending on what packages you are using for your project the graph can have many more levels and many more nodes to it. Basically, longer and wider. A very simple dependency graph Let’s imagine a slightly more practical scenario where the graph looks something like below for your project. As you can see that there are multiple paths which lead to package Consider B_1_ & B_2_ as two different packages and the same for C_1_ and C_2_ since the numbers 1 & 2 are not to be confused with the versions of packages B & C. X A -> B_2 ->_ C_1 ->_ X & A -> B_1 ->_ C_2 ->_ X non-trivial dependency graph since it’s marked in red represents something which can cause problems for your project in some ways. Lets have a look at the two popular scenarios where things can go wrong due to package X X Security We don’t really know what the transitive package(s) are actually doing under the hood (I am assuming you already know what the direct dependencies are doing — you should! 👨🏫) it might happen that you end up installing a package which tracks sensitive user data on forms, like usernames, passwords or any other personal information else if you are running javascript on the server then and is something you should keep your hands away from. I am not a expert, but if you think from a perspective of a there can be so many where a malicious package can cause security issues. Prototype Pollution ReDOS security cracker other ways A motorist by-passing police security check 👮 Legal Packages such as vue, jquery etc. have a license, which can be paraphrased as saying, MIT It lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable pdf.js uses which quotes Apache License 2.0 Similar to the MIT License, but also provides an express grant of patent rights from contributors to users Both the above licenses seem fine and seem to pose no threats no matter what type of use you put them to, even commercial. No matter how restrictive a license is for a third party package it is not an issue until it is distributed to the public (unless the package license terms state explicitly that its illegal to use privately also) and it’s also ok to distribute the package to employees who are part of the same organisation. License check fail ❌ Now you might think that since your software/service is distributed over a network for a SaaS (Software as a Service) based product of yours and is not present on a user’s machine that it’s ok to use any third party package — but licenses like also considers network usage as a distribution of the software. GNU AGPLv3 How can the above security and legal issues be prevented ? A bearded person who decides to quit 😫 Now that we know what the problems are, a reasonable solution, from the top of my head is to come up with a way where by we can look at each package which is used (directly/indirectly) by my project starting from the file (for npm). This is something which is called a of dependencies. Your deep scan should be able to look at each package and make a decision whether it is safe to use or not from both security and legal perspectives. This whole process has three parts to it : package.json deep scan To be able to scan efficiently and properly all the dependencies in your project. To be able to make a decision on whether it’s safe to use a package from security and legal point of view. Doing 1 & 2 repeatedly There are some open source and proprietary APIs ( , , which can help with some or all of the parts of the process, you just need to figure out what is best for your case. There can be scenarios where your checks discover a vulnerability but sometimes its to avoid them e.g. if you are not running javascript on the server then vulnerability can be considered non-dangerous. RetireJS NSP Snyk, fossa) ok ReDOS To summarise, the concept of npm and package managers is awesome but always keep your eyes open for what your dependencies are bringing with them for you. Cheers! Happy Coding 😺 Some sources which can be further useful Understanding the dependency model Choosing a license for your project Vulnerabilities tagged by risk Great article by on Vova Bilonenko why should we care about licenses
