How to fix security vulnerabilities in Yarn

Node.Js has a large community supporting many open source modules. They bring third party code and functionality into your codebase. In the Node.JS community sharing and reusing code has become the norm.

Unfortunately shared code doesn’t only bring the good parts; it also includes any vulnerabilities in it. Unmanaged vulnerabilities may lead to a critical security compromise in your apps and projects.

In recent years, Node.JS has exploded in popularity. But the more software gets built based upon Node.JS, the more lucrative any security compromise in it becomes to malicious attackers. There are many ways through which an attacker can compromise a javascript application.

In the post below we will focus on tools for evaluating the security of yarn packages.

Why use Yarn instead of npm?

Yarn was released in 2016 as an open-source collaboration between Facebook, Google, and few other major tech companies.

At the time they had major pain points with NPM, the default NodeJS package manager. Most of these had to do with performance and dependency management, but security was also a major concern (even though NPM nowadays has caught up).

With NodeJS projects, it’s very common to use a large number of modules. This is something that comes naturally as the project grows. Most packages have dependencies of their own, so you might end up with a rather large number of them for even a simple project.

This means that any fresh install will potentially have to download and install hundreds of megabytes of package data.  Yarn installs are multithreaded, meaning that they are significantly faster than the single-threaded NPM install.

Additionally, because of the way Yarn manages local and global caching, you are considerably more likely to avoid downloading something from a remote registry over the internet.

Yarn was intended to just change the way npm packages are installed, so it simply uses the same repository standard as npm. 

Installing a package with yarn or with npm will have the same result from the perspective of the code that uses the package. NodeJS projects using Yarn are more likely to be easily reproducible because Yarn by default pins all dependency versions.

So if I do a yarn install, yarn will write to my project’s yarn.lock file and write down the package source and version. If you try to build the same project, you will end up with the same version of all dependencies.

This makes it great for reproducibility, CI/CD, and might help your sanity in cases where you made no change to the codebase but the app stopped working. But having to manually upgrade packages also makes you less likely to do it, which might mean that you end up running package versions with known vulnerabilities. But more on this later. 

What are the ways a Yarn vulnerability can be exploited?

Let’s start by looking at the security concepts that yarn provides by default. Out of the box, yarn provides us with checksum verification. Checksum validation is a proven method of quickly determining if two files are identical without going into the details of the specific files.

When yarn downloads a file from an NPM registry, it automatically ensures that said file is identical and that it hasn’t been tampered with between the registry and our local machine. 

While this is not a major concern as most npm modules are downloaded through a TLS/SSL encrypted connection, it still has its cases. You might be downloading from your company’s local npm registry, or you might for some reason be forced to use a pure HTTP, unencrypted connection. A targeted attack could easily use such an opportunity to introduce a more serious backdoor into your software. 

A bigger concern is the increased attack surface area inherent in using any third-party modules. With a yarn install, you will end up with the package you want to be installed as well as all its dependencies, fixed to versions specified in its yarn.lock file.

As previously mentioned, anyone trying to replicate your code’s build process will end up with precisely the same versions of all packages. While this is very useful for CI and builds replicability, it has some security implications. 

Security Vulnerabilities in Yarn

Many popular node packages become targets to attackers with malicious intent. For one, open source means that anyone who wants can access and read the code. Meaning that people who know what to look for might be able to find vulnerabilities in the codebase of a module or a critical dependency.

The Node.JS blog is an excellent resource for getting a taste of recent security updates and vulnerabilities. But unintentional vulnerabilities are not the only concern here, malicious intent of the package owners is another concern. 

In a 2019 report, researchers concluded that compromising 20 developer accounts would compromise more than half the packages published on the official NPM registry. The malicious takeover of package ownership has happened in the past.

A recent high-profile exploit was the malicious code in event-stream package which stole cryptocurrency from users. The end target was the Copay cryptocurrency app. Malicious code sent the account credentials to steal cryptocurrency from the wallets. The attack was performed by posing as the package maintainer and simply pushing the malicious code into the npm repository. 

In short we can conclude that keeping track of vulnerabilities in Yarn might be a good idea. So, what’s the best way of doing it? And how can you actually fix vulnerabilities in an easy way, rather than just identifying them?

Tools for evaluating and fixing Yarn vulnerabilities

