Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
11:18 AM
Jonathan King
Jonathan King
Partner Perspectives

The Perils Of Dynamically Pulling Dependencies

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.

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.

Jon King is a security technologist and Intel Principal Engineer in the Intel Security Office of the CTO, where he is researching and working on future security challenges. Jon is a seasoned developer and architect with over 20 years of industry experience, and a 10-year ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.