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.
4/21/2016
11:18 AM
Jonathan King
Jonathan King
Partner Perspectives
50%
50%

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
Comments
Threaded  |  Newest First  |  Oldest First
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google's new See No Evil policy......
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31664
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 44741ff99f7a71df45420635b238b9c22093647a contains a buffer overflow which could allow attackers to obtain sensitive information.
CVE-2021-33185
PUBLISHED: 2021-06-18
SerenityOS contains a buffer overflow in the set_range test in TestBitmap which could allow attackers to obtain sensitive information.
CVE-2021-33186
PUBLISHED: 2021-06-18
SerenityOS in test-crypto.cpp contains a stack buffer overflow which could allow attackers to obtain sensitive information.
CVE-2021-31272
PUBLISHED: 2021-06-18
SerenityOS before commit 3844e8569689dd476064a0759d704bc64fb3ca2c contains a directory traversal vulnerability in tar/unzip that may lead to command execution or privilege escalation.
CVE-2021-31660
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 85da504d2dc30188b89f44c3276fc5a25b31251f contains a buffer overflow which could allow attackers to obtain sensitive information.