Tl;dr: do you want to minimize the amount of manual work and research when managing vulnerabilities? Start a free Debricked account and enjoy security automation at its best. If not, keep reading!

Security of Node.JS packages has become a major concern, and as such has created the need for evaluating package security. Below you will find a list of free and paid tools that will assist in the process of securing the npm packages installed through yarn. While such tools are quite powerful when run by hand, they really shine when you integrate them inside your CI/CD pipeline. 

Yarn audit

Yarn audit is a built-in tool of yarn that checks for known vulnerabilities inside your package dependencies. Similar to the npm audit it uses the official node.js and npm vulnerabilities database. But unlike its npm counterpart, it doesn’t have npm audit fix functionality.

You are still able to see vulnerabilities for dependencies, but it will not compute the full upgrade path based on said dependencies for you. Commonly you would integrate it in your pipeline and where it would “fail” and stop the further deployment of the app if any vulnerabilities are found.

You will have to use or create more tuned logic if you want to notify the right people and auto-assign developers/teams without just stopping and waiting for someone to take a look at the outage.

improved-yarn-audit

This tool builds upon the yarn audit and provides a few changes. These are not really “fixes” per se, they are more of a different creative approach to yarn audit. It provides the following improvements:

• A way to ignore advisories
• Ability to filter out low severity issues
• Ongoing network issues with the NPM registry will not cause false positives

yarn-audit-fix

As previously mentioned, there is no yarn audit fix command. This package attempts to replicate the npm audit fix command functionality in yarn. It can be quite a useful tool for actually fixing vulnerabilities found by other tools on this list.

yarn-audit-html

This tool is very useful for presenting the current vulnerability status on an HTML page. Inside a CI/CD platform, it’s quite useful to generate such reports and host them on an apache server or through GitLab/Github pages. For instance, you could automatically add the link to such a report directly inside the merge request so that you can enrich the reviewer’s decision with such data.

audit-ci

Audit-ci is an open-source tool backed by IBM. While it doesn’t do much checking on its own it makes npm audit, yarn audit, and similar tools easy to integrate into popular CI/CD Platforms. If your project is already using CI/CD adding audit-ci to it might be the simplest thing you can do.

In case you don’t intend to run a CI/CD pipeline for your code, consider setting up a check that checks your branches once a week. That way you will be able to stay on top of your yarn vulnerabilities without the additional effort of manual code checking.

While you can simply stop the pipeline if critical vulnerabilities are found, working on further automation of the issue propagation might be crucial for timely fixing of the vulnerability. 

Debricked 

Debicked’s tool has all the above mentioned functionality and more built into one; it allows you to automatically identify, prioritize and fix vulnerabilities with minimal effort. It integrates with your CI/CD within minutes and gives instant, actionable results.

It also features a powerful policy engine that allows you to set customizable rules that will keep vulnerabilities of a chosen severity out of your codebase. Get started for free!

Check for Yarn vulnerabilities manually

There are many public vulnerability databases that also cover Node.js module security. Their purpose is to provide a safe validated place for reporting vulnerabilities as well as a way to publicly disseminate issues as well as affected versions.

The commonly used ones are the US Government National Vulnerability database, NPM security advisories as well as mailing lists, bug trackers, and GitHub/GitLab issues related to the project in question.

A number of companies also maintain aggregated bug trucking sources, some of them even free. Although the free options tend to rate-limit requests or impose similar restrictions.

Debricked recently launched a public vulnerability database where data from multiple vulnerability databases such as NVD, NPM security advisories and others are collected and presented in one place.

So, what is the best way to fix Yarn vulnerabilities?

There’s no right or wrong here – it all comes down to personal preference and individual needs. For larger teams and organizations it’s quite clear that a full blown software composition analysis tool is the best choice, especially since they probably have vulnerabilities in more frameworks than Yarn and why not kill two birds with one stone.

Another aspect is that an SCA tool such as Debricked’s features further functionality such as license compliance and reporting that most solutions don’t.

For small teams it might be a different story, but if we’re really honest; who likes dealing with vulnerabilities? The answer is no one, and that’s exactly why even teams as small as two people should draw benefit from automated tools instead of putting in hours and hours of security research.

If you’re looking to improve the way you handle vulnerabilities while still spending minimal time on it, start a free Debricked account today.