Remediate Security Vulnerabilities in npm/Yarn dependencies
Software vulnerabilities are typically the root cause of many computer system security failures.
During a software development lifecycle, there are three stages to address such security vulnerabilities: (1) improving software quality during development, (2) pre-release bug discovery and repair, and (3) revising software as vulnerabilities are reported or found. Failing to address these vulnerabilities could cause data loss, service outages, unauthorized access to sensitive information, or other issues.
This article will cover the following steps to fix security vulnerabilities in npm/Yarn dependencies:
1. Getting familiar with the popular package managers
2. Understanding package dependencies and semantic versioning
3. Auditing your packages for vulnerabilities
4. Interpreting CVE code and researching for vulnerabilities
5. Identifying the alternatives and resources
Getting Familiar with the Popular Package Managers
Two of the most popular package managers among the web development community are npm (Node Package Manager) and Yarn. There are a lot of similarities between these two package managers and as a result, these package managers have about the same popularity.
npm (short for Node Package Manager), initially released in 2010, is one of the two popular package managers among JavaScript developers. In fact, It is the default package manager that is bundled with Node.js. Yarn, initially released by Facebook in 2016, is the other popular package manager for JavaScript. The intention behind creating Yarn was to address some of the performance and security shortcomings with npm. Nevertheless, both npm and Yarn are great package managers for Node.js and Javascript.
Understanding Package Dependencies and Semantic Versioning
Both npm and Yarn keeps track of the project’s dependencies and their version numbers in the package.json file that exists at the root of the project’s working directory keeping all the relevant metadata associated with the project and managing the dependencies version, scripts, and many more. In addition, both npm and Yarn provide an auto generated lock file called package-lock.json or yarn.lock respectively to ensure the same file structure in node_modules across all environments when installing a dependency.
Whenever you install dependencies or inspect package.json, you may notice that the dependency’s version may start with “^” before the version number. This implies whenever we install all the packages in another machine, or manually run the command to install, the package manager looks for newer versions released. If there is a newer version then that is automatically installed rather than the one mentioned in the package file. There are two ways to avoid this if you don’t want automatic change in your packages, one is to generate a lock file, so that only a particular version is installed every single time and the other is to remove ^ in the package file.
SemVer (Semantic Versioning) is denoted by three numbers, major, minor, and patch (e.g. 1.3.1). The first number (the major version) may include incompatible API changes or incompatibilities with older versions. The minor version (the second number) may add backwards-compatible functionality changes. The final number is the patch version which may include backwards-compatible bug fixes. In some cases, you may even encounter minus (unstable) and plus (metadata) behind the SemVer in the form of 1.3.1-beta+7890.
Auditing Your Packages for Vulnerabilities
A security audit is an assessment of package dependencies for security vulnerabilities to help you protect your package’s users by enabling you to find and fix known vulnerabilities in dependencies.
The npm audit or yarn audit command submits a description of the dependencies configured in your package to your default registry and asks for a report of known vulnerabilities. Audit only checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies. npm audit or yarn audit automatically runs when you install a package with npm install. You can also run npm audit or yarn audit manually on your locally installed packages to conduct a security audit of the package and produce a report of dependency vulnerabilities and, if available, suggested patches. npm update or yarn update is the simplest way to fix security issues. However, when you are working on a large codebase with multiple dependencies, executing npm update or yarn update is not a good idea because it will force updates to many packages which could result in unexpected changes in your software application. In addition, most of the critical security vulnerabilities are also reported and tracked under CVE code with the accompanying details and version including the fix.
Interpreting CVE code and researching for vulnerabilities
CVE is a dictionary that provides definitions for publicly disclosed cybersecurity vulnerabilities and exposures. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services) with these definitions. Each CVE contains a standardized identification number, a description, and at least one public reference for a given vulnerability or exposure. Knowing this common identifier allows you to quickly and accurately access information about the problem across multiple information sources that are compatible with CVE. CVE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) to be publicly available to anyone interested in correlating data between different vulnerability or security tools, repositories, and services.
You can easily search using the provided CVE code in multiple vulnerability database providers like NVD (National Vulnerability Database), OSVDB/VulnDB (Open Source Vulnerability Database), White Source, Snyk.io, and many more issue trackers from the originating repositories. If you find manually performing audits or subscribing to newsletters of security vulnerabilities cumbersome, there are a handful of free and premium security vulnerabilities code scanning services available at the convenience of delivering notifications once a security vulnerability is detected within your project. Service providers like White Source, Synk, and GitHub offer code scannings on the projects uploaded on their repositories or via API integrations. Security reports generally include overview, details, remediation, and references where the vulnerability is reported and fixed.
Identifying the Alternatives and Resources
On some occasions, you may receive the security vulnerability report where your current project utilizes version 7 but the security fixes are only added after version 8. Performing a major upgrade from version 7 to version 8 can potentially introduce unwanted security flaws or breaking API incompatibilities. Being a tech-enthusiast developer, I embrace the latest features and technologies but it is not always realistic or feasible when the latest upgrade can introduce new vulnerabilities or the potential loss of stability. In these scenarios, we have to research and understand the scope and behavior of the security vulnerabilities when it is not a simple npm update or yarn update. Understanding the vulnerabilities can help us tremendously in identifying potential alternatives in patching and getting the vulnerabilities fixed. This blog from White Source also entails a few recommendations to remediate vulnerabilities.
A few initiatives can also be driven to bring awareness on the vulnerabilities by researching community threads within StackOverflow or GitHub repositories, starting a community thread, and raising pull-request issues when the bugs or the security vulnerabilities are not being discussed. If your organization has a license contract with the repository owner, your team might be able to propose the remediation through the future version updates and backports.
Also read: Vulnerability detection using VulnDB integration with Nmap
Author
SEIN TUN
Sein Tun is a Software Engineer working at Crest Data. He has varied software development experience utilizing modern technologies and frameworks like React, Redux, Node.js, JavaScript, Python, and Golang to build secure high-performance systems. Before joining Crest, Sein worked as Financial Banker and Assistant Manager for 3 years with JPMorgan Chase Bank excelling in customer experience, compliance, and team management. He is a proud alumnus of the University of California Riverside with a Bachelor of Science in Management Information System. He enjoys building applications that improve and make a difference in people’s lifestyles.