The Perils Of Dynamically Pulling Dependencies

Many developers of modern Javascript Web applications use public libraries, or packages, to build their amazing apps quickly, avoid reinventing something, or get help for something they don’t know how to do. The largest of these libraries is npm (Node Package Manager), which has packages from hundreds of thousands of developers that run the gamut from abbreviation helpers to zip archive tools. These help developers focus on their core app functions and competitive strengths, instead of common functionality.

Many apps, especially from smaller or less mature development organizations, load their dependent packages dynamically, pulling the code from the public repository when the app is deployed. This reduces code management requirements and automatically picks up the latest version unless otherwise specified, so they get the most recent features and bug fixes.

Unfortunately, there is a risk to dynamically resolving these packages, which was recently demonstrated when a developer removed more than 250 of his packages from npm over a trademark dispute. Any app that dynamically included one or more of his packages would fail to deploy when the dependency could not be resolved, resulting in lost business and frustrated customers. In this instance, one of the packages was a basic routine that was included in other higher level packages. As a result of its popularity, this one package was downloaded 2.5 million times in the month prior to the event. After npm removed the package, any software deployment attempting to pull the package from the npm repository would fail, which affected many applications across the Internet.

Nothing From Scratch

Development today is never done from scratch. We build on frameworks, libraries, and packages that make it possible to rapidly build and integrate software that would never exist if every development project started at ground zero. But it is important to know your dependencies, and for a development team to be in control of when the dependencies are upgraded, altered, or removed. The risk in pulling dependencies dynamically is not just failed builds and deployments, but the possibility of malicious code being added to a package running in your environment, or unknowingly distributing it to customers.

Use of third-party source code is such a common practice -- especially if you use frameworks and other development tools -- that you may have no idea how many packages you use. To protect your company and your customers from these risks, you should consider adopting security development lifecycle processes.

First, you need to know your full set of dependencies because any frameworks that you might use can bring in their own dependencies, and so on. You should know the versions you depend on and the licenses under which the library or package is released. Check the dependencies into a local repository and control updates and version changes. Early in a project’s lifecycle you may be willing to accept updates with less inspection, but as the product gets close to release, or if you’re in production, you should apply more scrutiny to the newer versions.

Next, you should put a programmatic restriction to ensure you catch situations like this in your continuous integration environment, or as part of your deployment pipeline. One solution is to use your firewall to block links to external package repositories in your staging environment or production servers, catching dynamic includes and stopping your continuous deployment pipeline before your app completes its deployment tests. Any missing packages can then be checked against the approved list, and any missing ones reviewed and copied into your internal repository upon approval.

Depending on the nature of your development environment and its connection to production systems, you may want to do this for internal integration environments as well, although that could introduce delays in the process when new packages are used for the first time. The wide range of functions and broad availability of external packages is a tremendous boon to software development, but keep an eye on the security implications to manage your risk.