The latest v1 major version of Yarn 1.22.22 supports a dependency audit command yarn audit that is similar to npm audit and allows developers who choose to use the Yarn package manager to check for vulnerabilities in their dependencies.
How Yarn pulls vulnerability information
Yarn uses the same vulnerability database as the npmjs registry (which to date has transitioned over to GitHub and its advisory database).
As such, Yarn just mirrors the same API calls that the npm CLI uses to fetch vulnerability information when running with npm audit and that by default in modern npm versions runs automatically after* installing packages.
Itβs important to note that Yarn doesnβt maintain its own vulnerability database, nor curates or triages any security vulnerability information, nor do any vulnerabilities about npm packages are reported to Yarn maintainers.
How to use yarn audit
Simply run yarn audit in your project directory to check for vulnerabilities in your dependencies.
If you donβt already have Yarnβs lockfile generated (yarn.lock), Yarn will generate it for you before running the audit. and then present the results of the audit in a table format.
Hereβs an example output of yarn audit:
Note: if youβre using the latest major version of Yarn - Yarn 4, the audit commands exists under the command-line flag as follows: yarn npm audit (yes I know it looks confusing but thatβs the actual command).
How to read security vulnerability results from yarn audit output
Yarn and the npm CLI, while using the same underlying advisory database for vulnerabilities, choose to display and print out the results of the audit in different formats.
Yarnβs table format is quite more friendly and easier to read than npmβs formatting which is much more verbose and harder to parse. To compare, hereβs the same path-to-regexp vulnerability as reported by npm audit:
So, Yarn makes it more obvious to understand the top-level direct dependency that introduces the nested package with the vulnerability, and the path to the vulnerable package.
Hint: Yarn also supports JSON output with yarn audit --json if you want to parse the results programmatically, like say in a CI/CD pipeline or some custom tool youβre building.
The vulnerabilities reported by yarn audit can be fixed by updating the vulnerable package to a newer version that has the vulnerability patched, based on the versions range that Yarn reports.
Do note though that sometimes there exist no upgrade versions with a fix to the vulnerability (for example in cases where the vulnerability is very new, or the package is no longer well maintained), in which case you might need to look for alternative packages or solutions. Maybe consider applying the patch yourself using the patch-package package on npm.
That said, I highly recommend both using the Snyk CLI (npm install -g snyk) and integrating Snyk into your GitHub or Gitlab repository so that Snyk can monitor for new vulnerabilities in real-time as it learns about them and then automatically create new Pull Requests with upgrade fixes to your dependencies.
The Snyk CLI is also very handy and much more powerful than both yarn audit and npm audit because it was tailored for developer-first security workflows. For example, it will by default filter noise from development dependencies (those in devDependencies that donβt get pushed to production), and it can also test for vulnerabilities in your own code, Docker images, Kubernetes manifests, Terraform configurations, and more.
By using Snyk you also get access to Snykβs vulnerability database which is much more comprehensive than the npmjs advisory database, and you get access to Snykβs security research team that curates and triages security vulnerabilities and can provide you with more context and guidance on how to fix vulnerabilities.
Hereβs an example snyk test output:
Conclusion
Whether you use yarn audit, npm audit or snky test, itβs already a good step forward that you are thinking about your applicationβs security :-)
I curate many security incidents related to npm on my Awesome Node.js Security repository so secure dependency management is critical and you shouldnβt take it lightly. I agree that thereβs a lot of noise to filter through and vulnerability fatigue is a problem, but itβs better to be safe than sorry. Also, learn to use the tools that help you focus on the important bits (hint: Snyk!).